One document matched: draft-haynes-sacm-oval-variables-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-haynes-sacm-oval-variables-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 Variables Model">OVAL(R)
      Variables 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 Variables Model which contains constructs
        that allow for the specification of values
        for external_variables defined in content
        that was created using the OVAL
        Definitions Model. The OVAL Variables
        Model serves as a useful mechanism for
        parameterizing content based on the OVAL
        Definitions Model.</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 an 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 part of the OVAL
        contribution to the IETF SACM WG that
        standardizes the representation used to
        analyze a system for the presence of a
        specific machine state. It is intended to
        serve as a starting point for the endpoint
        posture assessment data modeling needs of
        SACM specifically for creating
        parameterized Collection and Evaluation
        Guidance.</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_variables"
      anchor="oval-variables">
      <t>The oval_variables type defines the base
        structure in the OVAL Variables Model for
        representing a collection of OVAL
        Variables and their associated values.
        This container type adds metadata about
        the origin of the content and allows for a
        signature.</t>
      <texttable
        anchor="oval_variables_type_mapping_table"
        title="oval_variables Construct">
        <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 Variables content. The
          timestamp property of the generator MUST
          represent the time at which the
          oval_variables was created.</c>

        <c>variables</c>
        <c>VariablesType</c>
        <c>1</c>
        <c>The variables defined in the OVAL
          Variables content.</c>

        <c>signature</c>
        <c>ext:Signature</c>
        <c>0..1</c>
        <c>Mechanism to ensure the integrity and
          authenticity of the OVAL Variables
          content.</c>

      </texttable>

    </section>

    <section title="VariablesType"
      anchor="variables-type">
      <t>The VariablesType provides a container
        for one or more OVAL Variables.</t>
      <texttable
        anchor="variables_type_mapping_table"
        title="VariablesType Construct">
        <ttcol align="left">Property</ttcol>
        <ttcol align="left">Type</ttcol>
        <ttcol align="left">Count</ttcol>
        <ttcol align="left">Description</ttcol>

        <c>variable</c>
        <c>VariableType</c>
        <c>1..*</c>
        <c>A collection of OVAL Variables.</c>

      </texttable>

    </section>

    <section title="VariableType"
      anchor="variable-type">
      <t>The VariableType defines a variable in
        the OVAL Variables Model that corresponds
        to an instance of an external variable in
        content based on the OVAL Definitions
        Model.</t>
      <texttable
        anchor="variable_type_mapping_table"
        title="VariableType Construct">
        <ttcol align="left">Property</ttcol>
        <ttcol align="left">Type</ttcol>
        <ttcol align="left">Count</ttcol>
        <ttcol align="left">Description</ttcol>

        <c>id</c>
        <c>oval:VariableIDPattern</c>
        <c>1</c>
        <c>The globally unique identifier of an
          external variable.</c>

        <c>datatype</c>
        <c>oval:SimpleDatatypeEnumeration</c>
        <c>1</c>
        <c>The datatype of the value(s) in the
          variable.</c>

        <c>comment</c>
        <c>string</c>
        <c>1</c>
        <c>The documentation associated with the
          variable instance.</c>

        <c>value</c>
        <c>string</c>
        <c>1..*</c>
        <c>The value(s) associated with the
          variable.</c>

      </texttable>

    </section>

    <section title="OVAL Variables Model Schema"
      anchor="oval-variables-model-schema">
      <t>The XML Schema that implements this OVAL
        Variables Model can be found below.</t>
      
      <!-- INSERT OVAL VARIABLES 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-var="http://oval.mitre.org/XMLSchema/
  oval-variables-5"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:sch="http://purl.oclc.org/dsdl/schematron"
  targetNamespace="http://oval.mitre.org/XMLSchema/
  oval-variables-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://www.w3.org/2000/09/xmldsig#"
    schemaLocation="xmldsig-core-schema.xsd"/>
  <xsd:annotation>
    <xsd:documentation/>
    <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) Variables. This schema is
      provided to give structure to any external
      variables and their values that an OVAL
      Definition is expecting.</xsd:documentation>
    <xsd:appinfo>
      <schema>Core Variable</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-var"
        uri="http://oval.mitre.org/XMLSchema/oval-variables-5"
      />
    </xsd:appinfo>
  </xsd:annotation>
<!-- ====================================================== -->
<!-- ====================================================== -->
<!-- ====================================================== -->
  <xsd:element name="oval_variables">
    <xsd:annotation>
      <xsd:documentation>The oval_variables
        element is the root of an OVAL Variable
        Document. Its purpose is to bind together
        the different variables contained in the
        document. The generator section must be
        present and provides information about
        when the variable file 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:element name="variables"
          type="oval-var:VariablesType"
          minOccurs="0" maxOccurs="1"/>
        <xsd:element ref="ds:Signature"
          minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
    </xsd:complexType>
    <xsd:key name="varKey">
      <xsd:annotation>
        <xsd:documentation>Enforce uniqueness
          amongst the variable ids found in the
          variable document.</xsd:documentation>
      </xsd:annotation>
      <xsd:selector xpath=".//oval-var:variable"/>
      <xsd:field xpath="@id"/>
    </xsd:key>
  </xsd:element>
<!-- ====================================================== -->
<!-- ==================  GENERATOR  ======================= -->
<!-- ====================================================== -->
  <!--
		The GeneratorType is defined by the oval common 
		schema.  Please refer to that documentation for a 
		description of the complex type.
	-->
<!-- ====================================================== -->
<!-- =================  DEFINITIONS  ====================== -->
<!-- ====================================================== -->
  <xsd:complexType name="VariablesType">
    <xsd:annotation>
      <xsd:documentation>The VariablesType complex
        type is a container for one or more
        variable elements. Each variable element
        holds the value of an external variable
        used in an OVAL Definition. Please refer
        to the description of the VariableType for
        more information about an individual
        variable.</xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="variable"
        type="oval-var:VariableType" minOccurs="1"
        maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="VariableType">
    <xsd:annotation>
      <xsd:documentation>Each variable element
        contains the associated datatype and value
        which will be substituted into the OVAL
        Definition that is referencing this
        specific variable.</xsd:documentation>
      <xsd:documentation>The notes section of a
        variable should be used to hold
        information that might be helpful to
        someone examining the technical aspects of
        the variable. Please refer to the
        description of the NotesType complex type
        for more information about the notes
        element.</xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="value"
        type="xsd:anySimpleType" minOccurs="1"
        maxOccurs="unbounded"/>
      <xsd:element name="notes"
        type="oval:NotesType" minOccurs="0"
        maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="id"
      type="oval:VariableIDPattern" use="required"/>
    <xsd:attribute name="datatype" use="required"
      type="oval:SimpleDatatypeEnumeration">
      <xsd:annotation>
        <xsd:documentation>Note that the 'record'
          datatype is not permitted on
          variables.</xsd:documentation>
      </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="comment"
      type="xsd:string" use="required"/>
  </xsd:complexType>
<!-- ====================================================== -->
<!-- ==================  SIGNATURE  ======================= -->
<!-- ====================================================== -->
  <!--
		The signature element is defined by the xmldsig 
		schema.  Please refer to that documentation for 
		a description of the valid elements and types.  
		More information about the official W3C 
		Recommendation regarding XML digital
		signatures can be found at 
		http://www.w3.org/TR/xmldsig-core/.
	-->
<!-- ====================================================== -->
<!-- ====================================================== -->
<!-- ====================================================== -->
</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-20262026-04-24 10:38:12