draft-ietf-sacm-information-model-02.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "http://xml2rfc.ietf.org/authoring/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 RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3416.xml">
<!ENTITY RFC3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY RFC3954 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3954.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4287 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml">
<!ENTITY RFC5201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY I-D.ietf-sacm-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-use-cases.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-terminology-05.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-requirements-01.xml">
<!ENTITY I-D.ietf-sacm-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-architecture-00.xml">
<!ENTITY I-D.salowey-sacm-xmpp-grid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-salowey-sacm-xmpp-grid-00.xml">
<!ENTITY W3C.REC-soap12-part1-20070427 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-soap12-part1-20070427.xml">
<!ENTITY W3C.REC-rdf11-concepts-20140225 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-rdf11-concepts-20140225.xml">
]>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.ietf.org/authoring/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 <xref target="TNC-Architecture"/> -->
<?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="yes" ?>
<!-- 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-ietf-sacm-information-model-02" 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="SACM Information Model">SACM Information Model</title>

        <author fullname="David Waltermire" initials="D." surname="Waltermire" role="editor">
            <organization abbrev="NIST">National Institute of Standards and
                Technology</organization>
            <address>
                <postal>
                    <street>100 Bureau Drive</street>
                    <city>Gaithersburg</city>
                    <region>Maryland</region>
                    <code>20877</code>
                    <country>USA</country>
                </postal>
                <phone/>
                <email>david.waltermire@nist.gov</email>
            </address>
        </author>
        <author fullname="Kim Watson" initials="K.K." surname="Watson">
            <organization abbrev="DHS">United States Department of Homeland Security</organization>
            <address>
                <postal>
                    <street>DHS/CS&amp;C/FNR</street>
                    <street>245 Murray Ln. SW, Bldg 410</street>
                    <street>MS0613</street>
                    <city>Washington</city>
                    <region>DC</region>
                    <code>20528</code>
                    <country>USA</country>
                </postal>            
                <email>kimberly.watson@hq.dhs.gov</email>
            </address>
        </author>
        <author fullname="Clifford Kahn" initials="C." surname="Kahn">
            <organization>Pulse Secure, LLC</organization>
            <address>
                <postal>
                    <street>2700 Zanker Road, Suite 200</street>
                    <city>San Jose</city>
                    <region>CA</region>
                    <code>95134</code>
                    <country>USA</country>
                </postal>            
                <email>cliffordk@pulsesecure.net</email>
            </address>
        </author>
        <author fullname="Lisa Lorenzin" initials="L." surname="Lorenzin">
            <organization>Pulse Secure, LLC</organization>
            <address>
                <postal>
                    <street>2700 Zanker Road, Suite 200</street>
                    <city>San Jose</city>
                    <region>CA</region>
                    <code>95134</code>
                    <country>USA</country>
                </postal>            
                <email>llorenzin@pulsesecure.net</email>
            </address>
        </author>

        <date year="2015"/>

        <area>General</area>

        <workgroup>SACM</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>todo</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 proposes an information model 
               for SACM.</t>
    
        </abstract>
    
    </front>

    <middle>
    
        <section title="Introduction" anchor="INTRO">
        
            <t>This document defines a notional information model for endpoint posture assessment. It
                describes the information needed to perform certain assessment activities. The scope
                of the information model is to describe the structure of the information carried to
                realize the assessment. It is meant to be a basis for the development of specific data
                models. The terms information model and data model loosely align with the definitions
                in RFC3444 <xref target="RFC3444"/>.</t>

            <t>The four primary activities to support this information model are:<list
                    style="numbers">
                    <t>Endpoint Identification</t>
                    <t>Endpoint Characterization</t>
                    <t>Endpoint Attribute Expression/Representation</t>
                    <t>Policy evaluation expression and results reporting</t>
                </list></t>

            <t>These activities are aimed at the level of the technology that performs operations to
                support collection, evaluation, and reporting.</t>
            <t>Review of the SACM Use Case <xref target="I-D.ietf-sacm-use-cases"/> usage scenarios
                show a common set of business process areas that are critical to understanding
                endpoint posture such that appropriate policies, security capabilities, and
                decisions can be developed and implemented.</t>
            <t>For this information model we have chosen to focus on the following business process
                    areas:<list style="symbols">
                    <t>Endpoint Management</t>
                    <t>Software Management</t>
                    <t>Configuration Management</t>
                    <t>Vulnerability Management</t>
                </list></t>
            <t>These management process areas are a way to connect the SACM use cases and building
                blocks <xref target="I-D.ietf-sacm-use-cases"/> to the organizational needs such
                that the definition of information requirements has a clearly understood
                context.(/wandw)</t>

            <t>The SACM information model offers a loose coupling between providers and
                consumers of security information. A provider can relay what it observes or infers,
                without knowing which consumers will use the information, or how they will use it. A
                consumer need not know exactly which provider generated a piece of information, or
                by what method.</t>
            <t>At the same time, a consumer *can* know these things, if necessary.</t>

            <t>As things evolve, a provider can relay supplemental information. Some consumers will
                understand and benefit from the supplemental information; other consumers will not
                understand and will disregard it.</t> 

            <section title="Changes in Revision 01">
 
                <t>Renamed "credential" to "identity", following industry usage. A credential includes
                proof, such as a key or password. A username or a distinguished name is called an
                "identity".</t>

                <t>Removed Session, because an endpoint's network activity is not SACM's initial focus</t>

                <t>Removed Authorization, for the same reason</t>

                <t>Added many-to-many relationship between Hardware Component and Endpoint, for clarity</t>

                <t>Added many-to-many relationship between Software Component and Endpoint, for clarity</t>

                <t>Added "contains" relationship between Network Interface and Network Interface</t>

                <t>Removed relationship between Network Interface and Account. The endpoint knows the identity it used to gain network access. The PDP also knows that. But they probably do not know the account.</t>

                <t>Added relationship between Network Interface and Identity. The endpoint and the PDP will typically know the identity.</t>

                <t>Made identity-to-account a many-to-one relationship.</t>

                </section>

            <section title="Changes in Revision 02">
                <t>Added <xref target="section-identifying-attributes"/>, Identifying Attributes.</t>
                <t>Split the figure into <xref target="figure-model-of-endpoint"/> and <xref target="figure-information-elements"/>.</t>
                <t>Added <xref target="figure-information-elements-take-2"/>, proposing a triple-store model.</t>
                <t>Some editorial cleanup</t>
                </section>

            </section>

        <section title="Problem Statement">
            
            <t>TODO: revise</t>
            
              <t>(wandw)SACM requires a large and broad set of mission and business processes, and to make
                the most effective of use of technology, the same data must support multiple
                processes. The activities and processes described within this document tend to build off
                of each other to enable more complex characterization and assessment. In an effort
                to create an information model that serves a common set of management processes
                represented by the usage scenarios in the SACM Use Cases document, we have narrowed
                down the scope of this model.(/wandw) [What does "narrowed down the scope of this model" mean? - LL]</t>
              
              <t>Administrators can't get technology from disparate
                sources to work together; they need information to make decisions, but the information
                is not available. Everyone is collecting the same data, but storing it as different
                information. Administrators therefore need to collect data and craft their own information,
                which may not be accurate or interoperable because it's customized by each administrator, not
                shared. A standard information model enables flexibility in collecting, storing, and sharing
                information despite platform differences.</t>

              <t>A way is needed to exchange
                 information that (a) has breadth, meaning the pieces of the notation are useful about a
                 variety of endpoints and software components, and (b) has longevity, meaning that the
                 pieces of the notation will stay useful over time.</t>
              
              <t>When creating standards, it's not sufficient to go from requirements directly to protocol;
                the standards must eliminate ambiguity in the information transported. This is
                the purpose of information models generally. The SACM problem space is about integrating
                many information sources. This information model addresses the need to integrate security
                components, support multiple data models, and provide interoperability in a way that is
                platform agnostic, scales, and works over time.</t>

            <section title="Mapping to SACM Use Cases">
                
                <t>TODO: revise</t>
                
                <t>(wandw)This information model directly corresponds to all four use cases defined in the
                    SACM Use Cases draft <xref target="I-D.ietf-sacm-use-cases"/>. It uses these use
                    cases in coordination to achieve a small set of well-defined tasks.</t>
                
                <t>Sections [removed] thru [removed] address each of the process areas. For each
                    process area, a "Process Area Description" sub-section represent an end state
                    that is consistent with all the General Requirements and many of the Use Case
                    Requirements identified in the requirements draft <xref
                        target="I-D.ietf-sacm-requirements"/>.</t>
                
                <t>The management process areas and supporting operations defined in this memo
                    directly support REQ004 Endpoint Discovery; REQ005-006 Attribute and Information
                    Based Queries, and REQ0007 Asynchronous Publication.</t>
                
                <t>In addition, the operations that defined for each business process in this memo
                    directly correlate with the typical workflow identified in the SACM Use Case
                    document.(/wandw)</t>
            </section>

            <section anchor="section-referring-to-an-endpoint" title="Referring to an Endpoint">

                <t>How to refer to an endpoint is problematic. Ideally, an endpoint would have a unique identifier. These identifiers would have a one-to-one relationship with endpoints. Every observation of an endpoint, or inference about an endpoint would be labeled with its identifier. </t>

                <t>However:
                    <list style="symbols">
                    <t> An external posture attribute collector typically cannot observe the unique identifier directly. An external posture attribute collector should be able to report exactly what it has observed, unembellished. It should not have to *infer* which endpoint it has observed; that inference should be leavable to other SACM components. So, SACM cannot require that every observation include the unique endpoint identifier.</t> 

                    <t>Internal posture attribute collectors are not present on all endpoints. They are not present on "dumb" devices such as Internet of Things (IoT) devices, or on Bring Your Own Device (BYOD) devices. In these cases, *no* observers have direct access to the unique endpoint identifier.</t>

                    <t>An endpoint identifier is generally subject to cloning, when a system image is cloned. Then it is no longer unique.</t> 

                    <t>Suppose the endpoint identifier is highly clone resistant -- such a unique certificate within a trusted platform module TPM.  Even so, it is possible to replace all of the software -- for example, changing a Windows machine to a Linux machine.  Is it still the same endpoint? For SACM purposes, it isn't really the same endpoint. </t>
                    </list>
                </t>

                <t>So SACM components must be able to put disparate observations together and form a picture of an endpoint -- somewhat like a detective. The SACM information model must facilitate this.</t>
               </section>

            <section title="Dealing with Uncertainty">

                <t>With many information models, the information is considered certain. 
                   In SACM, information is not certain.
                   Attackers may develop countermeasures to fool some SACM components.
                   Attackers may compromise some SACM components.</t>  

                <t>So the model must let SACM components and humans reason with uncertainty. There are no facts, only assertions. </t>

                <t>SACM components must be able to cross check observations and inferences against each other. They should be able to give weight if an observation or inference is corroborated by more than one method. Although SACM will probably not prescribe *how* to do this cross checking, SACM should provide the components with provenance information.</t> 

                <t>SACM components must be able to consider the reputation of the observer or inferrer. That reputation should account for the method  of observing or inferring, the implementer of the SACM component that made the observation or inference, and the compliance status of the endpoint on which the observation or inference was made.  For example, if some observers are found to be vulnerable to a Day 1 exploit, observations from those observers deserve less weight. The details of reputation technology may be out of scope for SACM. However, again, SACM should provide components with provenance information.</t>

                </section>
            </section>

        <section title="Conventions used in this document">
            <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>

        <section title="Elements of the SACM Information Model">
            
            <t>The SACM Information Model contains several elements 
               of the architecture, including:<list style="symbols">

               <t>SACM Components, which may be Collectors, Evaluators, etc. 
                   Collectors may be internal (performed within the
                   endpoint itself) or external (performed outside of the endpoint,
                   such as by a hypervisor or remote sensor)</t>
 
                <t>Guidance, which tells SACM components what to do</t>

                <t>Posture, in the form of posture attributes and evaluation results</t>

                <t>Additional information about the endpoint, such as a representation
                   of a software component, endpoint identity, user identity, address,
                   location, and authorization constraining the endpoint</t>

                </list></t>

            <t>The SACM Information Model does not (in this draft) specify
               how long information is retained. Historical information is
               modeled the same way as current information. Historical information
               may be represented
               differently in an implementation, but that difference would be in data models,
               not in the information model. 
               </t>
                          
            <t><xref target="figure-model-of-endpoint"/> 
               introduces the endpoint attributes
               and their relationships.</t>

            <figure title="Model of an Endpoint"
                            anchor="figure-model-of-endpoint">
                            <artwork><![CDATA[
+---------+*______in>_______*+-----+
|Hardware |                  |!   !|
|Component|   +---------+    |!   !|       +--------+*________________
+---------+   |Software |in> |!   !|*_____*|Location|___________   <in|
    1|        |Component|____|!   !|  in>  +--------+*  <in    *|     |
     |        +---------+*  *|!   !|                        +-------+ |
     |            1|         |!   !|                        |Account| |
     |            *|         |     |       +----------+     +-------+ |
     |        +---------+    |End- |*_____*| Identity |_________|0..1 |
    *|        |Software |in> |point| acts  +----------+* belongs      |
+---------+   |Instance |____|     | for>    0..1|^        to>        |
|Hardware |   +---------+*  1|!   !|             |acts                |
|Instance |__________________|!   !|            *|for                 |*
+---------+*      in>       1|!   !|_______+---------+         +-------+
                             |!   !|1 <in *|Network  |1_______*|Address|
                             |!   !|____   |Interface| <bound  +-------+
                             |!   !|0..1|  +---------+   to
                             +-----+    |   *|   |0..1   
                                |*      |    |___|
                                |_______|     in>
                                   in> 
    ]]></artwork>
                </figure>

            <t>ISSUE (CEK): we agreed to remove location and account
               from the model, did we not?</t>

            <t><xref target="figure-information-elements"/>
               is the core of the information model. It represents
               the information elements and their relationships.</t>

            <figure title="Information Elements"
                            anchor="figure-information-elements">
                            <artwork><![CDATA[                                  
                   +-----+            +---------+
                   | AVP |____________|Endpoint |
                   +-----+1..*       1|Attribute|            
                                      |Assertion|                    
                                      +---------+                    
                                        |*                     +-------+
                                        |                      |Summary|
                                        |                      +-------+
                                        |produced-by               *|       
                                        |V                          |
                                       1|                           |
     +--------+              +-----------+                          |
     |        |              | SACM      |__________________________|
     |Guidance|              | Component |1      <produced-by
     +--------+*____________1+-----------+
                <produced-by
    ]]></artwork>
                       </figure>

            <t><xref target="figure-information-elements-take-2"/>
               is a potential alternative structure for assertions.
               It is inspired by triple stores.
               See http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.</t>

                         <figure title="Information Elements, Take 2"
                            anchor="figure-information-elements-take-2">
                            <artwork><![CDATA[                                  
 +-----+______________+---------+                +---------+
 | AVP |1  <subject  *|assertion|________________|predicate|
 |     |______________|         |*  predicate>  1+---------+
 +-----+1  <object   *+---------+
    1^                     |*
     |_____________________|
            <asserter
     ]]></artwork> 
                </figure>

            <t>Note: UML 2 is specified by <xref target="UML"/>.</t>

            <t>TODO: update text to match new figure:</t>
            <t>Need to be clear in the description that ???</t>
            <t>For some of
            the relationships, will need some language and guidance to
            the interfaces and relationships we expect to have happen,
            MUSTs and SHOULDs, as well as explaining the extensibility
            that other relationships can exist, show examples of how
            that can happen. Others that we haven't thought of yet, might
            be added by another RFC or in another way</t>

            <section anchor="section-identifying-attributes" title="Identifying Attributes">

                <t>Identifying attributes let a consumer identify an endpoint,
                   for two purposes:<list style="symbols">
                    <t>To tell whether two endpoint 
                        attribute assertions concern the same endpoint
                        (This is not simple,
                        as <xref target="section-referring-to-an-endpoint"/> explains.)</t>
                    <t>To respond to compliance measurements, for example
                        by reporting, remediating, and quarantining
                        (SACM does not specify these responses,
                        but SACM exists to enable them.)</t>
                    </list></t>

                <t>Out of scope of this section: *classifying* an endpoint
                so as to apply appropriate collection guidance to it.
                We don't call this "identification".</t>

                <section title="How Known">
                    <t>Each attribute-value pair or triple
                       MUST be marked with how the provider knows.
                       There MUST be at least one marking.
                       The possible markings follow.
                       <list style="symbol">
                           <t>"Self" means that the endpoint furnished the information:
                              it is self-reported. "Self" does not (necessarily) mean that the
                              provider runs on the the monitored endpoint.
                              Self-reported information is generally subject to the
                              Lying Endpoint Problem. (TODO: citation)</t>
                           <t>"Authority" means that the provider got the information,
                              directly or indirectly, from an authority that assigned it. 
                              For example, the producer got an IP-MAC association 
                              from a DHCP server
                              (or was itself the DHCP server).</t>
                           <t>"Observation" means that the provider got the information
                              from observations of network traffic.
                              For example, the producer saw the source address in
                              an IP packet.</t>
                           <t>"Verification" means that the provider has verified
                              the information.
                              For example:<list style="symbols">
                                  <t>The provider does IP communication with the endpoint
                                     and knows the IP address with which it communicates.</t>
                                  <t>The provider makes an SSH connection to the endpoint
                                     and knows the endpoint's public key by virtue of
                                     authenticating it.</t>
                                  <t>The monitored endpoint is a virtual machine and
                                     the provider knows by peeking into it.</t>
                                  </list></t>
                           </list></t>
                        <t>TODO: Explain security considerations and how
                           consumers are meant to use these markings.</t>
                    </section>

                <section title="Whether to Include">
                    <t>When publishing an endpoint attribute assertion,
                       the provider MUST publish at least all common identifying AVPs
                       that it knows through
                       verification.
                       If the provider knows none through verification but it knows at least
                       one in another way, it MUST publish at least one.
                       The provider SHOULD publish all common identifying AVPs it knows.
                       </t>
                    </section>

                <section title="IP Address">

                    <section title="Range of Values">     
                        <t>MUST be an IPv4 or IPv6 address,
                            and optionally a scope string.
                            MUST NOT be a broadcast, multicast, or loopback address.</t>
                        <t>An IPv4 address MUST conform to <xref target="RFC0791"/>,
                            section 3.2.</t>
                        <t>An IPv6 address MUST conform to <xref target="RFC3587"/>.
                           SHOULD NOT be a link-local address.</t>
                        <t>Scope string: an administratively assigned string
                           denoting the IP routing domain.
                           Implementations MUST support this. 
                           Administrators may use it to avoid ambiguity,
                           for example if network address translation (NAT) is in use.</t>
                        <t>ISSUE (Jim Schaad): Scope strings are interesting.
                           However does this imply a potential need to create a new DHCP item so that 
                           it can be sent out to a device for reporting back?
                           Is there such a string already?</t>
                        <t>(Cliff): Scope strings are like administrative-domain in IF-MAP.
                           It would solve many problems if DHCP servers could provide this
                           string to endpoints and to observers.
                           I am not sure whether there is a standard DHCP option that
                           fills the bill or not.
                           I am not sure how easily application software can get
                           the DHCP options from the underlying OS.
                           But this is worth exploring.</t>
                        <t>(Jim): We may need to look at what happens if
                           a scope identifier is either not set or not available.
                           I am thinking of the virtual network that is NATed on my machine.
                           If those VMs reported [on themselves] then the network configuring
                           systems may not know about that VM and there would not 
                           necessarily be a reasonable scope string to report for it.</t>
                        </section>

                    <section title="Meaning">
                        <t>Throughout the time interval of the AVP,
                           the endpoint had the right to use,
                           or was communicating using, the specified IP address.</t>
                        </section>

                    <section title="Relationships">
                        <t>A network profiler might know an endpoint's address
                           and something about the software running on the endpoint.
                           The profiler might know nothing else.
                           So data models MUST support an endpoint attribute assertion
                           relating the IP address to a set of software components.</t>
                        
                        <t>A data model MUST support the following relationships:<list style="symbols">
                            <t>An address is "bound to" a network interface.</t>
                            <t>An address is considered "bound to" an endpoint just if the 
                               address is "bound to" an interface that is "in" the endpoint.</t> 
                            <t>An address may be "in" one or more locations. (DELETE?)</t>
                            </list></t>
                        </section>

                    <section title="Multiplicity">
                        <t>An endpoint attribute assertion MAY contain 
                           one or more IP addresses.</t>
                        <t>An IP address may be used by more than one endpoint at a time,
                           largely because of Network Address Translation (NAT).
                           Where practical, a scope string SHOULD be included,
                           to disambiguate.</t>
                        <t>In practice, an IP address can be used by only one 
                           endpoint in an IP routing domain at a time.</t>
                        </section>

                    <section title="Stability">
                        <t>The stability of IP address assignments varies widely.
                           Some assignments are persistent, some volatile.
                           The time interval of the AVP MUST NOT reach into the future,
                           not even if (for example) the DHCP lease is infinite.</t>
                        </section>

                    <section title="Accuracy">
                        <t>For IP addresses that a provider knows by
                            observation or verification: <list style="symbols">
                            <t>Network Address Translation (NAT, RFC2663) is a pitfall.</t>
                            <t>The provider MUST NOT include an IP address that
                               the provider knows to be a translated address.</t>
                            <t>The provider SHOULD be configurable with
                               a set of IP address blocks to be excluded.
                               Address blocks set aside for NAT devices SHOULD
                               be excluded, by administrators for example.</t>
                            <t>ISSUE: In a later SACM version, it would be good to
                               overcome this, by publishing the association
                               between the internal and external address-port
                               combinations.</t>
                            </list></t>
                         <t>For IP addresses that a provider
                            knows by observation or verification,
                            IP address spoofing is a pitfall.
                            Network administrators SHOULD take countermeasures.
                            Ingress filtering (RFC3704) is one.
                            DHCP snooping is another: many Network Access Devices
                            can confine endpoints to IP addresses assigned
                            by authorized DHCP servers.</t>
                         </section>

                    <section title="Data Model Requirements">
                        <t>All SACM data models MUST support this entire subsection.</t>
                        </section>

                    </section>

                <section title="MAC Address">

                    <t>TODO</t>
                    </section>

                <section title="Hardware Serial Number">

                    <section title="Range of Values">
                        <t>MUST be a vendor ID string and a serial number string string.
                           The vendor ID string MAY be empty, a URI, or a vendor number.</t>
                        </section>
 
                    <section title="Meaning">
                        <t>Throughout the time interval of the AVP,
                           the endpoint had a hardware component by
                           the indicated manufacturer and having the specified serial number.</t>
                        </section>

                    <section title="Multiplicity">
                        <t>An endpoint may have any number of hardware instances,
                           each with a different serial number.
                           An endpoint attribute assertion may contain AVPs
                           for any subset of the
                           hardware instances.</t>

                        <t>Vendors generally ensure that each serial number goes to 
                           only one hardware instance.</t>

                        </section>

                    <section title="Stability">
                        <t>Each hardware component is immutably associated
                           with a hardware serial number.
                           But hardware can be replaced or removed.
                           As endpoint attributes, hardware serial numbers are *persistent*
                           but not *immutable*.</t>
                        </section>

                    <section title="Accuracy">
                        </section>

                    <section title="Data Model Requirements">
                        <t>All SACM data models MUST support this entire subsection.</t>
                        </section>

                    </section>

                <section title="Certificate">
                    <section title="Range of values">
                        <t>MUST be X.509 certificate, per <xref target="RFC5280"/>.</t>
                        </section>

                    <section title="Meaning">
                        <t>Throughout the time interval of the AVP,
                           the endpoint had the private key corresponding to
                           the specified certificate.</t>
                        <t>Throughout the time interval,
                           the certificate was valid: it had a valid
                           certificate chain from a CA certificate that the asserter
                           trusted; every certificate in the chain was time-valid;
                           no certificate in in the chain (excluding the CA certificate)
                           was revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so,
                           would we include the CA certificate as well?</t>
                        </section>

                    <section title="Multiplicity">
                        <t>An endpoint may use, or have the right to use, one or more
                           certificates.</t>

                        <t>Some certificates may be used on more than one endpoint.
                           Other certificates are (by intent) bound to a single endpoint.
                           ISSUE (CEK): Is there a standard way to distinguish the two?
                           We could perhaps provide a configurable criterion,
                           as an information element. Should we?</t>
                        </section>

                    <section title="Stability">
                        <t>Certificates are replaced, due to expiration and other
                           reasons.
                           By and large, they are not replaced often.
                           A year is a typical interval.
                           In sum, they are persistent.</t>
                        <t>A private key is baked into hardware is almost immutable.
                           But again, hardware can be replaced.</t>
                        </section>

                    <section title="Accuracy">
                        <t>If a certificate is known by verification, the attribute
                           is highly accurate.</t>
                        </section>

                    <section title="Data model requirements">
                        <t>All SACM data models MUST support this entire subsection.</t>
                        </section>

                    </section>

                <section title="Public Key">

                    <t>TODO</t>
                    </section>

                <section title="Username?">
                    <t>ISSUE (CEK): If a user certificate can be an identifying attribute,
                       why not a username also?
                       At an earlier stage of our discussions, usernames were
                       considered common identifying attributes.
                       Did we decide they should not be? Or just forget them?</t>
                    <t>Many endpoints do not have client certificates.
                       An authenticated username is a useful clue for identifying
                       such an endpoint.                       
                       I log in only to a handful of personal endpoints.
                       I also present my username and password to many multi-user
                       servers. We would have to distinguish personal endpoints
                       from server endpoints somehow.</t>
                    </section>

                <section title="Tool-Specific Identifier">

                    <t>TODO</t>

                    <t>TODO: "Tool-specific identifier" suggests that two tools could
                       never agree on a tool-specific identifier.
                       But a community may agree on an identifier notation,
                       and might even create a formal standard. 
                       All that's important is that each of these attributes has a type 
                       and meaning *not* specified by the SACM internet drafts. 
                       "Vendor-specific identifier?" "Custom identifier?"
                       </t>

                    </section>

                <section title="Identification of Endpoints where SACM Components Reside">
                    <t>Every information element needs identifying attributes 
                       of its producer's endpoint.
                      (TODO: Provide normative language. SHOULD? MUST?)
                       </t>
                    <t>Specifically, in an endpoint attribute assertion,
                       we need identifying attributes of the asserter's endpoint.
                       If the asserter is external, the assertion will contain 
                       identifying attributes of two endpoints. 
                       (TODO: Discuss what this information is for.)
                       </t>
                    </section>

                <section title="Security Considerations">
                    <t>Effects of misidentification</t>
                    <t>Things that can cause misidentification</t>
                    <t>How minimize misidentification</t>
                    </section>

                </section>
  

            <section title="Software Component">

                <t>An endpoint contains and runs software components.</t>
                
                <t>Relationship:<list style="symbols">
                    <t>If an endpoint has an instance of a software component, we say that the software component is "in" the endpoint. This is a shorthand.</t>
                    </list></t>

                <t>Some software components are assets.
                   "Asset" is defined in RFC4949 <xref target="RFC4949"/> as "a system
                   resource that is (a) required to be protected by an information
                   system's security policy, (b) intended to be protected by a
                   countermeasure, or (c) required for a system's mission."</t>
         
                <t>An examination of software needs to
                   consider both (a) software assets and (b) software that may
                   do harm. A posture attribute collector may not know (a) from (b). It is useful
                   to define Software Component as the union of (a) and (b).</t>
    
                <t>Examples of Software Assets:<list style="symbols">
                    <t>An application</t>
                    <t>A patch</t>
                    <t>The operating system kernel</t>
                    <t>A boot loader</t>
                    <t>Firmware that controls a disk drive</t>
                    <t>A piece of JavaScript found in a web page the user visits</t>
                    </list></t>
    
                <t>Examples of harmful software components:<list style="symbols">
                     <t>A malicious entertainment app</t>  
                     <t>A malicious executable</t>
                     <t>A web page that contains malicious JavaScript</t>
                     <t>A business application that shipped with a virus</t>
                     </list></t>

                  <t>Software components SHOULD be disjoint from each other. In other words,
                      software componennts SHOULD be so defined that 
                      a given byte of software on an endpoint 
                      belongs to only one software component.</t>

                  <t>Different versions of the same piece of software MUST be modeled as
                     different components. Software versioning is not built into the 
                     information model.</t>

                  <t>Each separately installable piece of software SHOULD be modeled as a
                     component. Sometimes it may be better to divide more finely:
                     what an installer installs MAY be modeled as several components.</t> 

                  <t>A data model MAY identify a software component by parts of an ISO SWID tag.</t>

                </section>
    
            <section title="Software Instance">
                <t>Each copy of a piece of software is called a software instance.
                   The configuration of a software instance is regarded
                   as part of the software instance.
                   Configuration can strongly affect security posture.</t>

                <t>A data model MUST support the following relationships:<list style="symbols">
                       <t>A software instance is an "instance of" a software component.</t>
                       <t>A software instance is "in" an endpoint.</t>
                       </list></t>

                <t>A data model MAY use ISO SWID tags to describe software instances.</t>

                </section>

            <section title="Hardware Component">
                 <t>Hardware components may also be assets and/or harmful. For example,
                     a USB port on a system may be disabled to prevent information flow
                     into our out of a particular system; this provides an additional
                     layer of protection that can complement software based protections.
                     Other such assets may include access to or modification of storage
                     media, hardware key stores, microphones and cameras. Like software
                     assets, we can consider these hardware components both from the
                     perspective of (a) an asset that needs protection and (b) an asset
                     that can be compromised in some way to do harm.</t>
                 <t>A data model MAY designate a hardware component by its manufacturer and a part number. </t>
                 </section>

            <section title="Hardware Instance">
                 <t>A hardware instance is just an instance of a particular
                    component.</t>

                 <t>A data model MUST support the following relationships:<list style="symbols">
                     <t>A hardware instance is an "instance of" a hardware component.</t>
                     <t>A hardware instance is "in" an endpoint.</t>
                     </list></t>

                 <t>Hardware instances may need to be modeled because (a) an endpoint may have multiple instances of a hardware component, (b) a hardware instance may be compromised, whereas other instances may remain intact.</t>

                 <t>A data model MAY designate a hardware instance 
                    by its component and a unique serial number.</t>
                 </section>

            <section title="Network Interface">

                <t>An endpoint generally has at least one network interface.</t>

                <t>Interfaces nest. A virtual interface can nest in a physical interface.</t>

                <t>A data model MUST support the following relationships:<list style="symbols">
                    <t>A network interface is "in" an endpoint.</t>
                    <t>A network interface is "in" another network interface; this
                       is for a nested interface. CEK: And this allows representing 
                       compliance policies that are worthwhile. But is this too advanced
                       for the initial set of SACM RFCs?</t> 
                    <t>A network interface "acts for" an identity.
                       This occurs, for example, when the network interface is online
                       because of successful 802.1X.
                       An internal collector may be aware of the identity.
                       An external collector (such as a RADIUS server) will be aware of the identity.</t>
                    </list></t>
                </section>

            <section title="Address">

                <t>TODO: DELETE THIS SECTION. ISSUE (CEK): Do we still want to model
                   layer 4 addresses?</t>
 
                <t>An address SHALL BE any of:<list style="symbols">
                    <t>A layer 2 address; a data model MUST support MAC addresses, 
                       and MAY support others</t>
                    <t>A layer 3 address; a data model MUST support IPv4 and IPv6 
                       addresses, and MAY support others</t>
                    <t>A layer 4 address; a data model MUST support 
                       an IP-address-protocol-port combination, where protocol is TCP or UDP. 
                       It MAY support others</t>
                    </list></t>

                <t>Addresses from other layers may be added in the future.</t>

                <t>These addresses are not necessarily globally unique.
                   Therefore, a data model SHOULD allow an address to be qualified with a scope.<list style="symbols">  

                    <t>A data model SHOULD allow qualifying a MAC address with its 
                        layer-2 broadcast domain. This MAY take the form of a VLAN ID 
                        and an administratively assigned string denoting the LAN.</t> 
                    <t>A data model SHOULD allow qualifying an IP address with an 
                       administratively assigned string denoting the IP routing domain.</t>
                    </list></t>

                <t>A data model MUST support the following relationships:<list style="symbols">
                    <t>An address is "bound to" a network interface.</t>
                    <t>An address is considered "bound to" an endpoint just if the 
                       address is "bound to" an interface that is "in" the endpoint.</t> 
                    <t>An address may be "in" one or more locations.</t>
                    </list></t>
                </section>

            <section title="Identity">

                <t>TODO: delete this section</t>

                <t>An identity is the non-secret part of a credential. Examples are a username,
                   an X.500 distinguished name, and a public key. Passwords, private keys, 
                   and other secrets are not considered part of an identity.</t>

                <t>A data model MUST support the following relationships:<list style="symbols">

                    <t>An endpoint may "act for" an identity.
                       This SHALL mean that the endpoint claims or proves that it has this
                       identity. For example, if the endpoint is part of an
                       Active Directory domain and Alice logs into the endpoint with her
                       AD username (alice) and password, the endpoint "acts for" alice.
                       An endpoint MAY "act for" more than one identity,
                       such as a machine identity and a user identity.</t>

                    <t>A identity may "belong to" an account.
                       For example, an enterprise may have a database
                       that maps identities to accounts.
                       CEK: Is this relevant? I don't see how we'd use the notion
                       of an account in identifying an endpoint or in specifying
                       compliance measurements to be taken.</t>
                    </list></t> 
                </section>

            <section title="Location">

                <t>TODO: Delete this section?</t>
    
                <t>Location can be logical or physical. 
                   Location can be a clue to an endpoint's identity.</t>

                <t>A data model MUST support the following relationships:<list style="symbols">
                    <t>One or more endpoints may be "in" a location</t>
                    <t>A location may be "in" one or more locations</t>
                    <t>A network address may be "in" a location</t>
                    <t>An account may be "in" a location; this would happen 
                       if the account represents a user, and a physical access 
                       control system reports on the user's location</t>
                    </list></t>

                <t>Examples of location:<list style="symbols">
    
                    <t>The switch, access point, VPN gateway, or cell tower to which the endpoint is
                        linked</t>
    
                    <t>The switch port where the endpoint is plugged in</t>
    
                    <t>The location of the endpoint's IP address in the network
                        topology</t>
    
                    <t>The geographic location of the endpoint (which is often
                        self-reported)</t>

                    <t>A user location (may be reported by a physical access control
                        system)</t>
                    </list></t>


                <t>CEK: The last three examples seem too advanced for the first set of SACM RFCs. 
                    I do not know a notation that would be interoperable and 
                    useful for endpoint identification. Should we drop them?</t>

                <t>CEK: If we do drop them, all we have left is the device and port at which the
                   endpoint is linked to the network. Maybe we should regard that as a kind
                   of address.</t>

                <t>A data model MUST support switch + port number, 
                   access point, and VPN gateway as locations. 
                   The other examples are optional.</t>

                <t>More than one of kind of location may pertain to an endpoint. Endpoint has a
                    many-to-many relationship with Location.</t>

                </section>

            <section title="Endpoint">

                <t>An endpoint is the hollow center of the model. An endpoint is an abstract ideal. Any endpoint attribute assertion that mentions an endpoint mentions it by specifying identifying attributes. Even if there is one preferred endpoint identity, that is modeled as an identity. We do not anticipate any AVP whose attribute type is "endpoint".</t>

                </section>

            <section title="Endpoint Attribute Assertion">
                <section title="Form and Precise Meaning">
                    <t>An endpoint attribute assertion has:
                        <list style="symbols">
                            <t>One or more attribute-value pairs (AVPs)</t>
                            <t>Time intervals over which the AVPs hold</t>
                            <t>Endpoint uniquely identified? True or false</t>
                            <t>Provenance, including:
                                <list style="symbols">
                                    <t>The SACM component that made the assertion</t>
                                    <t>Information about the method used to derive the assertion</t> 
                                    </list>
                                </t>
                            </list>
                        </t>
                    <t>It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.</t>
                    <t>If the "Endpoint uniquely identified" is true, the set of attributes-value
                       pairs together make this assertion apply to only one endpoint.</t>
                    <t>The attributes can include posture attributes and
                                identification attributes. The model does not make a 
                                rigid distinction between the two uses of attributes.</t>
                    <t>Some of the attributes may be multi-valued.
                        </t>
                    <t>One of the AVPs may be a unique endpoint identifier. 
                       Not every endpoint will have one. If there is one, the SACM component that produces
                       the Endpoint Attribute Assertion will not necessarily know what it is.</t>
                    </section>

                <section title="Asserter">
                    <t>An Endpoint Attribute Assertion may come from an 
                       attribute collector or an evaluator. It may come from a SACM component that derives 
                       it from out-of-band sources, such as
                       a physical inventory system. A SACM component may derive it
                       from other Endpoint Attribute Assertions.</t>
                    </section>

                <section title="Example">
                    <t> For example, an attribute assertion might have these attribute-value pairs:<list>
                       <t>mac-address = 01:23:45:67:89:ab</t>
                       <t>os = OS X</t>
                       <t>os-version = 10.6.8</t>
                       </list></t>
                    <t>This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran OS X 10.6.8 throughout the specified time interval. A profiler might have provided this assertion.</t>
                    </section>

                <section title="A Use Case">
                    <t>For example, Endpoint Attribute Assertions should help SACM components to track an endpoint as it roams or stays stationary. They must track endpoints because they must track endpoints' postures over time. Tracking of an endpoint can employ many clues, such as:<list>
                        <t>The endpoint's MAC address</t>
                        <t>The authenticated identity (even if it identifies a user)</t>
                        <t>The location of the endpoint and the user</t>
                        </list></t>
                   </section>

                <section title="Event">
                      
                    <t>An event is represented as a Posture Attribute Assertion
                       whose time interval has length zero.</t>
    
                    <t>Some potential kinds of events are:<list style="symbols">
                        <t>A structured syslog message <xref target="RFC5424"/></t>
                        <t>IF-MAP event metadata <xref
                           target="TNC-IF-MAP-NETSEC-METADATA"/></t>
                        <t>A NetFlow message <xref target="RFC3954"/></t>
                        </list></t>
                    </section>

                <section title="Difference between Attribute and Event">
    
                    <t>Author: Henk Birkholz</t>
                      
                    <t>"Attribute" and "event" are often used fairly interchangeably. A
                       clear distinction makes the words more useful.</t>
                    <t>An *attribute* tends not to change until something causes a change. In
                       contrast, an *event* occurs at a moment in time.</t>
                    <t>For a nontechnical example, let us consider "openness" as an attribute of a door, with two values, "open" and "closed". A
                       closed door tends to stay closed until something opens it (a breeze,
                       a person, or a dog).</t>
                    <t>The door's opening or closing is an event.</t>
                    <t>Similarly, "Host firewall enabled" may be modeled as a  true/false attribute of an endpoint. 
                       Enabling or disabling the host firewall may be modeled as
                       an event. An endpoint's crashing also may be modeled as an
                       event.</t>

                    <t>Although events are not attributes, 
                       we use one kind of information element, 
                       the "Endpoint Attribute Assertion",
                       to describe both attributes and events.</t>

                    </section>
                </section> <!-- Endpoint Attribute Assertion -->

            <section title="Attribute-Value Pair">
                <t>The set of attribute types must be extensible, by other IETF standards, by other standards groups, and by vendors. How to express attribute types is not defined here, but is left to data models.</t>

                <t>The value may be structured. For example, it may something like XML.</t>

                <t>The information model requires a standard attribute type (or possibly more than one) for each box in 
 <xref target="figure-model-of-endpoint"/>:
                <list style="symbols">
                    <t>Hardware Component: the value identifies the hardware type. For example, it may consist of the make and model number.</t>
                    <t>Hardware Instance: the value, together with the Hardware Component value, uniquely identifies the hardware instance. For example, it may be a manufacturer-assigned
   serial number. This notion might not apply to all virtual hardware components.</t>
                    <t>Software Component: the value identifies a unit of software. Each
                       installable piece of software should be separately identifiable.
                       For example, this might be a Software Identifier (SWID). Therefore, a software inventory for an endpoint should be expressed as an Endpoint Attribute Assertion.</t>
                    <t>Software Instance: the value describes how the software component is installed and configured.</t>
                    <t>Endpoint: The value is a unique endpoint identifier.</t>
                    <t>Location</t>
                    <t>Identity: The value is the non-secret part of a credential.
                       For example, it may be a certificate, or just a subject Distinguished Name extracted from a certificate. It may be a username.</t>
                    <t>Network Interface: TBD</t>
                    <t>User: [cek: Do we want this? If one user uses different 
                       credentials at different times, do we think SACM components
                       will need know that it's the same user?]</t>
                    <t>Address: The value is an IP, MAC, or other network address,
                       possibly qualified with its scope.</t>
                    </list></t>

                <section title="Unique Endpoint Identifier">
                    <t>An organization should try to uniquely identify and label an endpoint, whether the endpoint is enrolled or is discovered in the operational environment. The identifier should be assigned by or used in the enrollment process. </t>
                    <t>Here "unique" means one-to-one. In practice, uniqueness is not always attainable. Even if an endpoint has a unique identifier, an attribute collector may not always know it.</t> 

                    <t>If the attribute type of an AVP is "endpoint", the value
                       is a unique identifier of the endpoint.</t>
                    </section>
    
                <section title="Posture Attribute">
    
                    <t>Some AVPs will be posture attributes.</t>

                    <t>See the definition in the SACM Terminology for Security Assessment
                       <xref target="I-D.ietf-sacm-terminology"/>.</t>
    
                    <t>Some potential kinds of posture attributes are:<list style="symbols">
                        <t>A NEA posture attribute (PA) <xref target="RFC5209"/></t>
                        <t>A YANG model <xref target="RFC6020"/></t>
                        <t>An IF-MAP device-characteristics metadata item <xref
                           target="TNC-IF-MAP-NETSEC-METADATA"/></t>
                        </list></t>
                    </section>
                </section>

            <section title="Evaluation Result">
    
                <t>Evaluation Results (see <xref
                   target="I-D.ietf-sacm-terminology"/>) are modeled as Endpoint Attribute Assertions.</t>

                <t>An Evaluation
                   Result derives from one or more other Endpoint Attribute Assertions.</t>

                <t>An example is: a NEA access recommendation <xref target="RFC5793"/></t>
    
                <t>An evaluator may be able to evaluate better if history is
                   available. This is a use case for retaining Endpoint Attribute Assertions for a time.</t>

                <t>An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. (<xref
                   target="figure-model-of-endpoint"/> does not show this.)               In the
                   limiting case, Endpoint Attribute Assertions are not retained. When  
                   as an Endpoint Attribute Assertion arrives, an evaluator produces
                   an Evaluation Result. These mechanics are out of the scope of the Information Model.</t>
                </section>

            <section title="Report">

                <t>ISSUE (CEK): Should we take modeling of reports out of scope?
                   It is clear that reports are needed.
                   But is a *standard* for reports needed, and does it
                   deserve our priority?</t>

                <t>An Endpoint Attribute Assertion concerns a single endpoint.
                   Assertions about a set of endpoints are also needed -- for example, for trend analysis and for reports read by humans. These assertions are termed "reports". SACM components will consume Endpoint Attribute Assertions
and generate reports.</t>

                <t>A report contains its provenance, with the same form and meaning
                   as the provenance of an Endpoint Attribute Assertion.</t>
    
                <t>A Report summarizes:<list style="symbols">
                    <t>Endpoint Attribute Assertions, which may include Evaluation Results</t>
                    <t>Other Reports</t>
                    </list></t>

                 <t>A Report may routine or ad hoc.</t>
                 <t>Some reports may be machine readable. Machine readable reports may be
                    consumable by SACM components and by automatic response systems (not specified by SACM).</t>
                 </section>

            <section title="SACM Component">
                <t>Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them?</t>

                <t>ISSUE (CEK): Why do we need information elements that model SACM compoments?</t>

                <section title="External Attribute Collector">
    
                    <t>An external collector is a collector 
                       that observes endpoints from
                       outside. [kkw-many of these [collectors] are 
                       actually configured and operated to manage assets for reasons other
                       than posture assessments. it is critical to bring them into this, so
                       i like it...but does it matter if the [collector] isn't intended to support
                       posture assessment, but happens to have information that can be
                       used by posture assessment collection consumers? do we lump them
                       together with collectors that are intended to support posture
                       assessment but run external to the endpoint?]
                       [jmf: ditto. The exampled below are of things that would perform external collection].                      
                       </t>

                   <t>[cek-to kkw's comment, I think the purpose here is to capture their
                       contribution to continuous monitoring. I don't see the need to separate
                       things whose primary job is monitoring from things whose primary job is
                       something else. Is there a need?]</t>
                   <t>[cek-to jmf's comment, that is what they are examples of; is a text
                       change needed?]</t>
    
                   <t>Examples:<list style="symbols">
    
                       <t>A RADIUS server whereby an endpoint has logged onto the
                          network</t>
                       <t>A network profiling system, which discovers and classifies
                          network nodes</t>
                       <t>A Network Intrusion Detection System (NIDS) sensor</t>
                       <t>A vulnerability scanner</t>
                       <t>A hypervisor that peeks into the endpoint, the endpoint being a
                          virtual machine</t>
                       <t>A management system that configures and installs software on the
                          endpoint</t>
                       </list></t>
                    </section>

                <section title="Evaluator">
                    <t>An evaluator can consume
                       endpoint attribute assertions, previous evaluations of posture attributes,
                       or previous reports of evaluation results. [kkw-i don't think this
                       conflicts with the definition in the terminology doc re: that
                       evaluation tasks evaluate posture attributes.]</t>
                    <t>[cek-I like the change. I think it *does* require a change in the terminology doc, though.]</t>

                    <t>Example: a NEA posture validator <xref target="RFC5209"/></t>
                    <t>[jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?]</t>
                    <t>[cek-Why isn't a NEA posture validator an example?]</t>
                    </section>

                <section title="Report Generator">
                    <t>A report generator makes reports based on:<list style="symbols">
                        <t>Endpoint Attribute Assertions, including Evaluation Results</t>
                        <t>Other Reports (a weekly report may be created from daily
                            reports)</t>
                        </list></t>
                    <t>It may summarize data continually, as the data arrives. It also may    
                       summarize data in response to an ad hoc query.</t>
                    </section>
                </section>

            <section title="Organization?">
                <t>[kkw-from a reporting standpoint there needs to be
                   some concept like organization or system. without this, there is no
                   way to produce result reports that can be acted upon to provide the
                   insight or accountability that almost all continuous monitoring
                   instances are trying to achieve. from a scoring or grading 
                   standpoint, an endpoint needs to be associated with exactly one
                   organization or system. it can have a many to many relationship
                   with other types of results reporting "bins". is this important
                   to include here? we had organization as a core asset type for this
                   reason, so i think it is a key information element. but i also
                   know that i do not want to define all the different reporting
                   types, so i am unsure.]</t>

                <t>[cek-I had not thought of this at all. Would it make sense to treat the organization and the bins 
                   as part of the guidance for creating reports? Maybe not. We should discuss.]</t>
                </section>

            <section title="Guidance">
                <t>[jmf- the guidance sections need more detail. . .]</t>
                <t>[cek - What is missing? We would welcome a critique or text.]</t>
                <t>Guidance is generally configurable by human administrators.</t>
    
                <section title="Internal Collection Guidance">
                    <t>An internal collector may need guidance to govern what it
                       collects and when.</t>
                    </section>
                <section title="External Collection Guidance">
                     <t>An external collector may need guidance to govern what it
                        collects and when.</t>
                    </section>
                <section title="Evaluation Guidance">
                    <t>An evaluator typically needs Evaluation Guidance to govern
                       what it considers to be a good or bad security posture.</t>
                    </section>
                <section title="Retention Guidance">
                    <t>A SACM deployment may retain posture attributes, events, or
                       evaluation results for some time. Retention supports ad hoc
                       reporting and other use cases.</t>
                    <t>If information is retained, retention guidance controls what is
                       retained and for how long.</t>
                    <t>If two or more pieces of retention guidance apply to a piece of information,
                       the guidance calling for the longest retention should take
                       precedence.</t>
                    </section>
                <section title="Reporting Guidance">
                    <t>A Report Generator typically needs Reporting Guidance to govern the
                       reports it generates.</t>
                    </section>
                </section>

            <section title="Provenance of Information">
                <t>Each Endpoint Attribute Assertion and Report needs to be
                   labeled with its provenance.</t>
                </section>
  
            <section title="Endpoint">
    
                            <t>See the definition in the SACM Terminology for Security Assessment <xref
                                    target="I-D.ietf-sacm-terminology"/>.</t>
    
                            <t>In the model, an endpoint can be part of another endpoint. 
                            This covers cases where multiple physical endpoints act as one endpoint. The constituent endpoints may not be distinguishable by external observation of network behavior.</t>
                            <t>For example, a hosting center may maintain a redundant set (redundancy group) of 
multi-chassis setups to provide active redundancy and load distribution 
on network paths to WAN gateways. Multi-chassis link aggregation 
groups make the chassis appear as one endpoint. 
Traditional security controls must be applied either to 
physical endpoints or the redundancy groups they compose (and 
occasionally both). Loss of redundancy is difficult to detect or 
mitigate without specific posture information about the current state of 
redundancy groups. Even if a physical endpoint (e.g. router) that is 
part of a redundancy group is replaced, the redundancy group can remain 
the same.
                               </t>

                <section title="Endpoint Identity">
    
                                <t>An endpoint identity provides both identification and
                                    authentication of the endpoint. For example, an identity may be an
                                    X.509 certificate <xref target="RFC5280"/> and corresponding private
                                    key. 
                                    [jmf- this example should be formatted like the other examples in this section]
                                </t>
    
                                <t>Not all kinds of identities are guaranteed to be unique.</t>
                    </section>

                <section title="Software Component">
    
                                <t>An endpoint contains and runs software components.</t>
    
                                <t>Some of the software components are assets.
                                   "Asset" is defined in RFC4949 <xref target="RFC4949"/> as "a system
                                    resource that is (a) required to be protected by an information
                                    system's security policy, (b) intended to be protected by a
                                    countermeasure, or (c) required for a system's mission."</t>
        
                                <t>An examination of software needs to
                                    consider both (a) software assets and (b) software that may
                                    do harm. A posture attribute collector may not know (a) from (b). It is useful
                                    to define Software Component as the union of (a) and (b).</t>
    
                                <t>Examples of Software Assets:<list style="symbols">
                                        <t>An application</t>
    
                                        <t>A patch</t>
    
                                        <t>The operating system kernel</t>
    
                                        <t>A boot loader</t>
    
                                        <t>Firmware that controls a disk drive</t>
    
                                        <t>A piece of JavaScript found in a web page the user visits</t>
                                    </list></t>
    
                                <t>Examples of harmful software components:<list style="symbols">
                                        <t>A malicious entertainment app</t>
    
                                        <t>A malicious executable</t>
                                        <t>A web page that contains malicious JavaScript</t>
    
                                        <t>A business application that shipped with a virus</t>
                                    </list></t>
        
                    <section title="Unique Software Identifier">
                                     <t>Organizations need to be able to uniquely identify and label software installed or run on an endpoint. Specifically, they need to know the name, publisher, unique ID, and version; and any related patches. In some cases the software's identity might be known a priori by the organization; in other cases, a software identity might be first detected by an organization when the software is first inventoried in an operational environment. Due to this, it is important that an organization have a stable and consistent means to identify software found during collection.</t>

                                <t>A piece of software may have a unique identifier, such as a SWID tag
                                    (ISO/IEC 19770).</t>
                        </section>
                    </section>

                </section> <!-- endpoint -->

            <section title="User">
    
                <section title="User Identity">
    
                      <t>An endpoint is often - but not always - associated with one or more
                         users.</t>
    
                      <t>A user's identity provides both identification and authentication
                         of the user. @@@ Eh?</t>
                     </section>
                </section>

            </section>

        <section title="SACM Usage Scenario Example">
            
            <t>TODO: this section needs to refer out to wherever the operations / generalized workflow
                content ends up</t>
            <t>TODO: revise to eliminate graph references</t>

            <t>This section illustrates the proposed SACM Information Model as applied to
                SACM Usage Scenario 2.2.3, Detection of Posture Deviations <xref
                    target="I-D.ietf-sacm-use-cases"/>. The following subsections describe the
                elements (components and elements), graph model, and operations (sample workflow)
                required to support the Detection of Posture Deviations scenario.</t>

                    <t>The Detection of Posture Deviations scenario involves multiple elements
                        interacting to accomplish the goals of the scenario. <xref target="figure-model-of-endpoint"/> illustrates those elements along with their major communication paths.</t>

            <section title="Graph Model for Detection of Posture Deviation">
                <t>The following subsections contain examples of identifiers and metadata which
                    would enable detection of posture deviation. These lists are by no means
                    exhaustive - many other types of metadata would be enumerated in a data model
                    that fully addressed this usage scenario.</t>

                <section title="Components">

                    <t>The proposed SACM Information Model contains three components, as defined in
                        the SACM Architecture <xref target="I-D.ietf-sacm-architecture"/>:
                        Posture Attribute Information Provider, Posture Attribute Information
                        Consumer, and Control Plane.</t>
                    
                    <t>In this example, the components are instantiated as follows:<list style="symbols">

                            <t>The Posture Attribute Information Provider is an endpoint security
                                service which monitors the compliance state of the endpoint and
                                reports any deviations for the expected posture.</t>

                            <t>The Posture Attribute Information Consumer is an analytics engine
                                which absorbs information from around the network and generates a
                                "heat map" of which areas in the network are seeing unusually high
                                rates of posture deviations.</t>

                            <t>The Control Plane is a security automation broker which receives
                                subscription requests from the analytics engine and authorizes
                                access to appropriate information from the endpoint security
                                service.</t>
                        </list></t>
                </section>

                <section title="Identifiers">

                    <t>To represent the elements listed above, the set of identifiers might include
                        (but is not limited to):<list style="symbols">
                            <t>Identity - a device itself, or a user operating a device, categorized
                                by type of identity (e.g. username or X.509 certificate <xref
                                    target="RFC5280"/>)</t>
                            <t>Software asset</t>
                            <t>Network Session</t>
                            <t>Address - categorized by type of address (e.g. MAC address, IP
                                address, Host Identity Protocol (HIP) Host Identity Tag (HIT) <xref
                                    target="RFC5201"/>, etc.)</t>
                            <t>Task - categorized by type of task (e.g. internal collector,
                                external collector, evaluator, or reporting task)</t>
                            <t>Result - categorized by type of result (e.g. evaluation result or
                                report)</t>
                            <t>Guidance</t>
                        </list></t>
                </section>
                <section title="Metadata">

                    <t>To characterize the elements listed above, the set of metadata types might
                        include (but is not limited to):<list style="symbols">
                            <t>Authorization metadata attached to an identity identifier, or to a
                                link between a network session identifier and an identity
                                identifier, or to a link between a network session identifier and an
                                address identifier.</t>
                            <t>Location metadata attached to a link between a network session
                                identifier and an address identifier.</t>
                            <t>Event metadata attached to an address identifier or an identity
                                identifier of an endpoint, which would be made available to
                                interested parties at the time of publication, but not stored
                                long-term. For example, when a user disables
                                required security software, an internal collector associated with
                                an endpoint security service might publish guidance violation event
                                metadata attached to the identity identifier of the endpoint, to notify consumers of the
                                change in endpoint state.</t>
                            <t>Posture attribute metadata attached to an identity identifier of an
                                endpoint. For example, when required security software
                                is not running, an internal collector associated with
                                an endpoint security service might publish posture attribute
                                metadata attached to the identity identifier of the endpoint, 
                                to notify consumers of the
                                current state of the endpoint.</t>
                        </list></t>
                </section>
                <section title="Relationships between Identifiers and Metadata">
                    <t>Interaction between multiple sets of identifiers and metadata lead to some
                        fairly common patterns, or "constellations", of metadata. For example, an
                        authenticated-session metadata constellation might include a central network
                        session with authorizations and location attached, and links to a user
                        identity, an endpoint identity, a MAC address, an IP address, and the
                        identity of the policy server that authorized the session, for the duration
                        of the network session.</t>
                    <t>These constellations may be independent of each other, or one constellation
                        may be connected to another. For example, an authenticated-session metadata
                        constellation may be created when a user connects an endpoint to the
                        network; separately, an endpoint- posture metadata constellation may be
                        created when an endpoint security system and other collectors gather
                        and publish posture information related to an endpoint. These two
                        constellations are not necessarily connected to each other, but may be
                        joined if the component publishing the authenticated-session metadata
                        constellation is able to link the network session identifier to the identity
                        identifier of the endpoint.</t>
                </section>
            </section>
            <section title="Workflow">
                <t>The workflow for exchange of information supporting detection of posture
                    deviation, using a standard publish/subscribe/query transport model such as
                    available with IF-MAP <xref target="TNC-IF-MAP-SOAP-Binding"/> or XMPP-Grid
                        <xref target="I-D.salowey-sacm-xmpp-grid"/>, is as follows:<list
                        style="numbers">
                        <t>The analytics engine (Posture Assessment Information Consumer)
                            establishes connectivity and authorization with the transport fabric,
                            and subscribes to updates on posture deviations.</t>
                        <t>The endpoint security service (Posture Assessment Information Provider)
                            requests connection to the transport fabric.</t>
                        <t>Transport fabric authenticates and establishes authorized privileges
                            (e.g. privilege to publish and/or subscribe to security data) for the
                            requesting components.</t>
                        <t>The endpoint security service evaluates the endpoint, detects posture
                            deviation, and publishes information on the posture deviation.</t>
                        <t>The transport fabric notifies the analytics engine, based on its
                            subscription of the new posture deviation information.</t>
                    </list></t>
                <t>Other components, such as access control policy servers or remediation systems,
                    may also consume the posture deviation information provided by the endpoint
                    security service.</t>
            </section>
        </section>


        <section anchor="Acknowledgements" title="Acknowledgements">
            <t>Many of the specifications in this document have been developed in a public-private
                partnership with vendors and end-users. The hard work of the SCAP community is
                appreciated in advancing these efforts to their current level of adoption.</t>
            <t>Over the course of developing the initial draft, Brant Cheikes, Matt Hansbury, Daniel
                Haynes, Scott Pope, Charles Schmidt, and Steve Venema have contributed text to many sections of this
                document.</t>
            
            <section anchor="contributors" title="Contributors">

                <t>The RFC guidelines no longer allow RFCs to be published with a large number of authors.
                Some additional authors contributed to specific sections of this document; their names are
                listed in the individual section headings as well as alphabetically listed with their
                affiliations below.</t>

                <texttable>
                    <ttcol align='left'>Name</ttcol>
                    <ttcol align='left'>Affiliation</ttcol>
                    <ttcol align='left'>Contact</ttcol>
                    <c>Henk Birkholz</c>
                    <c>Fraunhofer SIT</c>
                    <c>henk.birkholz@sit.fraunhofer.de</c>
                </texttable>
            </section>
        </section>

        <section anchor="IANA" title="IANA Considerations">
            <t>This memo includes no request to IANA.</t>
        </section>

        <section title="Security Considerations" anchor="Security">
            <t>Posture Assessments need to be performed in a safe and secure manner. In that regard,
                there are multiple aspects of security that apply to the communications between
                components as well as the capabilities themselves. Due to time constraints, this
                information model only contains an initial listing of items that need to be
                considered with respect to security. This list is not exhaustive, and will need to
                be augmented as the model continues to be developed/refined.</t>

            <t>Initial list of security considerations include:<list style="hanging" hangIndent="8">
                    <t hangText="Authentication:">Every component and asset needs to be able to
                        identify itself and verify the identity of other components and assets.</t>
                    <t hangText="Confidentiality:">Communications between components need to be
                        protected from eavesdropping or unauthorized collection. Some communications
                        between components and assets may need to be protected as well.</t>
                    <t hangText="Integrity:">The information exchanged between components needs to
                        be protected from modification. some exchanges between assets and components
                        will also have this requirement.</t>
                    <t hangText="Restricted Access:">Access to the information collected, evaluated,
                        reported, and stored should only be viewable/consumable to authenticated and
                        authorized entities.</t>
                </list></t>

            <!-- EDIT: begin TNC -->
            <t>The TNC IF-MAP Binding for SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/> and TNC
                IF-MAP Metadata for Network Security <xref target="TNC-IF-MAP-NETSEC-METADATA"/>
                document security considerations for sharing information via security automation.
                Most, and possibly all, of these considerations also apply to information shared via
                this proposed information model.</t>
            <!-- EDIT: end TNC -->
        </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"?-->
            &RFC0791; &RFC2119; &RFC3587; &RFC5280;</references>

        <references title="Informative References">
            <!-- Here we use entities that we defined at the beginning. --> &RFC3411; &RFC3416;
            &RFC3418; &RFC3444; &RFC3580; &RFC3954; &RFC4287; &RFC4949; &RFC5201; &RFC5209;
            &RFC5424; &RFC5792; &RFC5793; &RFC6020; &RFC6241; &RFC6876; &RFC7171;
            
            &I-D.ietf-sacm-use-cases;
            &I-D.ietf-sacm-requirements; &I-D.ietf-sacm-terminology;
            &I-D.ietf-sacm-architecture;
            &I-D.salowey-sacm-xmpp-grid;

            &W3C.REC-rdf11-concepts-20140225;
            &W3C.REC-soap12-part1-20070427;

            <reference
                anchor="IM-LIAISON-STATEMENT-NIST"
                target="http://datatracker.ietf.org/liaison/1329/">
                <front>
                    <title>Liaison Statement: Call for Contributions for the SACM Information Model
                        to NIST</title>
                    <author fullname="Adam W. Montville" surname="Montville" initials="A.">
                        <address>
                            <email>adam@stoicsecurity.com</email>
                        </address>
                    </author>
                    <date year="2014" month="May" day="21"/>
                </front>
            </reference>
            <reference anchor="NISTIR-7693"
                target="http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf">
                <front>
                    <title abbrev="Asset identification Specification v1.1">Specification for Asset
                        Identification 1.1</title>
                    <author fullname="John Wunder" surname="Wunder" initials="J."/>
                    <author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <date month="June" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7693"/>
            </reference>
            <reference anchor="NISTIR-7694"
                target="http://csrc.nist.gov/publications/nistir/ir7694/NISTIR-7694.pdf">
                <front>
                    <title abbrev="Asset Reporting Format v1.1">Specification for the Asset
                        Reporting Format 1.1</title>
                    <author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Mark Johnson" surname="Johnson" initials="M."/>
                    <date month="June" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7694"/>
            </reference>
            <reference anchor="CPE-WEBSITE" target="http://scap.nist.gov/specifications/cpe/">
                <front>
                    <title>Common Platform Enumeration</title>
                    <author>
                        <organization abbrev="NIST">The National Institute of Standards and
                            Technology</organization>
                    </author>
                    <date year="2014"/>
                </front>
            </reference>
            <reference anchor="SP800-117" target="http://csrc.nist.gov/publications/drafts/800-117-R1/Draft-SP800-117-r1.pdf">
                <front>
                    <title abbrev="SCAP 1.2 Overview">Guide to Adopting and Using the Security Content Automation Protocol (SCAP) Version 1.2</title>
                    <author fullname="Stephen Quinn" surname="Quinn" initials="S."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <date month="January" year="2012"/>
                </front>
                <seriesInfo name="SP" value="800-117"/>
            </reference>
            <reference anchor="SP800-126" target="http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf">
                <front>
                    <title abbrev="SCAP 1.2 Specification">The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2</title>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Stephen Quinn" surname="Quinn" initials="S."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
                    <date month="September" year="2011"/>
                </front>
                <seriesInfo name="SP" value="800-126"/>
            </reference>
            <reference anchor="NISTIR-7275"
                target="http://csrc.nist.gov/publications/nistir/ir7275-rev4/nistir-7275r4_updated-march-2012_clean.pdf">
                <front>
                    <title abbrev="XCCDF v1.2">Specification for the Extensible Configuration
                        Checklist Description Format (XCCDF) Version 1.2</title>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Charles Schmidt" surname="Schmidt" initials="C."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <author fullname="Neal Ziring" surname="Ziring" initials="N."/>
                    <date month="March" year="2013"/>
                </front>
                <seriesInfo name="NISTIR" value="7275r4"/>
            </reference>
            <reference anchor="NISTIR-7695"
                target="http://csrc.nist.gov/publications/nistir/ir7695/NISTIR-7695-CPE-Naming.pdf">
                <front>
                    <title abbrev="CPE Naming v2.3">Common Platform Enumeration: Naming
                        Specification Version 2.3</title>
                    <author fullname="Brant A. Cheikes" surname="Cheikes" initials="B.A."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <date month="August" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7695"/>
            </reference>
            <reference anchor="NISTIR-7696"
                target="http://csrc.nist.gov/publications/nistir/ir7696/NISTIR-7696-CPE-Matching.pdf">
                <front>
                    <title abbrev="CPE Name Matching v2.3">Common Platform Enumeration: Name
                        Matching Specification Version 2.3</title>
                    <author fullname="Mary C. Parmelee" surname="Parmelee" initials="M.C."/>
                    <author fullname="Harold Booth" surname="Booth" initials="H."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <date month="August" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7696"/>
            </reference>
            <reference anchor="NISTIR-7697"
                target="http://csrc.nist.gov/publications/nistir/ir7697/NISTIR-7697-CPE-Dictionary.pdf">
                <front>
                    <title abbrev="CPE Dictionary v2.3">Common Platform Enumeration: Dictionary
                        Specification Version 2.3</title>
                    <author fullname="Paul Cichonski" surname="Cichonski" initials="P."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <date month="August" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7697"/>
            </reference>
            <reference anchor="NISTIR-7698"
                target="http://csrc.nist.gov/publications/nistir/ir7698/NISTIR-7698-CPE-Language.pdf">
                <front>
                    <title abbrev="CPE Dictionary v2.3">Common Platform Enumeration: Applicability
                        Language Specification Version 2.3</title>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <author fullname="Paul Cichonski" surname="Cichonski" initials="P."/>
                    <author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
                    <date month="August" year="2011"/>
                </front>
                <seriesInfo name="NISTIR" value="7698"/>
            </reference>
            <reference anchor="NISTIR-7848"
                target="http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nistir_7848.pdf">
                <front>
                    <title abbrev="ASR v1.0">Specification for the Asset Summary Reporting Format
                        1.0</title>
                    <author fullname="Mark Davidson" surname="Davidson" initials="M."/>
                    <author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
                    <author fullname="David Waltermire" surname="Waltermire" initials="D."/>
                    <date month="May" year="2012"/>
                </front>
                <seriesInfo name="NISTIR" value="7848"/>
            </reference>
            <reference anchor="ISO.19770-2">
                <front>
                    <title abbrev="ISO/IEC 19770-2:2009">Information technology -- Software asset
                        management -- Part 2: Software identification tag</title>
                    <author/>
                    <date year="2009"/>
                </front>
                <seriesInfo name="ISO/IEC" value="19770-2"/>
            </reference>
            <reference anchor="ISO.18180"
                target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c061713_ISO_IEC_18180_2013.zip">
                <front>
                    <title abbrev="ISO/IEC 18180:2013">Information technology -- Specification for
                        the Extensible Configuration Checklist Description Format (XCCDF) Version
                        1.2</title>
                    <author/>
                    <date year="2013"/>
                </front>
                <seriesInfo name="ISO/IEC" value="18180"/>
            </reference>
            <reference anchor="CCE" target="http://nvd.nist.gov/CCE/">
                <front>
                    <title>Common Configuration Enumeration</title>
                    <author>
                        <organization abbrev="NIST">The National Institute of Standards and
                            Technology</organization>
                    </author>
                    <date year="2014"/>
                </front>
            </reference>
            <reference anchor="CCI" target="http://iase.disa.mil/cci/">
                <front>
                    <title>Control Correlation Identifier</title>
                    <author>
                        <organization abbrev="DISA">United States Department of Defense Defense
                            Information Systems Agency</organization>
                    </author>
                    <date year="2014"/>
                </front>
            </reference>
            <reference anchor="OVAL-LANGUAGE"
                target="https://oval.mitre.org/language/version5.10.1/">
                <front>
                    <title>The OVAL Language Specification version 5.10.1</title>
                    <author fullname="Jonathan Baker" surname="Baker" initials="J.">
                        <organization>The MITRE Corporation</organization>
                    </author>
                    <author fullname="Matthew Hansbury" surname="Hansbury" initials="M.">
                        <organization>The MITRE Corporation</organization>
                    </author>
                    <author fullname="Daniel Haynes" surname="Haynes" initials="D.">
                        <organization>The MITRE Corporation</organization>
                    </author>
                    <date day="20" month="January" year="2012"/>
                </front>
            </reference>
            <reference anchor="CVE-WEBSITE" target="http://cve.mitre.org/about/">
                <front>
                    <title>Common Vulnerabilities and Exposures</title>
                    <author>
                        <organization abbrev="MITRE">The MITRE Corporation</organization>
                    </author>
                    <date year="2014"/>
                </front>
            </reference>

            <reference anchor="UML">
                <front>
                    <title abbrev="UML v2.4.1">"Unified Modeling Language TM (UML (R))", Version 2.4.1</title>
                    <author>
                        <organization abbrev="OMG">Object Management Group</organization>
                    </author>
                    <date month="August" year="2011"/>
                </front>
            </reference>

            <reference anchor="TNC-Architecture">
                <front>
                    <title abbrev="TNC Architecture v1.5">"TNC Architecture", Specification Version 1.5</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2012"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-M-TLV-Binding">
                <front>
                    <title abbrev="TNC IF-M: TLV Binding v1.0">"TNC IF-M: TLV Binding", Specification Version 1.0</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2014"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-TNCCS-TLV-Binding">
                <front>
                    <title abbrev="TNC IF-TNCCS: TLV Binding v2.0">"TNC IF-TNCCS: TLV Binding", Specification Version 2.0</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2014"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-T-Tunneled-EAP">
                <front>
                    <title abbrev="TNC IF-T Tunneled EAP v2.0">"TNC IF-T: Protocol Bindings for Tunneled EAP Methods", Specification Version 2.0</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2014"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-T-TLS">
                <front>
                    <title abbrev="TNC IF-T: TLS Binding v2.0">"TNC IF-T: Binding to TLS", Specification Version 2.0</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="February" year="2013"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-MAP-SOAP-Binding">
                <front>
                    <title abbrev="TNC IF-MAP: SOAP Binding v2.2">"TNC IF-MAP Binding for SOAP", Specification Version 2.2</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="March" year="2014"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-MAP-NETSEC-METADATA">
                <front>
                    <title abbrev="TNC IF-MAP: Network Security Metadata v1.1">"TNC IF-MAP Metadata for Network Security", Specification Version 1.1</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2012"/>
                </front>
            </reference>
            
            <reference anchor="TNC-IF-MAP-ICS-METADATA">
                <front>
                    <title abbrev="TNC IF-MAP: ICS Security Metadata v1.0">"TNC IF-MAP Metadata for ICS Security", Specification Version 1.0</title>
                    <author>
                        <organization abbrev="TCG">Trusted Computing Group</organization>
                    </author>
                    <date month="May" year="2014"/>
                </front>
            </reference>
            
        </references>
        <section title="Security Automation with TNC IF-MAP">
            
            <section title="What is Trusted Network Connect?">
                
                <t>Trusted Network Connect (TNC) is a vendor-neutral open architecture <xref
                    target="TNC-Architecture"/> and a set of open standards for network security
                    developed by the Trusted Computing Group (TCG). TNC standards integrate security
                    components across end user systems, servers, and network infrastructure devices
                    into an intelligent, responsive, coordinated defense. TNC standards have been
                    widely adopted by vendors and customers; the TNC endpoint assessment protocols
                    <xref target="TNC-IF-M-TLV-Binding"/><xref target="TNC-IF-TNCCS-TLV-Binding"
                    /><xref target="TNC-IF-T-Tunneled-EAP"/><xref target="TNC-IF-T-TLS"/> were
                    used as the base for the IETF NEA RFCs <xref target="RFC5792"/><xref
                        target="RFC5793"/><xref target="RFC7171"/><xref target="RFC6876"/>.</t>
                
                <t>Traditional information security architectures have separate silos for endpoint
                    security, network security, server security, physical security, etc. The TNC
                    architecture enables the integration and categorization of security telemetry
                    sources via the information model contained in its Interface for Metadata Access
                    Points (IF-MAP) <xref target="TNC-IF-MAP-SOAP-Binding"/>. IF-MAP provides a
                    query-able repository of security telemetry that may be used for storage or
                    retrieval of such data by multiple types of security systems and endpoints on a
                    vendor-neutral basis. The information model underlying the IF-MAP repository
                    covers, directly or indirectly, all of the security information types required
                    to serve SACM use-cases.</t>
            </section>
            <section title="What is TNC IF-MAP?">
                
                <t>IF-MAP provides a standard client-server protocol for MAP clients to exchange
                    security-relevant information via database server known as the Metadata Access
                    Point or MAP. The data (known as "metadata") stored in the MAP is XML data. Each
                    piece of metadata is tagged with a metadata type that indicates the meaning of
                    the metadata and identifies an XML schema for it. Due to the XML language, the
                    set of metadata types is easily extensible.</t>
                
                <t>The MAP is a graph database, not a relational database. Metadata can be
                    associated with an identifier (e.g. the email address "user@example.com") or
                    with a link between two identifiers (e.g. the link between MAC address
                    00:11:22:33:44:55 and IPv4 address 192.0.2.1) where the link defines an
                    association (for example: a relation or state) between the identifiers. These
                    links between pairs of identifiers create an ad hoc graph of relationships
                    between identifiers. The emergent structure of this graph reflects a
                    continuously evolving knowledge base of security-related metadata that is shared
                    between various providers and consumers.</t>
            </section>
            <section title="What is the TNC Information Model?">
                
                <t>The TNC Information Model underlying IF-MAP relies on the graph database
                    architecture to enable a (potentially distributed) MAP service to act as a
                    shared clearinghouse for information that infrastructure devices can act upon.
                    The IF-MAP operations and metadata schema specifications (TNC IF-MAP Binding for
                    SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/>, TNC IF-MAP Metadata for Network
                    Security <xref target="TNC-IF-MAP-NETSEC-METADATA"/>, and TNC IF-MAP Metadata
                    for ICS Security <xref target="TNC-IF-MAP-ICS-METADATA"/>) define an extensible
                    set of identifiers and data types.</t>
                
                <t>Each IF-MAP client may interact with the IF-MAP graph data store through three
                    fundamental types of operation requests:<list style="symbols">
                        
                        <t>Publish, which may create, modify, or delete metadata associated with one
                            or more identifiers and/or links in the graph</t>
                        
                        <t>Search, which retrieves a selected sub-graph according to a set of search
                            criteria</t>
                        
                        <t>Subscribe, which allows a client to manage a set of search commands which
                            asynchronously return selected sub-graphs when changes to that sub-graph
                            are made by other IF-MAP clients</t>
                    </list></t>
                
                <t>The reader is invited to review the existing IF-MAP specification <xref
                    target="TNC-IF-MAP-SOAP-Binding"/> for more details on the above graph data
                    store operation requests and their associated arguments.</t>
                
                <t>The current IF-MAP specification provides a SOAP <xref
                    target="W3C.REC-soap12-part1-20070427"/> binding for the above operations,
                    as well as associated SOAP operations for managing sessions, error handling,
                    etc.</t>
            </section>
        </section>
        
        <section title="Text for Possible Inclusion in the Terminology Draft">
            <section anchor="im-terminology" title="Terms and Definitions">
                <t>This section describes terms that have been defined by other RFCs and Internet
                    Drafts, as well as new terms introduced in this document. </t>
                <section anchor="im-terminology-pre-defined" title="Pre-defined and Modified Terms">
                    <t>This section contains pre-defined terms that are sourced from other IETF RFCs and
                        Internet Drafts. Descriptions of terms in this section will reference the
                        original source of the term and will provide additional specific context for the
                        use of each term in SACM. For sake of brevity, terms from <xref
                            target="I-D.ietf-sacm-terminology"/> are not repeated here unless the
                        original meaning has been changed in this document.</t>
                    <t><list hangIndent="8" style="hanging">
                            <t hangText="Asset">For this Information Model it is necessary to change the
                                scope of the definition of asset from the one provided in <xref
                                    target="I-D.ietf-sacm-terminology"/>. Originally defined in <xref
                                    target="RFC4949"/> and referenced in <xref
                                    target="I-D.ietf-sacm-terminology"/> as "a system resource that is
                                (a) required to be protected by an information system's security policy,
                                (b) intended to be protected by a countermeasure, or (c) required for a
                                system's mission." This definition generally relates to an "IT Asset",
                                which in the context of this document is overly limiting. For use in
                                this document, a broader definition of the term is needed to represent
                                non-IT asset types as well.</t>
                            <t>In <xref target="NISTIR-7693"/> an asset is defined as "anything that has
                                value to an organization, including, but not limited to, another
                                organization, person, computing device, information technology (IT)
                                system, IT network, IT circuit, software (both an installed instance and
                                a physical instance), virtual computing platform (common in cloud and
                                virtualized computing), and related hardware (e.g., locks, cabinets,
                                keyboards)." This definition aligns better with common dictionary
                                definitions of the term and better fits the needs of this document. </t>
                            <t/>
                        </list></t>
                </section>
                    
                <section anchor="im-terminology-new" title="New Terms">
                    <t><list hangIndent="8" style="hanging">
                            <t hangText="IT Asset">Originally defined in <xref target="RFC4949"/> as "a
                                system resource that is (a) required to be protected by an information
                                system's security policy, (b) intended to be protected by a
                                countermeasure, or (c) required for a system's mission."</t>
                            <t hangText="Security Content Automation Protocol (SCAP)">According to
                                SP800-126, SCAP, pronounced "ess-cap", is "a suite of specifications
                                that standardize the format and nomenclature by which software flaw and
                                security configuration information is communicated, both to machines and
                                humans." SP800-117 revision 1 <xref target="SP800-117"/> provides a
                                general overview of SCAP 1.2. The 11 specifications that comprise SCAP
                                1.2 are synthesized by a master specification, SP800-126 revision 2
                                    <xref target="SP800-126"/>, that addresses integration of the
                                specifications into a coherent whole. The use of "protocol" in its name
                                is a misnomer, as SCAP defines only data models. SCAP has been adopted
                                by a number of operating system and security tool vendors.</t>
                        </list></t>
                    </section>

                </section>

            </section>
        
        <section title="Text for Possible Inclusion in the Architecture or Use Cases">
            
            <section title="Introduction">
        <!-- TODO: This belongs in a SACM overview or architecture document, not here. -->
                <t>The posture of an endpoint is the status of the endpoint with respect to the
                    security policies and risk models of the organization.</t>
    
                <t>A system administrator needs to be able to determine which 
                    elements of an endpoint have a security problem and which do not conform
                    the organization's security policies. The CIO needs to be able to determine whether
                    endpoints have security postures that conform to the organization's policies to
                    ensure that the organization is complying with its fiduciary and regulatory
                    responsibilities. The regulator or auditor needs to be able to assess the level of
                    due diligence being achieved by an organization to ensure that all regulations and
                    due diligence expectations are being met. The operator needs to understand which
                    assets have deviated from organizational policies so that those assets can be
                    remedied.</t>
    
                <t>Operators will focus on which endpoints are composed of specific assets with
                    problems. CIO and auditors need a characterization of how an organization is
                    performing as a whole to manage the posture of its endpoints. All of these actors
                    need deployed capabilities that implement security automation standards in the form
                    of data formats, interfaces, and protocols to be able to assess, in a timely and
                    secure fashion, all assets on all endpoints within their enterprise. This
                    information model provides a basis to identify the desirable characteristics of data
                    models to support these scenarios. Other SACM specifications, such as the SACM
                    Architecture, will describe the potential components of an interoperable system
                    solution based on the SACM information model to address the requirements for
                    scalability, timeliness, and security.</t>
            </section>
            
            <section title="Core Principles">
                    <t>This information model is built on the following core principles:<list style="symbols">
                        <t>Collection and Evaluation are separate tasks.</t>
                        <t>Collection and Evaluation can be performed on the endpoint, at a local
                            server that communicates directly with the endpoint, or based on data
                            queried from a back end data store that does not communicate directly
                            with any endpoints.</t>
                        <t>Every entity (human or machine) that notifies, queries, or responds to
                            any guidance, collection, or evaluator must have a way of
                            identifying itself and/or presenting credentials. Authentication is a
                            key step in all of the processes, and while needed to support the
                            business processes, information needs to support authentication are not
                            highlighted in this information model. There is already a large amount
                            of existing work that defines information needs for authentication.</t>
                        <t>Policies are reflected in guidance for collection, evaluation, and
                            reporting.</t>
                        <t>Guidance will often be generated by humans or through the use of
                            transformations on existing automation data. In some cases, guidance
                            will be generated dynamically based on shared information or current
                            operational needs. As guidance is created it will be published to an
                            appropriate guidance data store allowing guidance to be managed in and
                            retrieved from convenient locations.</t>
                        <t>Operators of a continuous monitoring or security automation system will
                            need to make decisions when defining policies about what guidance to use
                            or reference. The guidance used may be directly associated with policy
                            or may be queried dynamically based on associated metadata.</t>
                        <t>Guidance can be gathered from multiple data stores. It may be retrieved
                            at the point of use or may be packaged and forwarded for later use.
                            Guidance may be retrieved in event of a collection or evaluation trigger
                            or it may be gathered ahead of time and stored locally for use/reference
                            during collection and evaluation activities.</t>
                    </list></t>
            </section>
            
            <section title="Architecture Assumptions">
                <t>This information model will focus on WHAT information needs to be exchanged to
                    support the business process areas. The architecture document is the best place
                    to represent the HOW and the WHERE this information is used. In an effort to
                    ensure that the data models derived from this information model scale to the
                    architecture, four core architectural components need to be defined. They are
                    producers, consumers, capabilities, and repositories. These elements are defined
                    as follows:<list style="symbols">

                        <t>Producers (e.g., Evaluation Producer) collect, aggregate, and/or derive
                            information items and provide them to consumers. For this model there
                            are Collection, Evaluation, and Results Producers. There may or may not
                            be Guidance Producers.</t>

                        <t>Consumers (e.g., Collection Consumer) request and/or receive information
                            items from producers for their own use. For this model there are
                            Collection, Evaluation, and Results Consumers. There may or may not be
                            Guidance Consumers.</t>
                         <!-- Of course there are Guidance Consumers. -->

                        <t>Capabilities (e.g., Posture Evaluation Capability) take the input from
                            one or more producers and perform some function on or with that
                            information. For this model there are Collection Guidance, Collection,
                            Evaluation Guidance, Evaluation, Reporting Guidance, and Results
                            Reporting Capabilities.</t>

                        <t>Repositories (e.g., Enterprise Repository) store information items that
                            are input to or output from Capabilities, Producers, and Consumers. For
                            this model we refer to generic Enterprise and Guidance Repositories.</t>
                    </list></t>
                <t>Information that needs to be communicated by or made available to any of these
                    components will be specified in each of the business process areas.</t>
                <t>In the most trivial example, illustrated in <xref
                        target="figure-producer-consumer"/>, Consumers either request information
                    from, or are notified by, Producers.</t>
                <figure title="Example Producer/Consumer Interactions"
                    anchor="figure-producer-consumer">
                    <artwork><![CDATA[
+----------+     Request     +----------+
|          <-----------------+          |
| Producer |                 | Consumer |
|          +----------------->          |
+----------+    Response     +----------+
                                         
+----------+                 +----------+
|          |     Notify      |          |
| Producer +-----------------> Consumer |
|          |                 |          |
+----------+                 +----------+
]]></artwork>
                </figure>
                <t>As illustrated in <xref target="figure-producer-consumer-repository"/>, writing
                    and querying from data repositories are a way in which this interaction can
                    occur in an asynchronous fashion.</t>

                <figure title="Producer/Consumer Repository Interaction"
                    anchor="figure-producer-consumer-repository">
                    <artwork><![CDATA[
+----------+                +----------+
|          |                |          |
| Producer |                | Consumer |
|          |                |          |
+-----+----+                +----^-----+
      |                          |
Write |     +------------+       | Query
      |     |            |       |
      +-----> Repository +-------+
            |            |
            +------------+
]]></artwork>
                </figure>

                <t>To perform an assessment, these elements are chained together. The diagram below
                    is illustrative of this and process, and is meant to demonstrate WHAT basic
                    information exchanges need to occur, while trying to maintain flexibility in HOW
                    and WHERE they occur.</t>

                <t>For example:<list style="symbols">
                        <t>the collection capability can reside on the endpoint or not.</t>
                        <t>the collection producer can be part of the collection capability or
                            not.</t>
                        <t>a repository can be directly associated with a producer and/or an
                            evaluator or stand on its own.</t>
                        <t>there can be multiple "levels" of producers and consumers.</t>
                    </list></t>

                <figure title="Producer/Consumer Complex Example"
                    anchor="figure-producer-consumer-complex-example">
                    <artwork><![CDATA[
                            +-------------+
                            |Evaluation   |
           +-------------+  |Guidance     +--+
           |Endpoint     |  |Capability   |  |
   +-------+             |  +-------------+  |
   |       |             |                   |
   |       +-------+-----+             +-----v-------+
   | Collection    |                   |Evaluation   |
 +-> Capability +--+--------+          |Capability   |
 | |            |Collection |    +-----------+   +----------+
 | +------------+Producer   |    |           |---|          |
 |              |           |    |Collection |   |Evaluation|
 |              |           |    |Consumer   |   |Producer  |
 |              +----+------+    +----^------+   +---+------+
++---------+         |                |              |
|Collection|   +-----v------+     +---+--------+     |
|Guidance  |   |            |     |Collection  |     |
|Capability|   |Collection  |     |Producer    |     |
|          |   |Consumer    |-----|            |     |
+----------+   +------------+     +------------+     |
                          | Collection |             |
                          | Repository |             |
                          +------------+             |
                                                     |
    +--------------+           +---------------+     |
    |Evaluation    |           |Evaluation     |     |
    |Results       |           |Consumer       <-----+
    |Producer      |-----------|               |
    +-----+--------+           +---------------+
          |     |Results Reporting|
          |     |Capability       |
          |     +------------^----+
          |                  |
    +-----v--------+    +----+------+
    |Evaluation    |    |Reporting  |
    |Results       |    |Guidance   |
    |Consumer      |    |Repository |
    +---+----------+    +-----------+ +-------------+
        |                             | Results     |
        +-----------------------------> Repository  |
                                      |             |
                                      +-------------+
        ]]></artwork>
                </figure>

                <t>This illustrative example in <xref
                        target="figure-producer-consumer-complex-example"/> provides a set of
                    information exchanges that need to occur to perform a posture assessment. The
                    rest of this information model is using this set of exchanges based on these
                    core architectural components as the basis for determining information
                    elements.</t>
            </section>
        </section>

        <section title="Text for Possible Inclusion in the Requirements Draft">
            
            <section title="Problem Statement">
                <t>Scalable and sustainable collection, expression, and evaluation of endpoint
                    information is foundational to SACM's objectives. To secure and defend one's network
                    one must reliably determine what devices are on the network, how those devices are
                    configured from a hardware perspective, what software products are installed on
                    those devices, and how those products are configured. We need to be able to
                    determine, share, and use this information in a secure, timely, consistent, and
                    automated manner to perform endpoint posture assessments.</t>
            </section>
            
            <section title="Problem Scope">            
                <t>The goal of this iteration of the information model is to define the
                    information needs for an organization to effectively monitor the endpoints
                    operating on their network, the software installed on those endpoints, and the
                    configuration of that software. Once we have those three business processes in
                    place, we can identify vulnerable endpoints in a very efficient manner.</t>
                <t>The four business process areas represent a large set of tasks that support
                    endpoint posture assessment. In an effort to address the most basic and
                    foundational needs, we have also narrowed down the scope inside of each of the
                    business processes to a set of defined tasks that strive to achieve specific
                    results in the operational environment and the organization. These tasks
                        are:<list style="numbers">
                        <t>Define the assets. This is what we want to know about an asset. For
                            instance, organizations will want to know what software is installed and
                            its many critical security attributes such as patch level.</t>
                        <t>Resolve what assets compose an endpoint. This requires
                            populating the data elements and attributes needed to exchange
                            information pertaining to the assets composing an endpoint.</t>
                        <t>Express what expected values for the data elements and attributes need to
                            be evaluated against the actual collected instances of asset data. This
                            is how an organization can express its policy for an acceptable data
                            element or attribute value. A system administrator can also identify
                            specific data elements and attributes that represent problems, such as
                            vulnerabilities, that need to be detected on an endpoint.</t>
                        <t>Evaluate the collected instances of the asset data against those
                            expressed in the policy.</t>
                        <t>Report the results of the evaluation.</t>
                    </list></t>
                </section>    
            </section>
        
        <section title="Text With No Clear Home Yet">
        
            <section title="Operations">

                <t>Operations that may be carried out the proposed SACM Information Model are:<list
                        style="symbols">

                        <t>Publish data: Security information is made available in the information
                            model when a component publishes data to it.</t>

                        <t>Subscribe to data: A component seeking to consume an on-going stream of
                            security information "subscribes" to such data from the information
                            model.</t>

                        <t>Query: This operation enables a component to request a specific set of
                            security data regarding a specific asset (such as a specific user
                            endpoint).</t>
                    </list></t>

                <t>The subscribe capability will allow SACM components to monitor for selected
                    security-related changes in the graph data store without incurring the
                    performance penalties associated with polling for such changes.</t>

                <section title="Generalized Workflow">

                    <t>The proposed SACM Information Model would be most commonly used with a
                        suitable transport protocol for collecting and distributing security data
                        across appropriate network platforms and endpoints. The information model is
                        transport agnostic and can be used with its native transport provided by
                        IF-MAP or by other data transport protocols such as the recently proposed
                        XMPP-Grid.</t>

                    <t><list style="numbers">
                            <t>A Posture Assessment Information Consumer (Consumer) establishes
                                connectivity and authorization with the transport fabric.</t>

                            <t>A Posture Assessment Information Provider (Provider) with a source of
                                security data requests connection to the transport fabric.</t>

                            <t>Transport fabric authenticates and establishes authorized privileges
                                (e.g. privilege to publish and/or subscribe to security data) for
                                the requesting components.</t>
                            <t>Components may either publish security data, subscribe to security
                                data, query for security data, or any combination of these
                                operations.</t>
                        </list></t>

                    <t>Any component sharing information - either as Provider or Consumer - may do
                        so on a one-to-one, one-to-many and/or many-to-many meshed basis.</t>
                 </section>
            </section>
            
            <section title="From Information Needs to Information Elements">
                <t>The previous sections highlighted information needs for a set of management process
                    areas that use posture assessment to achieve organizational security goals. A single
                    information need may be made up of multiple information elements. Some information
                    elements may be required for two different process areas, resulting in two different
                    requirements. In an effort to support the main idea of collect once and reuse the
                    data to support multiple processes, we try to define a singular set of information
                    elements that will support all the associated information needs.</t>
            </section>
        
            <section title="Information Model Elements" anchor="im-elements">
                
                <t>TODO: Kim to pull up relevant content into section 4 / Elements</t>
                <t>Traditionally, one would use the SACM architecture to define interfaces that required
                    information exchanges. Identified information elements would then be based on those
                    exchanges. Because the SACM architecture document is still in the personal draft
                    stage, this information model uses a different approach to the identification of
                    information elements. First it lists the four main endpoint posture assessment
                    activities. Then it identifies management process areas that use endpoint posture
                    assessment to achieve organizational security objectives. These process areas were
                    then broken down into operations that mirrored the typical workflow from the SACM
                    Use Cases draft <xref target="I-D.ietf-sacm-use-cases"/>. These operations identify
                    architectural components and their information needs. In this section, information
                    elements derived from those information needs are mapped back to the four main
                    activities listed above.</t>
    
                <t>The original liaison statement <xref target="IM-LIAISON-STATEMENT-NIST"/> requested
                    contributions for the SACM information model in the four areas described below.
                    Based on the capabilities defined previously in this document, the requested areas
                    alone do not provide a sufficient enough categorization of the necessary information
                    model elements. The following sub-sections directly address the requested areas as
                        follows:<list style="numbers">
                        <t>Endpoint Identification<list style="letters">
                                <t><xref target="IM-ELEMENTS-ASSET-IDENTIFIERS"/>
                                    <xref target="IM-ELEMENTS-ASSET-IDENTIFIERS" format="title"/>:
                                    Describes identification of many different asset types including
                                    endpoints.</t>
                            </list>
                        </t>
                        <t>Endpoint Characterization <list style="letters">
                                <t><xref target="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION"/>
                                    <xref target="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION" format="title"
                                    />: This directly maps to the requested area.</t>
                            </list>
                        </t>
                        <t>Endpoint Attribute Expression/Representation <list style="letters">
                                <t><xref target="IM-ELEMENTS-PA-EXPRESSION"/>
                                    <xref target="IM-ELEMENTS-PA-EXPRESSION" format="title"/>: This
                                    corresponds to the first part of "Endpoint Attribute
                                    Expression/Representation."</t>
                                <t><xref target="IM-ELEMENTS-ACTUAL-VALUE"/>
                                    <xref target="IM-ELEMENTS-ACTUAL-VALUE" format="title"/>: This
                                    corresponds to the second part of "Endpoint Attribute
                                    Expression/Representation."</t>
                            </list>
                        </t>
                        <t>Policy evaluation expression and results reporting <list style="letters">
                                <t><xref target="IM-ELEMENTS-EVALUATION-GUIDANCE"/>
                                    <xref target="IM-ELEMENTS-EVALUATION-GUIDANCE" format="title"/>:
                                    This corresponds to the first part of "Policy evaluation expression
                                    and results reporting."</t>
                                <t><xref target="IM-ELEMENTS-EVAL-REPORTING"/>
                                    <xref target="IM-ELEMENTS-EVAL-REPORTING" format="title"/>:
                                    corresponds to the second part of "Policy evaluation expression and
                                    results reporting."</t>
                            </list>
                        </t>
                    </list></t>
    
                <t>Additionally, <xref target="IM-ELEMENTS-OTHER-IDENTIFIERS"/>
                    <xref target="IM-ELEMENTS-OTHER-IDENTIFIERS" format="title"/>: describes other
                    important identification concepts that were not directly requested by the liaison
                    statement.</t>
    
                <t>Per the liaison statement, each subsection references related work that provides a
                    basis for potential data models. Some analysis is also included for each area of
                    related work on how directly applicable the work is to the SACM efforts. In general,
                    much of the related work does not fully address the general or use case-based
                    requirements for SACM, but they do contain some parts that can be used as the basis
                    for data models that correspond to the information model elements. In these cases
                    additional work will be required by the WG to adapt the specification. In some
                    cases, existing work can largely be used in an unmodified fashion. This is also
                    indicated in the analysis. Due to time constraints, the work in this section is very
                    biased to previous work supported by the authors and does not reflect a
                    comprehensive listing. An attempt has been made where possible to reference existing
                    IETF work. Additional research and discussion is needed to include other related
                    work in standards and technology communities that could and should be listed here.
                    The authors intend to continue this work in subsequent revisions of this draft.</t>
                <t>Where possible when selecting and developing data models in support of these
                    information model elements, extension points and IANA registries SHOULD be used to
                    provide for extensibility which will allow for future data models to be
                    addressed.</t>
    
                <section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS" title="Asset Identifiers">
                    <t>In this context an "asset" refers to "anything that has value to an organization"
                        (see <xref target="NISTIR-7693"/>). This use of the term "asset" is broader than
                        the current definition in <xref target="I-D.ietf-sacm-terminology"/>. To support
                        SACM use cases, a number of different asset types will need to be addressed. For
                        each type of asset, one or more type of asset identifier will be needed for use
                        in establishing contextual relationships within the SACM information model. The
                        following asset types are referenced or implied by the SACM use cases: <list
                            hangIndent="8" style="hanging">
                            <t hangText="Endpoint:">Identifies an individual endpoint for which posture
                                is collected and evaluated.</t>
                            <t hangText="Hardware:">Identifies a given type of hardware that may be
                                installed within an endpoint.</t>
                            <t hangText="Software:">Identifies a given type of software that may be
                                installed within an endpoint.</t>
                            <t hangText="Network:">Identifies a network for which a given endpoint may
                                be connected or request a connection to.</t>
                            <t hangText="Organization:">Identifies an organizational unit.</t>
                            <t hangText="Person:">Identifies an individual, often within an
                                organizational context.</t>
                        </list></t>
                    <section title="Related Work" toc="exclude">
                        <section title="Asset Identification" anchor="AI-BACKGROUND" toc="exclude">
                            <t>The Asset Identification specification <xref target="NISTIR-7693"/> is an
                                XML-based data model that "provides the necessary constructs to uniquely
                                identify assets based on known identifiers and/or known information
                                about the assets." Asset identification plays an important role in an
                                organization's ability to quickly correlate different sets of
                                information about assets. The Asset Identification specification
                                provides the necessary constructs to uniquely identify assets based on
                                known identifiers and/or known information about the assets. Asset
                                Identification provides a relatively flat and extensible model for
                                capturing the identifying information about a one or more assets, and
                                also provides a way to represent relationships between assets.</t>
                            <t>The model is organized using an inheritance hierarchy of specialized
                                asset types/classes (see <xref target="figure-ai-class-hierarchy"/>),
                                providing for extension at any level of abstraction. For a given asset
                                type, a number of properties are defined that provide for capturing
                                identifying characteristics and the referencing of namespace qualified
                                asset identifiers, called "synthetic IDs."</t>
                            <t/>
                            <figure anchor="figure-ai-class-hierarchy"
                                title="Asset Identification Class Hierarchy">
                                <preamble>The following figure illustrates the class hierarchy defined
                                    by the Asset Identification specification.</preamble>
                                <artwork><![CDATA[
      asset
       +-it-asset
       | +-circuit
       | +-computing-device
       | +-database
       | +-network
       | +-service
       | +-software
       | +-system
       | +-website
       +-data 
       +-organization
       +-person
    ]]></artwork>
                            </figure>
                            <texttable anchor="table-sacm-to-ai"
                                title="Mapping of SACM to Asset Identification Asset Types" style="all">
                                <preamble>This table presents a mapping of notional SACM asset types to
                                    those asset types provided by the Asset Identification
                                    specification.</preamble>
                                <ttcol>SACM Asset Type</ttcol>
                                <ttcol>Asset Identification Type</ttcol>
                                <ttcol>Notes</ttcol>
                                <c>Endpoint</c>
                                <c>computing-device</c>
                                <c>This is not a direct mapping since a computing device is not required
                                    to have network-connectivity. Extension will be needed to define a
                                    directly aligned endpoint asset type.</c>
                                <c>Hardware</c>
                                <c>Not Applicable</c>
                                <c>The concept of hardware is not addressed by the asset identification
                                    specification. An extension can be created based on the it-asset
                                    class to address this concept.</c>
                                <c>Software</c>
                                <c>software</c>
                                <c>Direct mapping.</c>
                                <c>Network</c>
                                <c>network</c>
                                <c>Direct mapping.</c>
                                <c>Organization</c>
                                <c>organization</c>
                                <c>Direct mapping.</c>
                                <c>Person</c>
                                <c>person</c>
                                <c>Direct mapping.</c>
                            </texttable>
                            <t>This specification has been adopted by a number of SCAP validated
                                products. It can be used to address asset identification and
                                categorization needs within SACM with minor modification.</t>
                        </section>
                    </section>
    
                    <section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-ENDPOINT"
                        title="Endpoint Identification">
                        <t>An unique name for an endpoint. This is a foundational piece of information
                            that will enable collected posture attributes to be related to the endpoint
                            from which they were collected. It is important that this name either be
                            created from, provide, or be associated with operational information (e.g.,
                            MAC address, hardware certificate) that is discoverable from the endpoint or
                            its communications on the network. It is also important to have a method of
                            endpoint identification that can persist across network sessions to allow
                            for correlation of collected data over time.</t>
                        <section title="Related Work" toc="exclude">
                            <t>The previously introduced asset identification specification (see <xref
                                    target="AI-BACKGROUND"/> provides a basis for endpoint
                                identification using the "computing-device" class. While the meaning of
                                this class is broader than the current definition of an endpoint in the
                                SACM terminology <xref target="I-D.ietf-sacm-terminology"/>, either that
                                class or an appropriate sub-class extension can be used to capture
                                identification information for various endpoint types.</t>
                        </section>
                    </section>
    
                    <section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-SOFTWARE"
                        title="Software Identification">
                        <t>A unique name for a unit of installable software. Software names should
                            generally represent a unique release or installable version of software.
                            Identification approaches should allow for identification of commercially
                            available, open source, and organizationally developed custom software. As
                            new software releases are created, a new software identifier should be
                            created by the releasing party (e.g., software creator, publisher,
                            licensor). Such an identifier is useful to:<list style="symbols">
                                <t>Relate metadata that describes the characteristics of the unit of
                                    software, potentially stored in a repository of software
                                    information. Typically, the software identifier would be used as an
                                    index into such a repository.</t>
                                <t>Indicate the presence of the software unit on a given endpoint.</t>
                                <t>To determine what endpoints are the targets for an assessment based
                                    on what software is installed on that endpoint.</t>
                                <t>Define guidance related to a software unit that represents
                                    collection, evaluation, or other automatable policies.</t>
                            </list></t>
                        <t>In general, an extensible method of software identification is needed to
                            provide for adequate coverage and to address legacy identification
                            approaches. Use of an IANA registry supporting multiple software
                            identification methods would be an ideal way forward.</t>
                        <section title="Related Work" toc="exclude">
                            <t>While we are not aware of a one-size-fits-all solution for software
                                identification, there are two existing specifications that should be
                                considered as part of the solution set. They are described in the
                                following subsections.</t>
                            <section title="Common Platform Enumeration">
                                <section title="Background" anchor="IM-ELEMENTS-CPE-BACKGROUND">
                                    <t>The Common Platform Enumeration (CPE) <xref target="CPE-WEBSITE"
                                        /> is composed of a family of four specification that are
                                        layered to build on lower-level functionality. The following
                                        describes each specification:<list style="numbers">
                                            <t>CPE Naming: A standard machine-readable format <xref
                                                    target="NISTIR-7695"/> for encoding names of IT
                                                products and platforms. This defines the notation used
                                                to encode the vendor, software name, edition, version
                                                and other related information for each platform or
                                                product. With the 2.3 version of CPE, a second, more
                                                advanced notation was added to the original
                                                colon-delimited notation for CPE naming.</t>
                                            <t>CPE Matching: A set of procedures <xref
                                                    target="NISTIR-7696"/> for comparing names. This
                                                describes how to compare two CPE names to one another.
                                                It describes a logical method that ensures that
                                                automated systems comparing two CPE names would arrive
                                                at the same conclusion.</t>
                                            <t>CPE Applicability Language: An XML-based language <xref
                                                    target="NISTIR-7698"/> for constructing
                                                "applicability statements" that combine CPE names with
                                                simple logical operators.</t>
                                            <t>CPE Dictionary: An XML-based catalog format <xref
                                                    target="NISTIR-7697"/> that enumerates CPE Names and
                                                associated metadata. It details how to encode the
                                                information found in a CPE Dictionary, thereby allowing
                                                multiple organizations to maintain compatible CPE
                                                Dictionaries.</t>
                                        </list></t>
                                    <t>The primary use case of CPE is for exchanging software inventory
                                        data, as it allows the usage of unique names to identify
                                        software platforms and products present on an endpoint. The NIST
                                        currently maintains and updates a dictionary of all agreed upon
                                        CPE names, and is responsible for ongoing maintenance of the
                                        standard. Many of the names in the CPE dictionary have been
                                        provided by vendors and other 3rd-parties.</t>
                                    <t>While the effort has seen wide adoption, most notably within the
                                        US Government, a number of critical flaws have been identified.
                                        The most critical issues associated with the effort are:<list
                                            style="symbols">
                                            <t>Because there is no requirement for vendors to publish
                                                their own, official CPE names, CPE necessarily requires
                                                one or more organizations for curation. This centralized
                                                curation requirement ensures that the effort has
                                                difficulty scaling.</t>
                                            <t>Not enough primary source vendors provide platform and
                                                product naming information. As a result, this pushes too
                                                much of the effort out onto third-party groups and
                                                non-authoritative organizations. This exacerbates the
                                                ambiguity in names used for identical platforms and
                                                products and further reduces the utility of the
                                                effort.</t>
                                        </list></t>
                                </section>
                                <section title="Applicability to Software Identification">
                                    <t>The Common Platform Enumeration (CPE) Naming specification
                                        version 2.3 defines a scheme for human-readable standardized
                                        identifiers of hardware and software products.</t>
                                    <t>CPE names are the identifier format for software and hardware
                                        products used in SCAP 1.2 and is currently adopted by a number
                                        of SCAP product vendors.</t>
                                    <t>CPE names can be directly referenced in the asset identification
                                        software class (see <xref target="AI-BACKGROUND"/>.)</t>
                                    <t>Although relevant, CPE has an unsustainable maintenance "tail"
                                        due to the need for centralized curation and naming-consistency
                                        enforcement. Its mention in this document is to support the
                                        historic inclusion of CPE as part of SCAP and implementation of
                                        this specification in a number of security processes and
                                        products. Going forward, software identification (SWID) tags are
                                        recommended as a replacement for CPE. To this end, work has been
                                        started to align both efforts to provide translation for
                                        software units identified using SWID tags to CPE Names. This
                                        translation would allow tools that currently use CPE-based
                                        identifiers to map to SWID identifiers during a transition
                                        period.</t>
                                </section>
                            </section>
                            <section title="Software Identification (SWID) Tags"
                                anchor="SWID-BACKGROUND">
                                <t>The software identification tag specification <xref
                                        target="ISO.19770-2"/> is an XML-based data model that is used
                                    to describe a unit of installable software. A SWID tag contains data
                                    elements that:<list style="symbols">
                                        <t>Identify a specific unit of installable software,</t>
                                        <t>Enable categorization of the software (e.g., edition,
                                            bundle),</t>
                                        <t>Identification and hashing of software artifacts (e.g.,
                                            executables, shared libraries),</t>
                                        <t>References to related software and dependencies, and</t>
                                        <t>Inclusion of extensible metadata.</t>
                                    </list></t>
                                <t>SWID tags can be associated with software installation media,
                                    installed software, software updates (e.g., service packs, patches,
                                    hotfixes), and redistributable components. SWID tags also provide
                                    for a mechanism to relate these concepts to each other. For example,
                                    installed software can be related back to the original installation
                                    media, patches can be related to the software that they patch, and
                                    software dependencies can be described for required redistributable
                                    components. SWID tags are ideally created at build-time by the
                                    software creator, publisher or licensor; are bundled with software
                                    installers; and are deployed to an endpoint during software
                                    installation.</t>
                                <t>SWID tags should be considered for two primary uses:<list
                                        style="numbers">
                                        <t>As the data format for exchanging descriptive information
                                            about software products, and</t>
                                        <t>As the source of unique identifiers for installed
                                            software.</t>
                                    </list></t>
                                <t>In addition to usage for software identification, a SWID tag can
                                    provide the necessary data needed to target guidance based on
                                    included metadata, and to support verification of installed software
                                    and software media using cryptographic hashes. This added
                                    information increases the value of using SWID tags as part of the
                                    larger security automation and continuous monitoring solution
                                    space.</t>
                            </section>
                        </section>
                    </section>
    
                    <section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-HARDWARE"
                        title="Hardware Identification">
                        <t>Due to the time constraints, research into information elements and related
                            work for identifying hardware is not included in this revision of the
                            information model.</t>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-OTHER-IDENTIFIERS" title="Other Identifiers">
                    <t>In addition to identifying core asset types, it is also necessary to have stable,
                        globally unique identifiers to represent other core concepts pertaining to
                        posture attribute collection and evaluation. The concept of "global uniqueness"
                        ensures that identifiers provided by multiple organization do not collide. This
                        may be handled by a number of different mechanisms (e.g., use of
                        namespaces).</t>
    
                    <section anchor="IM-ELEMENTS-OTHER-IDENTIFIERS-PLATFORM-CI"
                        title="Platform Configuration Item Identifier">
                        <t>A name for a low-level, platform-dependent configuration mechanism as
                            determined by the authoritative primary source vendor. New identifiers will
                            be created when the source vendor makes changes to the underlying platform
                            capabilities (e.g., adding new settings, replacing old settings with new
                            settings). When created each identifier should remain consistent with
                            regards to what it represents. Generally, a change in meaning would
                            constitute the creation of a new identifier.</t>
                        <t>For example, if the configuration item is for "automatic execution of code",
                            then the platform vendor would name the low-level mechanism for their
                            platform (e.g., autorun for mounted media).</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Common Configuration Enumeration">
                                <t>The Common Configuration Enumeration (CCE) <xref target="CCE"/> is an
                                    effort managed by NIST. CCE provides a unique identifier for
                                    platform-specific configuration items that facilitates fast and
                                    accurate correlation of configuration items across multiple
                                    information sources and tools. CCE does this by providing an
                                    identifier, a human readable description of the configuration
                                    control, parameters needed to implement the configuration control,
                                    various technical mechanisms that can be used to implement the
                                    configuration control, and references to documentation that describe
                                    the configuration control in more detail.</t>
                                <t>By vendor request, NIST issues new blocks of CCE identifiers. Vendors
                                    then populate the required fields and provided the details back to
                                    NIST for publication in the "CCE List", a consolidated listing of
                                    assigned CCE identifiers and associated data. Many vendors also
                                    include references to these identifiers in web pages, SCAP content,
                                    and prose configuration guides they produce.</t>
                                <t>CCE the identifier format for platform specific configuration items
                                    in SCAP and is currently adopted by a number of SCAP product
                                    vendors.</t>
                                <t>While CCE is largely supported as a crowd-sourced effort, it does
                                    rely on a central point of coordination for assignment of new CCE
                                    identifiers. This approach to assignment requires a single
                                    organization, currently NIST, to manage allocations of CCE
                                    identifiers which doesn't scale well and introduces sustainability
                                    challenges for large volumes of identifier assignment. If this
                                    approach is used going forward by SACM, a namespaced approach is
                                    recommended for identifier assignment that allows vendors to manage
                                    their own namespace of CCE identifiers. This change would require
                                    additional work to specify and implement.</t>
                            </section>
                            <section title="Open Vulnerability and Assessment Language">
                                <section anchor="IM-ELEMENTS-OVAL-BACKGROUND" title="Background">
                                    <t>The Open Vulnerability and Assessment Language (OVAL&reg;) is an
                                        XML schema-based data model developed as part of a
                                        public-private information security community effort to
                                        standardize how to assess and report upon the security posture
                                        of endpoints. OVAL provides an established framework for making
                                        assertions about an endpoint's posture by standardizing the
                                        three main steps of the assessment process:<list style="numbers">
                                            <t>representing the current endpoint posture;</t>
                                            <t>analyzing the endpoint for the presence of the specified
                                                posture; and</t>
                                            <t>representing the results of the assessment.</t>
                                        </list></t>
                                    <t>OVAL facilitates collaboration and information sharing among the
                                        information security community and interoperability among tools.
                                        OVAL is used internationally and has been implemented by a
                                        number of operating system and security tools vendors.</t>
    
                                    <figure anchor="figure-oval-data-model" title="The OVAL Data Model">
                                        <preamble>The following figure illustrates the OVAL data
                                            model.</preamble>
                                        <artwork><![CDATA[
                                          +------------+
                    +-----------------+   | Variables  |
                    | Common          <---+            |
           +-------->                 |   +------------+
           |        |                 |   +------------+
           |        |                 <---+ Directives |
           |        +--------^----^---+   |            |
           |                 |    |       +--------+---+
           |                 |    +-----+          |
           |                 |          |          |
           |        +--------+--------+ |          |
           |        | System          | |          |
           |        | Characteristics | |          |
    +------+------+ |                 | | +--------v---+
    | Definitions | |                 | | | Results    |
    |             | +--------^--------+ +-+            |
    |             |          |            |            |
    |             |          +------------+            |
    +------^------+                       +-------+----+
           |                                      |
           +--------------------------------------+
    ]]></artwork>
                                        <postamble>Note: The direction of the arrows indicate a model
                                            dependency</postamble>
                                    </figure>
    
                                    <t>The OVAL data model <xref target="OVAL-LANGUAGE"/>, visualized in
                                            <xref target="figure-oval-data-model"/>, is composed of a
                                        number of different components. The components are:<list
                                            style="symbols">
                                            <t>Common: Constructs, enumerations, and identifier formats
                                                that are used throughout the other model components.</t>
                                            <t>Definitions: Constructs that describe assertions about
                                                system state. This component also includes constructs
                                                for internal variable creation and manipulation through
                                                a variety of functions. The core elements are:<list
                                                    style="symbols">
                                                    <t>Definition: A collection of logical statements
                                                      that are combined to form an assertion based on
                                                      endpoint state.</t>
                                                    <t>Test(platform specific): A generalized construct
                                                      that is extended in platform schema to describe
                                                      the evaluation of expected against actual
                                                      state.</t>
                                                    <t>Object(platform specific): A generalized
                                                      construct that is extended in platform schema to
                                                      describe a collectable aspect of endpoint
                                                      posture.</t>
                                                    <t>State(platform specific): A generalized construct
                                                      that is extended in platform schema to describe a
                                                      set of criteria for evaluating posture
                                                      attributes.</t>
                                                </list></t>
                                            <t>Variables: Constructs that allow for the parameterization
                                                of the elements used in the Definitions component based
                                                on externally provided values.</t>
                                            <t>System Characteristics: Constructs that represent
                                                collected posture from one or more endpoints. This
                                                element may be embedded with the Results component, or
                                                may be exchanged separately to allow for separate
                                                collection and evaluation. The core elements of this
                                                component are:<list style="symbols">
                                                    <t>CollectedObject: Provides a mapping of collected
                                                      Items to elements defined in the Definitions
                                                      component.</t>
                                                    <t>Item(platform specific): A generalized construct
                                                      that is extended in platform schema to describe
                                                      specific posture attributes pertaining to an
                                                      aspect of endpoint state.</t>
                                                </list></t>
                                            <t>Results: Constructs that represent the result of
                                                evaluating expected state (state elements) against
                                                actual state (item elements). It includes the true/false
                                                evaluation result for each evaluated Definition and
                                                Test. Systems characteristics are embedded as well to
                                                provide low-level posture details.</t>
                                            <t>Directives: Constructs that enable result reporting
                                                detail to be declared, allowing for result production to be
                                                customized.</t>
                                        </list></t>
                                    <t>End-user organizations and vendors create assessment guidance
                                        using OVAL by creating XML instances based on the XML schema
                                        implementation of the OVAL Definitions model. The OVAL
                                        Definitions model defines a structured identifier format for
                                        each of the Definition, Test, Object, State, and Item elements.
                                        Each instantiation of these elements in OVAL XML instances are
                                        assigned a unique identifier based on the specific elements
                                        identifier syntax. These XML instances are used by tools that
                                        support OVAL to drive collection and evaluation of endpoint
                                        posture. When posture collection is performed, an OVAL Systems
                                        Characteristics XML instance is generated based on the collected
                                        posture attributes. When this collected posture is evaluated, an
                                        OVAL Result XML instance is generated that contains the results
                                        of the evaluation. In most implementations, the collection and
                                        evaluation is performed at the same time.</t>
    
                                    <t>Many of the elements in the OVAL model (i.e., Test, Object,
                                        State, Item) are abstract, requiring a platform-specific schema
                                        implementation, called a "Component Model" in OVAL. These
                                        platform schema implementations are where platform specific
                                        posture attributes are defined. For each aspect of platform
                                        posture a specialized OVAL Object, which appears in the OVAL
                                        Definitions model, provides a format for expressing what posture
                                        attribute data to collect from an endpoint through the
                                        specification of a datatype, operation, and value(s) on entities
                                        that uniquely identify a platform configuration item. For
                                        example, a hive, key, and name is used to identify a registry
                                        key on a Windows endpoint. Each specialized OVAL Object has a
                                        corresponding specialized State, which represents the posture
                                        attributes that can be evaluated, and an Item which represents
                                        the specific posture attributes that can be collected.
                                        Additionally, a specialized Test exists that allows collected
                                        Items corresponding to a CollectedObject to be evaluated against
                                        one or more specialized States of the same posture type.</t>
    
                                    <t>The OVAL language provides a generalized approach suitable for
                                        posture collection and evaluation. While this approach does
                                        provide for a degree of extensibility, there are some concerns
                                        that should be addressed in order to make OVAL a viable basis
                                        for SACM's use. These concerns include:<list style="symbols">
                                            <t>Platform Schema Creation and Maintenance: In OVAL
                                                platform schema, the OVAL data model maintains a tight
                                                binding between the Test, Object, State, and Item
                                                elements used to assess an aspect of endpoint posture.
                                                Creating a new platform schema or adding a new posture
                                                aspect to an existing platform schema can be a very
                                                labor intensive process. Doing so often involves
                                                researching and understanding system APIs and can be
                                                prone to issues with inconsistency within and between
                                                platforms. To simplify platform schema creation and
                                                maintenance, the model needs to be evolved to generalize
                                                the Test, Object, and State elements, requiring only the
                                                definition of an Item representation.</t>
                                            <t>Given an XML instance based on the Definitions model, it
                                                is not clear in the specification how incremental
                                                collection and evaluation can occur. Because of this,
                                                typically, OVAL assessments are performed on a periodic
                                                basis. The OVAL specification needs to be enhanced to
                                                include specifications for performing event-based and
                                                incremental assessment in addition to full periodic
                                                collection.</t>
                                            <t>Defining new functions for manipulating variable values
                                                is current handled in the Definitions schema. This
                                                requires revision to the core language to add new
                                                functions. The OVAL specification needs to be evolved to
                                                provide for greater extensibility in this area, allowing
                                                extension schema to define new functions.</t>
                                            <t>The current process for releasing a new version of OVAL,
                                                bundle releases of the core language with release of
                                                community recognized platform schema. The revision
                                                processes for the core and platform schema need to be
                                                decoupled. Each platform schema should use some
                                                mechanism to declare which core language version it
                                                relies on.</t>
                                        </list></t>
                                    <t>If adopted by SCAM, these issues will need to be addressed as
                                        part of the SCAM engineering work to make OVAL more broadly
                                        adoptable as a general purpose data model for posture collection
                                        and evaluation.</t>
                                </section>
                                <section
                                    title="Applicability to Platform Configuration Item Identification">
                                    <t>Each OVAL Object is identified by a globally unique identifier.
                                        This globally unique identifier could be used by the SACM
                                        community to identify platform-specific configuration items and
                                        at the same time serve as collection guidance. If used in this
                                        manner, OVAL Objects would likely need to undergo changes in
                                        order to decouple it from evaluation guidance and to provide
                                        more robust collection capabilities to support the needs of the
                                        SACM community.</t>
                                </section>
                            </section>
                        </section>
                    </section>
    
                    <section title="Configuration Item Identifier">
                        <t>An identifier for a high-level, platform-independent configuration control.
                            This identification concept is necessary to allow similar configuration item
                            concepts to be comparable across platforms. For example, a configuration
                            item might be created for the minimum password length configuration control,
                            which may then have a number of different platform-specific configuration
                            settings. Without this type of identification, it will be difficult to
                            perform evaluation of expected versus actual state in a platform-neutral
                            way.</t>
                        <t>High-level configuration items tend to change much less frequently than the
                            platform-specific configuration items (see <xref
                                target="IM-ELEMENTS-OTHER-IDENTIFIERS-PLATFORM-CI"/>) that might be
                            associated with them. To provide for the greatest amount of sustainability,
                            collections of configuration item identifiers are best defined by specific
                            communities of interest, while platform-specific identifiers are best
                            defined by the source vendor of the platform. Under this model, the primary
                            source vendors would map their platform-specific configuration controls to
                            the appropriate platform-independent item allowing end-user organizations to
                            make use of these relationships.</t>
                        <t>To support different communities of interest, it may be necessary to support
                            multiple methods for identification of configuration items and for
                            associating related metadata. Use of an IANA registry supporting multiple
                            configuration item identification methods would be an ideal way forward. To
                            the extent possible, a few number of configuration item identification
                            approaches is desirable, to maximize the update by vendors who would be
                            maintain mapping of platform-specific configuration identifiers to the more
                            general platform-neutral configuration identifiers.</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Control Correlation Identifier">
                                <t>The Control Correlation Identifier (CCI) <xref target="CCI"/> is
                                    developed and managed by the United States Department of Defense
                                    (US-DoD) Defense Information Systems Agency (DISA). According to
                                    their website, CCI "provides a standard identifier and description
                                    for each of the singular, actionable statements that comprise an
                                    information assurance (IA) control or IA best practice. CCI bridges
                                    the gap between high-level policy expressions and low-level
                                    technical implementations. CCI allows a security requirement that is
                                    expressed in a high-level policy framework to be decomposed and
                                    explicitly associated with the low-level security setting(s) that
                                    must be assessed to determine compliance with the objectives of that
                                    specific security control. This ability to trace security
                                    requirements from their origin (e.g., regulations, IA frameworks) to
                                    their low-level implementation allows organizations to readily
                                    demonstrate compliance to multiple IA compliance frameworks. CCI
                                    also provides a means to objectively roll-up and compare related
                                    compliance assessment results across disparate technologies."</t>
                                <t>It is recommended that this approach be analysed as a potential
                                    candidate for use as a configuration item identifier method.</t>
                                <t>Note: This reference to CCI is for informational purposes. Since the
                                    editors do not represent DISA's interests, its inclusion in this
                                    document does not indicate the presence or lack of desire to
                                    contribute aspects of this effort to SACM.</t>
                            </section>
                            <section title="A Potential Alternate Approach">
                                <t>There will likely be a desire by different communities to create
                                    different collections of configuration item identifiers. This
                                    fracturing may be caused by:<list style="symbols">
                                        <t>Different requirements for levels of abstraction,</t>
                                        <t>Varying needs for timely maintenance of the collection,
                                            and</t>
                                        <t>Differing scopes of technological needs.</t>
                                    </list></t>
                                <t>Due to these and other potential needs, it will be difficult to
                                    standardize around a single collection of configuration identifiers.
                                    A workable solution will be one that is scalable and usable for a
                                    broad population of end-user organizations. An alternate approach
                                    that should be considered is the definition of data model that
                                    contains a common set of metadata attributes, perhaps supported by
                                    an extensible taxonomy, that can be assigned to platform-specific
                                    configuration items. If defined at a necessary level of granularity,
                                    it may be possible to query collections of platform-specific
                                    configuration items provided by vendors to create groupings at
                                    various levels of abstractions. By utilizing data provided by
                                    vendors, technological needs and the timeliness of information can
                                    be addressed based on customer requirements.</t>
                                <t> SACM should consider this and other approaches to satisfy the need
                                    for configuration item roll-up in a way that provides the broadest
                                    benefit, while achieving a sensible degree of scalability and
                                    sustainability.</t>
                            </section>
                        </section>
                    </section>
    
                    <section title="Vulnerability Identifier">
                        <t>An unique name for a known software flaw that exists in specific versions of
                            one or more units of software. One use of a vulnerability identifier in the
                            SACM context is to associate a given flaw with the vulnerable software using
                            software identifiers. For this reason at minimum, software identifiers
                            should identify a software product to the patch or version level, and not
                            just to the level that the product is licensed.</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Common Vulnerabilities and Exposures">
                                <t>Common Vulnerabilities and Exposures (CVE) <xref target="CVE-WEBSITE"
                                    /> is a MITRE led effort to assign common identifiers to publicly
                                    known security vulnerabilities in software to facilitate the sharing
                                    of information related to the vulnerabilities. CVE is the industry
                                    standard by which software vendors, tools, and security
                                    professionals identify vulnerabilities and could be used to address
                                    SACM's need for a vulnerability identifier.</t>
                            </section>
                        </section>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION"
                    title="Endpoint characterization">
                    <t>Target when policies (collection, evaluated, guidance) apply</t>
                    <t>Collection can be used to further characterize</t>
                    <t>Also human input</t>
                    <t>Information required to characterize an endpoint is used to determine what
                        endpoints are the target of a posture assessment. It is also used to determine
                        the collection, evaluation, and/or reporting policies and the associated
                        guidance that apply to the assessment. Endpoint characterization information may
                        be populated by:<list style="symbols">
                            <t>A manual input process and entered into records associated with the
                                endpoint, or</t>
                            <t>Using information collected and evaluated by an assessment.</t>
                        </list></t>
                    <t>Regardless of the method of collection, it will be necessary to query and
                        exchange endpoint characterization information as part of the assessment
                        planning workflow.</t>
                    <section title="Related Work" toc="exclude">
                        <section title="Extensible Configuration Checklist Description Format"
                            toc="exclude">
                            <section title="Background" anchor="XCCDF-BACKGROUND">
                                <t>The Extensible Configuration Checklist Description Format (XCCDF) is
                                    a specification that provides an XML-based format for expressing
                                    security checklists. The XCCDF 1.2 specification is published by
                                    International Organization for Standardization (ISO) <xref
                                        target="ISO.18180"/>. XCCDF contains multiple components and
                                    capabilities, and various components align with different elements
                                    of this information model.</t>
                                <t>This specification was originally published by NIST <xref
                                        target="NISTIR-7275"/>. When contributed to ISO Joint Technical
                                    Committee 1 (JTC 1), a comment was introduced indicating an interest
                                    in the IETF becoming the maintenance organization for this standard.
                                    If the SACM working group is interested in taking on engineering
                                    work pertaining to XCCDF, a contribution through a national body can
                                    be made to create a ballot resolution for transition of this
                                    standard to the IETF for maintenance.</t>
                            </section>
                            <section title="Applicability to Endpoint characterization"
                                anchor="IM-ELEMENTS-XCCDF-CHARACTERIZATION">
                                <t>The target component of XCCDF provides a mechanism for capturing
                                    characteristics about an endpoint including the fully qualified
                                    domain name, network address, references to external identification
                                    information (e.g. Asset Identification), and is extensible to
                                    support other useful information (e.g. MAC address, globally unique
                                    identifier, certificate, etc.). XCCDF may serve as a good starting
                                    point for understanding the types of information that should be used
                                    to identify an endpoint.</t>
                            </section>
                        </section>
    
                        <section title="Asset Reporting Format" toc="exclude">
                            <section title="Background" anchor="ARF-BACKGROUND" toc="exclude">
                                <t>The Asset Reporting Format (ARF) <xref target="NISTIR-7694"/> is a
                                    data model to express information about assets, and the
                                    relationships between assets and reports. It facilitates the
                                    reporting, correlating, and fusing of asset information within and
                                    between organizations. ARF is vendor and technology neutral,
                                    flexible, and suited for a wide variety of reporting
                                    applications.</t>
                                <t>There are four major sub-components of ARF:<list style="symbols">
                                        <t>Asset: The asset component element includes asset
                                            identification information for one or more assets. It simply
                                            houses assets independent of their relationships to reports.
                                            The relationship section can then link the report section to
                                            specific assets.</t>
                                        <t>Report: The report component element contains one or more
                                            asset reports. An asset report is composed of content (or a
                                            link to content) about one or more assets.</t>
                                        <t>Report-Request: The report-request component element contains
                                            the asset report requests, which can give context to asset
                                            reports captured in the report section. The report-request
                                            section simply houses asset report requests independent of
                                            the report which was subsequently generated.</t>
                                        <t>Relationship: The relationship component element links
                                            assets, reports, and report requests together with
                                            well-defined relationships. Each relationship is defined as
                                            {subject} {predicate} {object}, where {subject} is the
                                            asset, report request, or report of interest, {predicate} is
                                            the relationship type being established, and {object} is one
                                            or more assets, report requests, or reports.</t>
                                    </list></t>
                            </section>
                            <section title="Relationship to Endpoint Characterization" toc="exclude">
                                <t>For Endpoint Characterization, ARF can be used in multiple ways due
                                    to its flexibility. ARF supports the use of the Asset Identification
                                    specification (more in <xref target="IM-ELEMENTS-CHAR-AI"/>) to
                                    embed the representation of one or more assets as well as
                                    relationships between those assets. It also allows the inclusion of
                                    report-requests, which can provide details on what data was required
                                    for an assessment.</t>
                                <t>ARF is agnostic to the data formats of the collected posture
                                    attributes and therefore can be used within the SACM Architecture to
                                    provide Endpoint Characterization without dictating data formats for
                                    the encoding of posture attributes. The embedded Asset
                                    Identification data model (see <xref target="AI-BACKGROUND"/>) can
                                    be used to characterize one or more endpoints to allow targeting for
                                    collection, evaluation, etc. Additionally, the report-request model
                                    can dictate the type of reporting that has been requested, thereby
                                    providing context as to which endpoints the guidance applies. </t>
                            </section>
                            <section title="Asset Identification" anchor="IM-ELEMENTS-CHAR-AI"
                                toc="exclude">
                                <t>Described earlier</t>
                                <t>In the context of Endpoint Characterization, the Asset Identification
                                    data model could be used to encode information that identifies
                                    specific endpoints and/or classes of endpoints to which a particular
                                    assessment is relevant. The flexibility in the Asset Identification
                                    specification allows usage of various endpoint identifiers as
                                    defined by the SACM engineering work.</t>
                                <t>As stated in <xref target="IM-ELEMENTS-CHAR-AI"/>, the Asset
                                    Identification specification is included within the Asset Reporting
                                    Framework (ARF) and therefore can be used in concert with that
                                    specification as well.</t>
                            </section>
                        </section>
                        <section title="The CPE Applicability Language"
                            anchor="CPE-APPLICABILITY-BACKGROUND" toc="exclude">
                            <t>CPE described earlier</t>
                            <t>Applicability in CPE is defined as an XML language <xref
                                    target="NISTIR-7698"/> for using CPE names to create applicability
                                statements using logical expressions. These expressions can be used to
                                applicability statements that can drive decisions about assets, whether
                                or not to do things like collect data, report data, and execute policy
                                compliance checks.</t>
                            <t>It is recommended that SACM evolve the CPE Applicability Language through
                                engineering work to allow it to better fit into the security automation
                                vision laid out by the Use Cases and Architecture for SACM. This should
                                include de-coupling the identification part of the language from the
                                logical expressions, making it such that the language is agnostic to the
                                method by which assets are identified. This will allow use of SWID, CPE
                                Names, or other identifiers to be used, perhaps supported by an IANA
                                registry of identifier types.</t>
                            <t>The other key aspect that should be evolved is the ability to make use of
                                the Applicability Language against a centralized repository of collected
                                posture attributes. The language should be able to make applicability
                                statements against previously collected posture attributes, such that an
                                enterprise can quickly query the correct set of applicable endpoints in
                                an automated and scalable manner.</t>
                        </section>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-PA-EXPRESSION" title="Posture Attribute Expression">
                    <t>Discuss the catalog concept. Listing of things that can be chosen from. Things we
                        can know about. Vendors define catalogs. Ways for users to get vendor-provided
                        catalogs.</t>
                    <t>To support the collection of posture attributes, there needs to be a way for
                        operators to identify and select from a set of platform-specific attribute(s) to
                        collect. The same identified attributes will also need to be identified
                        post-collection to associate the actual value of that attribute pertaining to an
                        endpoint as it was configured at the time of the collection. To provide for
                        extensibility, the need exists to support a variety of possible identification
                        approaches. It is also necessary to enable vendors of software to provide a
                        listing, or catalog, of the available posture attributes to operators that can
                        be collected. Ideally, a federated approach will be used to allow organizations
                        to identify the location for a repository containing catalogs of posture
                        attributes provided by authoritative primary source vendors. By querying these
                        repositories, operators will be able to acquire the appropriate listings of
                        available posture attributes for their deployed assets. One or more posture
                        attribute expressions are needed to support these exchanges.</t>
                    <section title="Related Work" toc="exclude">
                        <t>The ATOM Syndication Format <xref target="RFC4287"/> provides an extensible,
                            flexible XML-based expression for organizing a collection of data feeds
                            consisting of entries. This standard can be used to express one or more
                            catalogs of posture attributes represented as data feeds. Groupings of
                            posture attributes would be represented as entries. These entries could be
                            defined using the data models described in the "Related Work" sections
                            below. Additionally, this approach can also be used more generally for
                            guidance repositories allowing other forms of security automation guidance
                            to be exchanged using the same format.</t>
                    </section>
                    <section title="Platform Configuration Attributes">
                        <t>A low-level, platform-dependent posture attribute as determined by the
                            authoritative primary source vendor. Collection guidance will be derived
                            from catalogs of platform specific posture attributes.</t>
                        <t>For example, a primary source vendor would create a platform-specific posture
                            attribute that best models the posture attribute data for their
                            platform.</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Open Vulnerability and Assessment Language">
                                <t>A general overview of OVAL was provided previously in <xref
                                        target="IM-ELEMENTS-OVAL-BACKGROUND"/>. The OVAL System
                                    Characteristics platform extension models provide a catalog of the
                                    posture attributes that can be collected from an endpoint. In OVAL
                                    these posture attributes are further grouped into logical constructs
                                    called OVAL Items. For example, the passwordpolicy_item that is part
                                    of the Windows platform extension groups together all the posture
                                    attributes related to passwords for an endpoint running Windows
                                    (e.g. maximum password age, minimum password length, password
                                    complexity, etc.). The various OVAL Items defined in the OVAL System
                                    Characteristics may serve as a good starting for the types of
                                    posture attribute data that needs to be collected from
                                    endpoints.</t>
                                <t>OVAL platform extension models may be shared using the ATOM
                                    Syndication Format.</t>
                            </section>
                            <section
                                title="Network Configuration Protocol and YANG Data Modeling Language"
                                anchor="NETCONF-BACKGROUND">
                                <!-- spell out -->
                                <t>The Network Configuration Protocol (NETCONF) <xref target="RFC6241"/>
                                    defines a mechanism for managing and retrieving posture attribute
                                    data from network infrastructure endpoints. The posture attribute
                                    data that can be collected from a network infrastructure endpoint is
                                    highly extensible and can defined using the YANG modeling language
                                        <xref target="RFC6020"/>. Models exist for common datatypes,
                                    interfaces, and routing subsystem information among other subjects.
                                    The YANG modeling language may be useful in providing an extensible
                                    framework for the SACM community to define one or more catalogs of
                                    posture attribute data that can be collected from network
                                    infrastructure endpoints.</t>
                                <t>Custom YANG modules may also be shared using the ATOM Syndication
                                    Format.</t>
                            </section>
                            <section
                                title="Simple Network Management Protocol and Management Information Base Entry"
                                anchor="SNMP-BACKGROUND">
                                <t>The Simple Network Protocol (SNMP) <xref target="RFC3411"/> defines a
                                    protocol for managing and retrieving posture attribute data from
                                    endpoints on a network . The posture attribute data that can be
                                    collected of an endpoint and retrieved by SNMP is defined by the
                                    Management Information Base (MIB) <xref target="RFC3418"/> which is
                                    hierarchical collection of information that is referenced using
                                    Object Identifiers . Given this, MIBs may provide an extensible way
                                    for the SACM community to define a catalog of posture attribute data
                                    that can be collected off of endpoints using SNMP.</t>
                                <t>MIBs may be shared using the ATOM Syndication Format.</t>
                            </section>
    
                        </section>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-ACTUAL-VALUE" title="Actual Value Representation">
                    <t>Discuss instance concept.</t>
                    <t>The actual value of a posture attribute is collected or published from an
                        endpoint. The identifiers discussed previously provide names for the posture
                        attributes (i.e., software or configuration item) that can be the subject of an
                        assessment. The information items listed below are the actual values collected
                        during the assessment and are all associated with a specific endpoint.</t>
                    <section title="Software Inventory">
                        <t>A software inventory is a list of software identifiers (or content)
                            associated with a specific endpoint. Software inventories are maintained in
                            some organized fashion so that entities can interact with it. Just having
                            software publish identifiers onto an endpoint is not enough, there needs to
                            be an organized listing of all those identifiers associated with that
                            endpoint.</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Asset Summary Reporting" anchor="ASR-BACKGROUND"
                                toc="exclude">
                                <t>The Asset Summary Reporting (ASR) specification <xref
                                        target="NISTIR-7848"/> provides a format for capturing summary
                                    information about one or more assets. Specifically, it provides the
                                    ability to express a collection of records from some defined data
                                    source and map them to some set of assets. As a result, this
                                    specification may be useful for capturing the software installed on
                                    an endpoint, its relevant attributes, and associating it with a
                                    particular endpoint.</t>
                            </section>
    
                            <section title="Software Identification Tags">
                                <t>SWID tag were previously introduced in <xref target="SWID-BACKGROUND"
                                    />. As stated before, SWID tags are ideally deployed to an endpoint
                                    during software installation. In the less ideal case, they may also
                                    be generated based on information retrieved from a proprietary
                                    software installation data store. At minimum, SWID tag must contain
                                    an identifier for each unit of installed software. Given this, SWID
                                    tags may be a viable way for SACM to express detailed information
                                    about the software installed on an endpoint.</t>
                            </section>
                        </section>
                    </section>
                    <section title="Collected Platform Configuration Posture Attributes">
                        <t>Configurations associated with a software instance associated with an
                            endpoint</t>
                        <t>A list of the configuration posture attributes associated with the actual
                            values collected from the endpoint during the assessment as
                            required/expressed by any related guidance. Additionally, each configuration
                            posture attribute is associated with the installed software instance it
                            pertains to.</t>
                        <section title="Related Work" toc="exclude">
                            <section title="Open Vulnerability and Assessment Language">
                                <t>A general overview of OVAL was provided previously in <xref
                                        target="IM-ELEMENTS-OVAL-BACKGROUND"/>. As mentioned earlier,
                                    the OVAL System Characteristics platform extensions provide a
                                    catalog of the posture attributes that can be collected and assessed
                                    in the form of OVAL Items. These OVAL Items also serve as a model
                                    for representing posture attribute data and associated values that
                                    are collected off an endpoint. Furthermore, the OVAL System
                                    Characteristics model provides a system_info construct that captures
                                    information that identifies and characterizes the endpoint from
                                    which the posture attribute data was collected. Specifically, it
                                    includes operating system name, operating system version, endpoint
                                    architecture, hostname, network interfaces, and an extensible
                                    construct to support arbitrary additional information that may be
                                    useful in identifying the endpoint in an enterprise such as
                                    information capture in Asset Identification constructs. The OVAL
                                    System Characteristics model could serve as a useful starting point
                                    for representing posture attribute data collected from an endpoint
                                    although it may need to undergo some changes to satisfy the needs of
                                    the SACM community.</t>
                            </section>
                            <section title="NETCONF-Based Collection">
                                <t>Introduced earlier in <xref target="NETCONF-BACKGROUND"/>, NETCONF
                                    defines a protocol for managing and retrieving posture attribute
                                    data from network infrastructure endpoints. NETCONF provides the
                                    &lt;get-config&gt; and &lt;get&gt; operations to retrieve the
                                    configuration data, and configuration data and state data
                                    respectively from a network infrastructure endpoint. Upon successful
                                    completion of these operations, the current posture attribute data
                                    of the network infrastructure endpoint will be made available.
                                    NETCONF also provides a variety of filtering mechanisms (XPath,
                                    subtree, content matching, etc.) to trim down the posture attribute
                                    data that is collected from the endpoint. Given that NETCONF is
                                    widely adopted by network infrastructure vendors, it may useful to
                                    consider this protocol as a standardized mechanism for collecting
                                    posture attribute data from network infrastructure endpoints.</t>
                                <t>As a side note, members of the OVAL Community have also developed a
                                    proposal to extend the OVAL Language to support the assessment of
                                    NETCONF configuration data <eref
                                        target="https://github.com/OVALProject/Sandbox/blob/master/x-netconf-definitions-schema.xsd"
                                    />. The proposal leverages XPath to extract the posture attribute
                                    data of interest from the XML data returned by NETCONF. The
                                    collected posture attribute data can then be evaluated using OVAL
                                    Definitions and the results of the evaluation can be expressed as
                                    OVAL Results. While this proposal is not currently part of the OVAL
                                    Language, it may be worth considering.</t>
                            </section>
                            <section title="SNMP-Based Collection">
                                <t>The SNMP, previously introduced in <xref target="SNMP-BACKGROUND"/>,
                                    defines a protocol for managing and retrieving posture attribute
                                    data from endpoints on a network <xref target="RFC3411"/>. SNMP
                                    provides three protocol operations <xref target="RFC3416"/>
                                    (GetRequest, GetNextRequest, and GetBulkRequest) for retrieving
                                    posture attribute data defined by MIB objects. Upon successful
                                    completion of these operations, the requested posture attribute data
                                    of the endpoint will be made available to the requesting
                                    application. Given that SNMP is widely adopted by vendors, and the
                                    MIBs that define posture attribute data on an endpoint are highly
                                    extensible, it may useful to consider this protocol as a
                                    standardized mechanism for collecting posture attribute data from
                                    endpoints in an enterprise.</t>
                            </section>
                        </section>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-EVALUATION-GUIDANCE" title="Evaluation Guidance">
                    <section title="Configuration Evaluation Guidance">
                        <t>The evaluation guidance is applied by evaluators during posture assessment of
                            an endpoint. This guidance must be able to reference or be associated with
                            the following previously defined information elements:<list style="symbols">
                                <t>configuration item identifiers,</t>
                                <t>platform configuration identifiers, and</t>
                                <t>collected Platform Configuration Posture Attributes.</t>
                            </list></t>
                        <section title="Related Work" toc="exclude">
                            <section title="Open Vulnerability and Assessment Language">
                                <t>A general overview of OVAL was provided previously in <xref
                                        target="IM-ELEMENTS-OVAL-BACKGROUND"/>. The OVAL Definitions
                                    model provides an extensible framework for making assertions about
                                    the state of posture attribute data collected from an endpoint.
                                    Guidance written against this model consists of one or more OVAL
                                    Tests, which can be logically combined, where each OVAL Test defines
                                    what posture attributes should be collected from an endpoint (as
                                    OVAL Objects) and optionally defines the expected state of the
                                    posture attributes (as OVAL States). While the OVAL Definitions
                                    model may be a useful starting point for evaluation guidance, it
                                    will likely require some changes to decouple collection and
                                    evaluation concepts to satisfy the needs of the SACM community.</t>
                            </section>
                            <section title="XCCDF Rule" anchor="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF">
                                <t>A general description of XCCDF was provided in <xref
                                        target="XCCDF-BACKGROUND"/>. As noted there, an XCCDF document
                                    represents a checklist of items against which a given endpoint's
                                    state is compared and evaluated. An XCCDF Rule represents one
                                    assessed item in this checklist. A Rule contains both a prose
                                    description of the assessed item (either for presentation to the
                                    user in a tool's user interface, or for rendering into a prose
                                    checklist for human consumption) and can also contain instructions
                                    to support automated evaluation of the assessed item, if such
                                    automated assessment is possible. Automated assessment instructions
                                    can be provided either within the XCCDF Rule itself, or by providing
                                    a reference to instructions expressed in other languages, such as
                                    OVAL.</t>
                                <t>In order to support greater flexibility in XCCDF, checklists can be
                                    tailored to meet certain needs. One way to do this is to enable or
                                    disable certain rules that are appropriate or inappropriate to a
                                    given endpoint, respectively. For example, a single XCCDF checklist
                                    might contain check items to evaluate the configuration of an
                                    endpoint's operating system. An endpoint deployed in an enterprise's
                                    DMZ might need to be locked down more than a common internal
                                    endpoint, due to the greater exposure to attack. In this case, some
                                    operating system configuration requirements for the DMZ endpoint
                                    might be unnecessary for the internal endpoint. Nonetheless, most
                                    configuration requirements would probably remain applicable to both
                                    environments (providing a common baseline for configuration of the
                                    given operating system) and thus be common to the checking
                                    instructions for both types of endpoints. XCCDF supports this by
                                    allowing a single checklist to be defined, but then tailored to the
                                    needs of the assessed endpoint. In the previous example, some Rules
                                    that apply only to the DMZ endpoint would be disabled during the
                                    assessment of an internal endpoint and would not be exercised during
                                    the assessment or count towards the assessment results. To
                                    accomplish this, XCCDF uses the CPE Applicability Language. By
                                    enhancing this applicability language to support other aspects of
                                    endpoint characterization (see <xref
                                        target="CPE-APPLICABILITY-BACKGROUND"/>), XCCDF will also
                                    benefit from these enhancements.</t>
                                <t>In addition, XCCDF Rules also support parameterization, allowing
                                    customization of the expected value for a given check item. For
                                    example, the DMZ endpoint might require a password of at least 12
                                    characters, while an internal endpoint may only need 8 or more
                                    characters in its password. By employing parameterization of the
                                    XCCDF Rule, the same Rule can be used when assessing either type of
                                    endpoint, and simply be provided with a different target parameter
                                    each time to reflect the different role-based requirements. Sets of
                                    customizations can be stored within the XCCDF document itself: XCCDF
                                    Values store parameters values that can be used in tailoring, while
                                    XCCDF Profiles store sets of tailoring instructions, including
                                    selection of certain Values as parameters and the enabling and
                                    disabling of certain Rules. The tailoring capabilities supported by
                                    XCCDF allow a single XCCDF document to encapsulate configuration
                                    evaluation guidance that applies to a broad range of endpoint
                                    roles.</t>
                            </section>
                        </section>
                    </section>
                </section>
    
                <section anchor="IM-ELEMENTS-EVAL-REPORTING" title="Evaluation Result Reporting">
                    <section title="Configuration Evaluation Results">
                        <t>The evaluation guidance applied during posture assessment of an endpoint to
                            customize the behavior of evaluators. Guidance can be used to define
                            specific result output formats or to select the level-of-detail for the
                            generated results. This guidance must be able to reference or be associated
                            with the following previously defined information elements:<list
                                style="symbols">
                                <t>configuration item identifiers,</t>
                                <t>platform configuration identifiers, and</t>
                                <t>collected Platform Configuration Posture Attributes.</t>
                            </list></t>
                        <section title="Related Work" toc="exclude">
                            <section title="XCCDF TestResults" toc="exclude">
                                <t>A general description of the eXtensible Configuration Checklist
                                    Description Format (XCCDF) was provided in section <xref
                                        target="XCCDF-BACKGROUND"/>. The XCCDF TestResult structure
                                    captures the outcome of assessing a single endpoint against the
                                    assessed items (i.e., XCCDF Rules) contained in an XCCDF instance
                                    document. XCCDF TestResults capture a number of important pieces of
                                    information about the assessment including:<list style="symbols">
                                        <t>The identity of the assessed endpoint. See <xref
                                                target="IM-ELEMENTS-XCCDF-CHARACTERIZATION"/> for more
                                            about XCCDF structures used for endpoint identification.</t>
                                        <t>Any tailoring of the checklist that might have been employed.
                                            See <xref target="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF"/> for
                                            more on how XCCDF supports tailoring.</t>
                                        <t>The individual results of the assessment of each enabled
                                            XCCDF Rule in the checklist. See <xref
                                                target="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF"/> for more on
                                            XCCDF Rules.</t>
                                    </list></t>
                                <t>The individual results for a given XCCDF Rule capture only whether
                                    the rule "passed", "failed", or experienced some exceptional
                                    condition, such as if an error was encountered during assessment.
                                    XCCDF 1.2 Rule results do not capture the actual state of the
                                    endpoint. For example, an XCCDF Rule result might indicate that an
                                    endpoint failed to pass requirement that passwords be of a length
                                    greater than or equal to 8, but it would not capture that the
                                    endpoint was, in fact, only requiring passwords of 4 or more
                                    characters. It may, however, be possible for a user to discover this
                                    information via other means. For example, if the XCCDF Rule uses an
                                    OVAL Definition to effect the Rule's evaluation, then the actual
                                    endpoint state may be captured in the corresponding OVAL System
                                    Characteristics file.</t>
                                <t>The XCCDF TestResult structure does provide a useful structure for
                                    understanding the overall assessment that was conducted and the
                                    results thereof. The ability to quickly determine the Rules that are
                                    not complied with on a given endpoint allow administrators to
                                    quickly identify where remediation needs to occur.</t>
                            </section>
    
                            <section title="Open Vulnerability and Assessment Language" toc="exclude">
                                <t>A general overview of OVAL was provided previously in <xref
                                        target="IM-ELEMENTS-OVAL-BACKGROUND"/>. OVAL Results provides a
                                    model for expressing the results of the assessment of the actual
                                    state of the posture attribute values collected of an endpoint
                                    (represented as an OVAL System Characteristics document) against the
                                    expected posture attribute values (defined in an OVAL Definitions
                                    document. Using OVAL Directives, the granularity of OVAL Results can
                                    also be specified. The OVAL Results model may be useful in providing
                                    a format for capturing the results of an assessment.</t>
                            </section>
                            <section title="Asset Summary Reporting" toc="exclude">
                                <t>A general overview of ASR was provided previously in <xref
                                        target="ASR-BACKGROUND"/>. As ASR provides a way to report
                                    summary information about assets, it can be used within the SACM
                                    Architecture to provide a way to aggregate asset information for
                                    later use. It makes no assertions about the data formats used by the
                                    assessment, but rather provides an XML, record-based way to collect
                                    aggregated information about assets.</t>
                                <t>By using ASR to collect this summary information within the SACM
                                    Architecture, one can provide a way to encode the details used by
                                    various reporting requirements, including user-definable
                                    reports.</t>
                            </section>
                            <section title="ARF" toc="exclude">
                                <t>A general overview of ARF was provided previously in <xref
                                        target="ARF-BACKGROUND"/>. Because ARF is data model agnostic,
                                    it can provide a flexible format for exchanging collection and
                                    evaluation information from endpoints. It additionally provides a
                                    way to encode relationships between guidance and assets, and as
                                    such, can be used to associate assessment results with guidance.
                                    This could be the guidance that directly triggered the assessment,
                                    or for guidance that is run against collected posture attributes
                                    located in a central repository.</t>
                            </section>
                        </section>
                    </section>
                    <section title="Software Inventory Evaluation Results">
                        <t>The results of an evaluation of an endpoint's software inventory against an
                            authorized software list. The authorized software list represents the policy
                            for what software units are allowed, prohibited, and mandatory for an
                            endpoint.</t>
                    </section>
                </section>
            </section>
        </section>
        <section title="Graph Model">

            <t>TODO: Write text on how the information model above
               can be realized in this kind of graph model.</t>

            <t>The graph model describes how security information is structured,
                related, and accessed. Control of operations to supply and/or access the data is
                architecturally distinct from the structuring of the data in the information model.
                Authorization may be applied by the Control Plane (as defined in the SACM
                Architecture <xref target="I-D.ietf-sacm-architecture"/>) to requests for
                information from a consumer or requests for publication from a provider, and may
                also be applied by a provider to a direct request from a consumer.</t>

            <t>This architecture addresses information structure independently of the access/transport of
                that information. This separation enables scalability, customizability, and extensibility.
                Access to provide or consume information is particularly suited to publish/subscribe/query
                data transport and data access control models.</t>

            <t>This graph model is a framework that:<list style="symbols">

                    <t>Facilitates the definition of extensible data types that support SACM's use
                        cases</t>

                    <t>Provides a structure for the defined data types to be exchanged via a variety
                        of data transport models</t>

                    <t>Describes components used in information exchange, and the objects exchanged</t>

                    <t>Captures and organizes evolving information and
                        information relationships for multiple data publishers</t>

                    <t>Provides access to the published information via publish, query, and subscribe
                        operations</t>

                    <t>Leverages the knowledge and experience gained from incorporating TNC IF-MAP
                        into many disparate products that have to integrate and share an information
                        model in a scalable, extensible manner</t>
                </list></t>


             <section title="Background: Graph Models">

                    <t>Knowledge is often represented with graph-based formalisms. A common
                        formalism defines a graph as follows:<list style="symbols">

                            <t>A set of *vertices*</t>

                            <t>A set of *edges*, each connecting two vertices (technically, an edge
                                is an ordered pair of vertices)</t>

                            <t>A set of zero or more *properties* attached to each vertices and
                                edges. Each property consists of a type and a optionally a value.
                                The type and the value are typically just strings</t>
                        </list></t>


                    <figure title="Knowledge represented by a graph"
                        anchor="figure-knownledge-graph">
                        <artwork><![CDATA[
   +------------------+                 +-----------------+
   | Id:          1   |   parent-of     |Id:          2   |
   | Given name:  Sue | --------------> |Given name:  Ann |
   | Family name: Wong|                 |Family name: Wong|
   +------------------+                 +-----------------+

         A VERTEX          AN EDGE           A VERTEX
]]></artwork>
                    </figure>

                    <t>A pair of vertices connected by an edge is commonly referred to as a triple
                        that comprises subject, predicate and object. For example, subject = Sue
                        Wong, predicate = is-parent-of, object = Ann Wong. A common language that
                        uses this representation is the Resource Description Framework (RDF) <xref
                            target="W3C.REC-rdf11-concepts-20140225"/>.</t>
            </section>

            <section title="Graph Model Overview">

                    <t>The proposed model, influenced by IF-MAP, is a labeled graph: each vertex has a label.</t>

                    <t>A table of synonyms follows.</t>

                    <texttable>
                        <ttcol>Graph Theory</ttcol>
                        <ttcol>Graph Databases</ttcol>
                        <ttcol>IF-MAP and This Internet Draft</ttcol>

                        <c>Vertex or Node</c>
                        <c>Node</c>
                        <c>-</c>

                        <c>Label</c>
                        <c>-</c>
                        <c>Identifier</c>

                        <c>Edge</c>
                        <c>Edge</c>
                        <c>Link</c>

                        <c>-</c>
                        <c>Property</c>
                        <c>Metadata Item</c>
                    </texttable>

                    <t>In this mode, identifiers and metadata have hierarchical structure.</t>

                    <t>The graphical aspect makes this model well suited to non-hierarchical
                        relationships, such as connectivity in a computer network.</t>

                    <t>Hierarchical properties allow this model to accommodate structures such as
                        YANG <xref target="RFC6020"/> data models.</t>
            </section>
            <section title="Identifiers">

                    <t>Each identifier is an XML element. For extensibility, schemas use
                        xsd:anyAttribute and such. </t>

                    <t>Alternately, this model could be changed to use another hierarchical
                        notation, such as JSON.</t>

                    <t>Identifiers are unique: two different vertices cannot have equivalent
                        identifiers.</t>

                    <t>An identifier has a type. There is a finite, but extensible, set of
                        identifier types. If the identifier is XML, the type is based on the XML
                        schema.</t>

                    <t>In IF-MAP, standard identifier types include IP address, MAC address,
                        identity, and overlay network. Additional identifier types will need to be
                        standardized for SACM use cases.</t>

                    <t>Any number of metadata items can be attached to an identifier.</t>

                    <t>Some identifiers, especially those relating to identity, address, and
                        location, require the ability to specify an administrative domain (such as
                        AD domain, L2 broadcast domain / L3 routing domain, or geographic domain) in
                        order to differentiate between instances with the same name occurring in
                        different realms.</t>
            </section>
            <section title="Links">

                    <t>A link can be thought of as an ordered pair of identifiers.</t>

                    <t>Any number of metadata items can be attached to a link.</t>
                </section>

                <section title="Metadata">

                    <t>A metadata item is the basic unit of information, and is attached to an
                        identifier or to a link.</t>

                    <t>A given metadata item is an XML document. In IF-MAP metadata items are generally small. However, larger ones, such as YANG data models, can also fit. For
                        extensibility, the XML schemas of metadata items use xsd:anyAttribute and such.</t>

                    <t>Alternately, this model could be changed to use another hierarchical
                        notation, such as JSON.</t>

                    <t>A metadata item has a type. There is a finite, but extensible, set of
                        metadata types. If the metadata item is XML, the type is based on the XML
                        schema. An example metadata type is
                        http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device-
                        characteristic.</t>

                    <t>TNC IF-MAP Metadata for Network Security <xref
                            target="TNC-IF-MAP-NETSEC-METADATA"/> and TNC IF-MAP Metadata for ICS
                        Security <xref target="TNC-IF-MAP-ICS-METADATA"/> define many pertinent
                        metadata types. More will need to be standardized for SACM use cases.</t>
            </section>
                
            <section title="Use for SACM">
                 <t>Many of the information elements
                    can be represented as vertices, and many of the
                            relationships can be represented as edges.</t>
                 <t>Identifiers are like database keys. For example, there would be identifiers for addresses, identities, unique endpoint identifiers, software component identifiers, and hardware component identifiers. The inventory of software instances and hardware instances within an endpoint might be expressed using a single YANG description, as a single metadata item in the graph. Where to put Endpoint Attribute Assertions, Evaluation Results, and the like is an open question.</t>
            </section>
 
            <section title="Provenance" anchor="sec-im-tnc-graph-provenance">
                    
                    <t>Provenance helps to protect the SACM ecosystem against a misled or malicious
                        provider.</t>
                    
                    <t>The provenance of a metadata item includes:<list style="symbols">
                        
                        <t>The time when the item was produced</t>
                        
                        <t>The component that produced the item, including its software and
                            version</t>
                        
                        <t>The policies that governed the producing component, with versions</t>
                        
                        <t>The method used to produce the information (e.g., vulnerability
                            scan)</t>
                    </list></t>
                    
                    <t>How provenance should be expressed is an open question. For reference, in
                        IF-MAP provenance of a metadata item is expressed within the metadata item
                        <xref target="TNC-IF-MAP-NETSEC-METADATA"/>. For example, there is a
                        top-level XML attribute called "timestamp".</t>
                    
                    <t>It is critical that provenance be secure from tampering. How to achieve that
                        security is out of scope of this document.</t>
            </section>

            <section title="Extensibility">
                    
                    <t>Anyone can define an identifier type or a metadata type, by creating an XML
                        schema (or other specification). There is no need for a central authority.
                        Some deployments may exercise administrative control over the permitted
                        identifier types and metadata types; others may leave components free
                        rein.</t>
                    
                    <t>A community of components can agree on and use new identifier and metadata
                        types, if the administrators allow it. This allows rapid innovation.
                        Intermediate software that conveys graph changes from one component to
                        another does not need changes. Components that do not understand the new
                        types do not need changes. Accordingly, a consumer normally ignores metadata
                        types and identifier types it does not understand.</t>
                    
                    <t>As a proof point for this agility, the original use cases for TNC IF- MAP
                        Binding for SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/> were addressed in
                        TNC IF-MAP Metadata for Network Security <xref
                            target="TNC-IF-MAP-NETSEC-METADATA"/>. Some years later an additional,
                        major set of use cases, TNC IF-MAP Metadata for ICS <xref
                            target="TNC-IF-MAP-ICS-METADATA"/>, were specified and implemented.</t>
            </section>

        </section>
        
        <!-- Change Log
          
v00 2014-10-24  LLL   Initial version

      -->
    </back>
</rfc>