One document matched: draft-rothenberg-sacm-oval-directives-model-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
docName="draft-rothenberg-sacm-oval-directives-model-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="OVAL Directives Model">OVAL(R)
Directives Model</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Michael Cokus" initials="M.C."
surname="Cokus">
<organization>The MITRE
Corporation</organization>
<address>
<postal>
<street>903 Enterprise Parkway, Suite 200</street>
<!-- Reorder these if your country does things differently -->
<city>Hampton</city>
<region>VA</region>
<code>23666</code>
<country>USA</country>
</postal>
<phone/>
<email>msc@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Haynes"
initials="D.H." surname="Haynes">
<organization>The MITRE
Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>dhaynes@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Rothenberg"
initials="D.R." surname="Rothenberg">
<organization>The MITRE
Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>drothenberg@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Juan Gonzalez"
initials="J.G." surname="Gonzalez">
<organization>Department of Homeland
Security</organization>
<address>
<postal>
<street>245 Murray Lane</street>
<!-- Reorder these if your country does things differently -->
<city>Washington</city>
<region>DC</region>
<code>20548</code>
<country>USA</country>
</postal>
<phone/>
<email>juan.gonzalez@dhs.gov</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="September" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>Security Automation and Continuous
Monitoring</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>security automation</keyword>
<keyword>continuous monitoring</keyword>
<keyword>endpoint</keyword>
<keyword>posture assessment</keyword>
<keyword>oval</keyword>
<keyword>data model</keyword>
<keyword>posture attribute
evaluation</keyword>
<keyword>posture attribute
collection</keyword>
<keyword>configuration management</keyword>
<keyword>vulnerability management</keyword>
<keyword>information model</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document specifies Version 5.11.1 of
the OVAL Directives Model which defines
the constructs used to tailor the level of
detail contained within a set of OVAL
Results.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Open Vulnerability and Assessment
Language (OVAL) <xref
target="OVAL-WEBSITE"/> is an
international, information security
community effort to standardize how to
assess and report upon the machine state
of systems. For over ten years, OVAL has
been developed in collaboration with any
and all interested parties to promote open
and publicly available security content
and to standardize the representation of
this information across the entire
spectrum of security tools and
services.</t>
<t>OVAL provides an established framework
for making assertions about a system's
state by standardizing the three main
steps of the assessment process:
representing the current machine state;
analyzing the system for the presence of
the specified machine state; and
representing the results of the assessment
which facilitates collaboration and
information sharing among the information
security community and interoperability
among tools.</t>
<t>This draft is the part of the OVAL
contribution to the IETF SACM WG that
standardizes the representation of the
results of an assessment. It is intended
to serve as a starting point for the
endpoint posture assessment data modeling
needs of SACM specifically a capability to
specify the level of detail in Evaluation
Results.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in
<xref target="RFC2119">RFC
2119</xref>.</t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section title="OVAL Directives Model"
anchor="oval-directives-model">
<t>The OVAL Directives Model is used to
control what result information is
included in the OVAL Results as well as
specify its level of detail. </t>
<texttable
anchor="oval_directives_mapping_table"
title="oval_directives Construct">
<!-- DR better title? -->
<ttcol align="left">Property</ttcol>
<ttcol align="left">Type</ttcol>
<ttcol align="left">Count</ttcol>
<ttcol align="left">Description</ttcol>
<c>generator</c>
<c>oval:GeneratorType</c>
<c>1</c>
<c>Information regarding the generation of
the OVAL Directives content. The
timestamp property of the generator MUST
represent the time at which the
oval_directives was created.</c>
<c>directives</c>
<c>oval-res:DefaultDirectivesType</c>
<c>1</c>
<c>Describes the default set of directives
that specify the results that have been
included in the OVAL Results.</c>
<c>class_directives</c>
<c>oval-res:ClassDirectivesType</c>
<c>0..5</c>
<c>Describes the set of directives that
specify the class-specific results that
have been included in the OVAL
Results.</c>
<c>signature</c>
<c>ext:Signature</c>
<c>0..1</c>
<c>Mechanism to ensure the integrity and
authenticity of the OVAL Directives
content.</c>
</texttable>
</section>
<section title="OVAL Directives Model Schema"
anchor="oval-directives-model-schema">
<t>The XML Schema that implements this OVAL
Directives Model can be found below.</t>
<!-- INSERT OVAL DIRECTIVES MODEL SCHEMA
HERE -->
<figure>
<artwork>
<![CDATA[
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
xmlns:oval-res=
"http://oval.mitre.org/XMLSchema/oval-results-5"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:sch="http://purl.oclc.org/dsdl/schematron"
xmlns:oval-dir=
"http://oval.mitre.org/XMLSchema/oval-directives-5"
targetNamespace=
"http://oval.mitre.org/XMLSchema/oval-directives-5"
elementFormDefault="qualified" version="5.11">
<xsd:import namespace=
"http://oval.mitre.org/XMLSchema/oval-common-5"
schemaLocation="oval-common-schema.xsd"/>
<xsd:import namespace=
"http://oval.mitre.org/XMLSchema/oval-results-5"
schemaLocation="oval-results-schema.xsd"/>
<xsd:import
namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
<xsd:annotation>
<xsd:documentation>The following is a
description of the elements, types,
and attributes that compose the
core schema for encoding Open
Vulnerability and Assessment
Language (OVAL) Directives. Each of
the elements, types, and attributes
that make up the Core Directives
Schema are described in detail and
should provide the information
necessary to understand what each
object represents. This document is
intended for developers and assumes
some familiarity with XML. A high
level description of the
interaction between these objects
is not outlined
here.</xsd:documentation>
<xsd:appinfo>
<schema>Core Directives</schema>
<version>5.11.1</version>
<date>4/22/2015 09:00:00 AM</date>
<terms_of_use>Copyright (C) 2010 United States
Government. All Rights Reserved.</terms_of_use>
<sch:ns prefix="oval-dir" uri=
"http://oval.mitre.org/XMLSchema/
oval-directives-5"
/>
</xsd:appinfo>
</xsd:annotation>
<!-- ================================================== -->
<!-- ================================================== -->
<!-- ================================================== -->
<xsd:element name="oval_directives">
<xsd:annotation>
<xsd:documentation>The
oval_directives element is the
root of an OVAL Directive
Document. Its purpose is to
bind together the generator
and the set of directives
contained in the document. The
generator section must be
present and provides
information about when the
directives document was
compiled and under what
version. The optional
Signature element allows an
XML Signature as defined by
the W3C to be attached to the
document. This allows
authentication and data
integrity to be provided to
the user. Enveloped signatures
are supported. More
information about the official
W3C Recommendation regarding
XML digital signatures can be
found at
http://www.w3.org/TR/xmldsig-core/.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="generator"
type="oval:GeneratorType">
<xsd:annotation>
<xsd:documentation>The
required generator
section provides
information about when
the directives document
was compiled and under
what
version.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="directives"
type="oval-res:DefaultDirectivesType">
<xsd:annotation>
<xsd:documentation>The
required directives
section presents flags
describing what
information must be been
included in an oval
results document. This
element represents the
default set of
directives. These
directives apply to all
classes of definitions
for which there is not a
class specific set of
directives.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element
name="class_directives"
type="oval-res:ClassDirectivesType"
minOccurs="0"
maxOccurs="5">
<xsd:annotation>
<xsd:documentation>The
optional class_directives
section presents flags
describing what
information has been
included in the results
document for a specific
OVAL Definition class.
The directives for a
particlar class override
the default
directives.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element
ref="ds:Signature"
minOccurs="0"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The
optional Signature
element allows an XML
Signature as defined by
the W3C to be attached to
the document. This allows
authentication and data
integrity to be provided
to the user. Enveloped
signatures are supported.
More information about
the official W3C
Recommendation regarding
XML digital signatures
can be found at
http://www.w3.org/TR/xmldsig-core/.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:unique name="UniqueDirectiveClass">
<xsd:annotation>
<xsd:documentation>The class
attribute on
class_directives must be
unique.</xsd:documentation>
</xsd:annotation>
<xsd:selector
xpath="oval-dir:class_directives"/>
<xsd:field xpath="@class"/>
</xsd:unique>
</xsd:element>
<!-- ================================================== -->
<!-- =================== GENERATOR ================== -->
<!-- ================================================== -->
<!--
The GeneratorType is defined by the
oval-common-schema. Please refer to that
documentation for a description of the complex type.
-->
<!-- ================================================== -->
<!-- ================= DIRECTIVES =================== -->
<!-- ================================================== -->
<!--
The DefaultDirectivesType is defined by the
oval-results-schema. Please refer to that
documentation for a description of the complex type.
-->
<!-- ================================================== -->
<!-- ================ DIRECTIVES ==================== -->
<!-- ================================================== -->
<!--
The ClassDirectivesType is defined by the
oval-results-schema. Please refer to that
documentation for a description of the complex type.
-->
</xsd:schema>
]]>
</artwork>
</figure>
</section>
<section anchor="Intellectual-Property-Considerations"
title="Intellectual Property Considerations">
<t>Copyright (C) 2010 United States Government. All Rights
Reserved.</t>
<t>DHS, on behalf of the United States, owns the registered
OVAL trademarks, identifying the OVAL STANDARDS SUITE and
any component part, as that suite has been provided to the
IETF Trust. A "(R)" will be used in conjunction with the
first use of any OVAL trademark in any document or
publication in recognition of DHS's trademark ownership.</t>
</section>
<section anchor="Acknowledgements"
title="Acknowledgements">
<t>The authors wish to thank DHS for sponsoring the OVAL
effort over the years which has made this work possible.
The authors also wish to thank the original authors of
this document Jonathan Baker, Matthew Hansbury, and
Daniel Haynes of the MITRE Corporation as well as the
OVAL Community for its assistance in contributing and
reviewing the original document. The authors would also
like to acknowledge Dave Waltermire of NIST for his
contribution to the development of the original document.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA"
title="IANA Considerations">
<t>This memo includes no request to
IANA.</t>
</section>
<section anchor="Security"
title="Security Considerations">
<t>While OVAL is just a set of data models
and does not directly introduce security
concerns, it does provide a mechanism by
which to represent endpoint posture
assessment information. This information
could be extremely valuable to an attacker
allowing them to learn about very
sensitive information including, but, not
limited to: security policies, systems on
the network, criticality of systems,
software and hardware inventory, patch
levels, user accounts and much more. To
address this concern, all endpoint posture
assessment information should be protected
while in transit and at rest. Furthermore,
it should only be shared with parties that
are authorized to receive it.</t>
<t>Another possible security concern is due
to the fact that content expressed as OVAL
has the ability to impact how a security
tool operates. For example, content may
instruct a tool to collect certain information
off a system or may be
used to drive follow-up actions like
remediation. As a result, it is important
for security tools to ensure that they are
obtaining OVAL content from a trusted
source, that it has not been modified in
transit, and that proper validation is
performed in order to ensure it does
not contain malicious data.</t>
</section>
<section anchor="ChangeLog" title="Change Log">
<section title="-00 to -01">
<t>There are no textual changes associated with this revision.
This revision simply reflects a resubmission of the document
so that it remains in active status.</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119; </references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="OVAL-WEBSITE"
target="http://ovalproject.github.io/">
<front>
<title>The Open Vulnerability and
Assessment Language</title>
<author>
<organization>The MITRE
Corporation</organization>
</author>
<date year="2015"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes
problems).
2015-04-17 AR updated ipr attribute. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:00:06 |