+-----+______________+---------+                +---------+
 | AVP |1  <subject  *|assertion|________________|predicate|
 |     |______________|         |*  predicate>  1+---------+
 +-----+1  <object   *+---------+
    1^                     |*
     |_____________________|
            <asserter
     

Figure 12: Information Elements, Take 2

Note: UML 2 is specified by [UML].

TODO: update text to match new figure:

Need to be clear in the description that ???

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

6.1. Identifying Attributes

TODO: Need to rename this section to align with new "designation" term.

Identifying attributes let a consumer identify an endpoint, for two purposes:

• To tell whether two endpoint attribute assertions concern the same endpoint
• To respond to compliance measurements, for example by reporting, remediating, and quarantining (SACM does not specify these responses, but SACM exists to enable them.)

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

6.1.1. How Known

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.

• "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)
• "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).
• "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.
• "Verification" means that the provider has verified the information. For example:
  • The provider does IP communication with the endpoint and knows the IP address with which it communicates.
  • The provider makes an SSH connection to the endpoint and knows the endpoint's public key by virtue of authenticating it.
  • The monitored endpoint is a virtual machine and the provider knows by peeking into it.

TODO: Explain security considerations and how consumers are meant to use these markings.

6.1.2. Whether to Include

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.

6.1.3. Certificate

6.1.3.1. Range of values

MUST be X.509 certificate, per [RFC5280].

6.1.3.2. Meaning

Throughout the time interval of the AVP, the endpoint had the private key corresponding to the specified certificate.

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?

6.1.3.3. Multiplicity

An endpoint may use, or have the right to use, one or more certificates.

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?

6.1.3.4. Stability

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.

A private key is baked into hardware is almost immutable. But again, hardware can be replaced.

6.1.3.5. Accuracy

If a certificate is known by verification, the attribute is highly accurate.

6.1.3.6. Data model requirements

All SACM data models MUST support this entire subsection.

6.1.4. Public Key

TODO

6.1.5. Username?

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?

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.

6.1.6. Tool-Specific Identifier

TODO

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?"

6.1.7. Identification of Endpoints where SACM Components Reside

Every information element needs identifying attributes of its producer's endpoint. (TODO: Provide normative language. SHOULD? MUST?)

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.)

6.1.8. Security Considerations

Effects of misidentification

Things that can cause misidentification

How minimize misidentification

6.2. Identity

TODO: Delete this section?

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.

A data model MUST support the following relationships:

• 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.
• 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.

6.3. Location

TODO: Delete this section?

Location can be logical or physical. Location can be a clue to an endpoint's identity.

A data model MUST support the following relationships:

• One or more endpoints may be "in" a location
• A location may be "in" one or more locations
• A network address may be "in" a location
• 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

Examples of location:

• The switch, access point, VPN gateway, or cell tower to which the endpoint is linked
• The switch port where the endpoint is plugged in
• The location of the endpoint's IP address in the network topology
• The geographic location of the endpoint (which is often self-reported)
• A user location (may be reported by a physical access control system)

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?

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.

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

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

6.4. Endpoint Attribute Assertion

TODO: Integrate into the Section 4 as appropriate.

6.4.1. Form and Precise Meaning

An endpoint attribute assertion has:

• One or more attribute-value pairs (AVPs)
• Time intervals over which the AVPs hold
• Endpoint uniquely identified? True or false
• Provenance, including:
  • The SACM component that made the assertion
  • Information about the method used to derive the assertion

It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.

If the "Endpoint uniquely identified" is true, the set of attributes-value pairs together make this assertion apply to only one endpoint.

The attributes can include posture attributes and identification attributes. The model does not make a rigid distinction between the two uses of attributes.

Some of the attributes may be multi-valued.

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.

6.4.2. Asserter

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.

6.4.3. Example

For example, an attribute assertion might have these attribute-value pairs:

• mac-address = 01:23:45:67:89:ab
• os = OS X
• os-version = 10.6.8

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.

6.4.4. A Use Case

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:

• The endpoint's MAC address
• The authenticated identity (even if it identifies a user)
• The location of the endpoint and the user

6.4.5. Difference between Attribute and Event

Author: Henk Birkholz

"Attribute" and "event" are often used fairly interchangeably. A clear distinction makes the words more useful.

An *attribute* tends not to change until something causes a change. In contrast, an *event* occurs at a moment in time.

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).

The door's opening or closing is an event.

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.

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

6.5. Attribute-Value Pair

TODO: Integrate into the Section 4 as appropriate.

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.

The value may be structured. For example, it may something like XML.

The information model requires a standard attribute type (or possibly more than one) for each box in Figure 10:

• Hardware Component: the value identifies the hardware type. For example, it may consist of the make and model number.
• 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.
• 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.
• Software Instance: the value describes how the software component is installed and configured.
• Endpoint: The value is a unique endpoint identifier.
• Location
• 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.
• Network Interface: TBD
• 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?]
• Address: The value is an IP, MAC, or other network address, possibly qualified with its scope.

6.5.1. Unique Endpoint Identifier

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.

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.

If the attribute type of an AVP is "endpoint", the value is a unique identifier of the endpoint.

6.5.2. Posture Attribute

Some AVPs will be posture attributes.

See the definition in the SACM Terminology for Security Assessment [I-D.ietf-sacm-terminology].

Some potential kinds of posture attributes are:

• A NEA posture attribute (PA) [RFC5209]
• A YANG model [RFC6020]
• An IF-MAP device-characteristics metadata item [TNC-IF-MAP-NETSEC-METADATA]

6.6. Evaluation Result

Evaluation Results (see [I-D.ietf-sacm-terminology]) are modeled as Endpoint Attribute Assertions.

An Evaluation Result derives from one or more other Endpoint Attribute Assertions.

An example is: a NEA access recommendation [RFC5793]

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.

An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. (Figure 10 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.

6.7. Organization?

[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.]

[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.]

6.8. Guidance

[jmf- the guidance sections need more detail. . .]

[cek - What is missing? We would welcome a critique or text.]

Guidance is generally configurable by human administrators.

6.8.1. Internal Collection Guidance

An internal collector may need guidance to govern what it collects and when.

6.8.2. External Collection Guidance

An external collector may need guidance to govern what it collects and when.

6.8.3. Evaluation Guidance

An evaluator typically needs Evaluation Guidance to govern what it considers to be a good or bad security posture.

6.8.4. Retention Guidance

A SACM deployment may retain posture attributes, events, or evaluation results for some time. Retention supports ad hoc reporting and other use cases.

If information is retained, retention guidance controls what is retained and for how long.

If two or more pieces of retention guidance apply to a piece of information, the guidance calling for the longest retention should take precedence.

6.9. Endpoint

See the definition in the SACM Terminology for Security Assessment [I-D.ietf-sacm-terminology].

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.

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.

6.9.1. Endpoint Identity

An endpoint identity provides both identification and authentication of the endpoint. For example, an identity may be an X.509 certificate [RFC5280] and corresponding private key. [jmf- this example should be formatted like the other examples in this section]

Not all kinds of identities are guaranteed to be unique.

6.9.2. Software Component

An endpoint contains and runs software components.

Some of the software components are assets. "Asset" is defined in RFC4949 [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."

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).

Examples of Software Assets:

• An application
• A patch
• The operating system kernel
• A boot loader
• Firmware that controls a disk drive
• A piece of JavaScript found in a web page the user visits

Examples of harmful software components:

• A malicious entertainment app
• A malicious executable
• A web page that contains malicious JavaScript
• A business application that shipped with a virus

6.9.2.1. Unique Software Identifier

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.

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

6.10. User

6.10.1. User Identity

An endpoint is often - but not always - associated with one or more users.

A user's identity provides both identification and authentication of the user. @@@ Eh?

6.11. hardwareSerialNumber

elementId: TBD
name: hardwareSerialNumber
dataType: string
dataTypeSemantics: default
status: current
description: A globally unique identifier for a particular
             piece of hardware assigned by the vendor.
    

6.12. interfaceName

elementId: TBD
name: interfaceName
dataType: string
dataTypeSemantics: default
status: current
description: A short name uniquely describing an interface,
             eg "Eth1/0". See [RFC2863] for the definition
             of the ifName object.
    

6.13. interfaceIndex

elementId: TBD
name: interfaceIndex
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The index of an interface installed on an endpoint.
             The value matches the value of managed object
             'ifIndex' as defined in [RFC2863]. Note that ifIndex
             values are not assigned statically to an interface
             and that the interfaces may be renumbered every time
             the device's management system is re-initialized,
             as specified in [RFC2863].
    

6.14. interfaceMacAddress

elementId: TBD
name: interfaceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 MAC address associated with a network
             interface on an endpoint.
    

6.15. interfaceType

elementId: TBD
name: interfaceType
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The type of a network interface. The value matches 
             the value of managed object 'ifType' as defined in 
             [IANA registry ianaiftype-mib].
    

6.16. interfaceFlags

elementId: TBD
name: interfaceFlags
dataType: unsigned16
dataTypeSemantics: flags
status: current
description: This information element specifies the flags 
             associated with a network interface. Possible
             values include:
    

6.17. networkInterface

elementId: TBD
name: networkInterface
dataType: basicList
dataTypeSemantics: default
status: current
description: Information about a network interface 
             installed on an endpoint. The 
             following high-level digram  
             describes the structure of 
             networkInterface information 
             element.
    

             networkInterface = (basicList, allof,
                                 interfaceName,
                                 interfaceIndex,
                                 macAddress,
                                 ifType,
                                 flags
                                 )
    

6.18. softwareIdentifier

elementId: TBD
name: softwareIdentifier
dataType: string
dataTypeSemantics: default
status: current
description: A globally unique identifier for a particular 
             software application.
      

6.19. softwareTitle

elementId: TBD
name: softwareTitle
dataType: string
dataTypeSemantics: default
status: current
description: The title of the software application.
      

6.20. softwareCreator

elementId: TBD
name: softwareCreator
dataType: string
dataTypeSemantics: default
status: current
description: The software developer (e.g., vendor or author).      
      

6.21. simpleSoftwareVersion

elementId: TBD
name: simpleSoftwareVersion
dataType: simpleVersion
dataTypeSemantics: default
status: current
description: The version string for a software application that
             follows the simple versioning scheme.      
      

6.22. rpmSoftwareVersion

elementId: TBD
name: rpmSoftwareVersion
dataType: rpmVersion
dataTypeSemantics: default
status: current
description: The version string for a software application that
             follows the RPM versioning scheme.
      

6.23. ciscoTrainSoftwareVersion

elementId: TBD
name: ciscoTrainSoftwareVersion
dataType: ciscoTrainVersion
dataTypeSemantics: default
status: current
description: The version string for a software application that
             follows the Cisco Train Release versioning scheme.
      

6.24. softwareVersion

elementId: TBD
name: softwareVerison
dataType: basicList
dataTypeSemantics: default
status: current
description: The version of the software application. Software 
             applications may be versioned using a number of
             schemas. The following high-level digram describes
             the structure of the softwareVersion information
             element.

softwareVersion(basicList, exactlyOneOf,
                simpleSoftwareVersion,
                rpmSoftwareVersion,
                ciscoTrainSoftwareVersion,
                ...
               )     
      

6.25. lastUpdated

elementId: TBD
name: lastUpdated
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
description: The date and time when the software instance 
             was last updated on the system (e.g., new 
             version instlalled or patch applied)
      

6.26. softwareInstance

elementId: TBD
name: softwareInstance
dataType: subTemplateMultiList
dataTypeSemantics: default
status: current
description: Information about an instance of software 
             installed on an endpoint. The following 
             high-level digram describes the structure of 
             softwareInstance information element.

             softwareInstance = (subTemplateMultiList, allof,
                                 softwareIdentifier,
                                 title,
                                 creator,
                                 softwareVersion,
                                 lastUpdated
                                )      
    

6.27. globallyUniqueIdentifier

elementId: TBD
name: globallyUniqueIdentifier
dataType: unsigned8
dataTypeSemantics: identifier
status: current
metadata: true
description: TODO.
    

6.28. dataOrigin

elementId: TBD
name: dataOrigin
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The origin of the data. TODO make a better
             description.
    

6.29. dataSource

elementId: TBD
name: dataSource
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The source of the data. TODO make a better
             description.
    

6.30. creationTimestamp

elementId: TBD
name: creationTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
             information was created by a SACM Component.
    

6.31. collectionTimestamp

elementId: TBD
name: collectionTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
             information was collected or observed by a SACM
             Component.
    

6.32. publicationTimestamp

elementId: TBD
name: publicationTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
             information was published.
    

6.33. relayTimestamp

elementId: TBD
name: relayTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
             information was relayed to another SACM Component.
    

6.34. storageTimestamp

elementId: TBD
name: storageTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
             information was stored in a Repository.
    

6.35. type

elementId: TBD
name: type
dataType: unsigned16
dataTypeSemantics: flags
status: current
metadata: true
description: The type of data model use to represent
             some set of endpoint information. The following 
             table lists the set of data models supported by SACM.

             +-------+----------------------------------+
             | Value | Description                      |
             +-------+----------------------------------+
             | 0x00  | Data Model 1                     |
             +-------+----------------------------------+
             | 0x01  | Data Model 2                     |
             +-------+----------------------------------+
             | 0x02  | Data Model 3                     |
             +-------+----------------------------------+
             |...    | ...                              |
             +-------+----------------------------------+
    

6.36. protocolIdentifier

elementId: TBD
name: protocolIdentifier
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: The value of the protocol number in the IP packet 
             header. The protocol number identifies the IP packet 
             payload type. Protocol numbers are defined in the 
             IANA Protocol Numbers registry.
             
             In Internet Protocol version 4 (IPv4), this is 
             carried in the Protocol field.  In Internet Protocol 
             version 6 (IPv6), this is carried in the Next Header 
             field in the last extension header of the packet.

6.37. sourceTransportPort

elementId: TBD
name: sourceTransportPort
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: The source port identifier in the transport header.
             For the transport protocols UDP, TCP, and SCTP, this 
             is the source port number given in the respective 
             header.  This field MAY also be used for future 
             transport protocols that have 16-bit source port 
             identifiers.

6.38. sourceIPv4PrefixLength

elementId: TBD
name: sourceIPv4PrefixLength
dataType: unsigned8
dataTypeSemantics: 
status: current
description: The number of contiguous bits that are relevant in 
             the sourceIPv4Prefix Information Element.

6.39. ingressInterface

elementId: TBD
name: ingressInterface
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: The index of the IP interface where packets of this 
             Flow are being received.  The value matches the 
             value of managed object 'ifIndex' as defined in 
             [RFC2863]. Note that ifIndex values are not assigned 
             statically to an interface and that the interfaces 
             may be renumbered every time the device's management 
             system is re-initialized, as specified in [RFC2863].

6.40. destinationTransportPort

elementId: TBD
name: destinationTransportPort
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: The destination port identifier in the transport 
             header. For the transport protocols UDP, TCP, and 
             SCTP, this is the destination port number given in 
             the respective header. This field MAY also be used 
             for future transport protocols that have 16-bit 
             destination port identifiers.

6.41. sourceIPv6PrefixLength

elementId: TBD
name: sourceIPv6PrefixLength
dataType: unsigned8
dataTypeSemantics: 
status: current
description: The number of contiguous bits that are relevant in 
             the sourceIPv6Prefix Information Element.

6.42. sourceIPv4Prefix

elementId: TBD
name: sourceIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 source address prefix.

6.43. destinationIPv4Prefix

elementId: TBD
name: destinationIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 destination address prefix.

6.44. sourceMacAddress

elementId: TBD
name: sourceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 source MAC address field.

6.45. ipVersion

elementId: TBD
name: ipVersion
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: The IP version field in the IP packet header.

6.46. interfaceDescription

elementId: TBD
name: interfaceDescription
dataType: string
dataTypeSemantics: default
status: current
description: The description of an interface, eg "FastEthernet 
             1/0" or "ISP 
connection".

6.47. applicationDescription

elementId: TBD
name: applicationDescription
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the description of an application.

6.48. applicationId

elementId: TBD
name: applicationId
dataType: octetArray
dataTypeSemantics: default
status: current
description: Specifies an Application ID per [RFC6759].

6.49. applicationName

elementId: TBD
name: applicationName
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the name of an application.

6.50. exporterIPv4Address

elementId: TBD
name: exporterIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: The IPv4 address used by the Exporting Process. 
             This is used by the Collector to identify the 
             Exporter in cases where the identity of the Exporter 
             may have been obscured by the use of a proxy.

6.51. exporterIPv6Address

elementId: TBD
name: exporterIPv6Address
dataType: ipv6Address
dataTypeSemantics: default
status: current
description: The IPv6 address used by the Exporting Process.  
             This is used by the Collector to identify the 
             Exporter in cases where the identity of the 
             Exporter may have been obscured by the use of a 
             proxy.

6.52. portId

elementId: TBD
name: portId
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: An identifier of a line port that is unique per 
             IPFIX Device hosting an Observation Point.  
             Typically, this Information Element is used for 
             limiting the scope of other Information Elements.

6.53. templateId

elementId: TBD
name: templateId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: An identifier of a Template that is locally unique 
             within a combination of a Transport session and an 
             Observation Domain.       
              
             Template IDs 0-255 are reserved for Template Sets, 
             Options Template Sets, and other reserved Sets yet 
             to be created. Template IDs of Data Sets are 
             numbered from 256 to 65535.
                
             Typically, this Information Element is used for 
             limiting the scope of other Information Elements.
             Note that after a re-start of the Exporting Process 
             Template identifiers may be re-assigned.

6.54. collectorIPv4Address

elementId: TBD
name: collectorIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPv4 address to which the Exporting Process sends 
             Flow information.

6.55. collectorIPv6Address

elementId: TBD
name: collectorIPv6Address
dataType: ipv6Address
dataTypeSemantics: default
status: current
description: An IPv6 address to which the Exporting Process sends 
             Flow information.

6.56. informationElementIndex

elementId: TBD
name: informationElementIndex
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: A zero-based index of an Information Element
             referenced by informationElementId within a Template 
             referenced by templateId; used to disambiguate 
             scope for templates containing multiple identical 
             Information Elements.

6.57. informationElementId

elementId: TBD
name: informationElementId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: This Information Element contains the ID of another 
             Information Element.

6.58. informationElementDataType

elementId: TBD
name: informationElementDataType
dataType: unsigned8
dataTypeSemantics: 
status: current
description: A description of the abstract data type of an IPFIX
             information element.These are taken from the 
             abstract data types defined in section 3.1 of the 
             IPFIX Information Model [RFC5102]; see that section 
             for more information on the types described in the 
             informationElementDataType sub-registry.
                          
             These types are registered in the IANA IPFIX 
             Information Element Data Type subregistry.  This 
             subregistry is intended to assign numbers for type 
             names, not to provide a mechanism for adding data 
             types to the IPFIX Protocol, and as such requires a 
             Standards Action [RFC5226] to modify.

6.59. informationElementDescription

elementId: TBD
name: informationElementDescription
dataType: string
dataTypeSemantics: default
status: current
description: A UTF-8 [RFC3629] encoded Unicode string containing 
             a human-readable description of an Information 
             Element.  The content of the 
             informationElementDescription MAY be annotated with 
             one or more language tags [RFC4646], encoded 
             in-line [RFC2482] within the UTF-8 string, in order 
             to specify the language in which the description is 
             written.  Description text in multiple languages MAY 
             tag each section with its own language tag; in this 
             case, the description information in each language 
             SHOULD have equivalent meaning.  In the absence of 
             any language tag, the "i-default" [RFC2277] language 
             SHOULD be assumed.  See the Security Considerations 
             section for notes on string handling for Information 
             Element type records.

6.60. informationElementName

elementId: TBD
name: informationElementName
dataType: string
dataTypeSemantics: default
status: current
description: A UTF-8 [RFC3629] encoded Unicode string containing
             the name of an Information Element, intended as a 
             simple identifier.  See the Security Considerations 
             section for notes on string handling for Information 
             Element type records.

6.61. informationElementRangeBegin

elementId: TBD
name: informationElementRangeBegin
dataType: unsigned64
dataTypeSemantics: quantity
status: current
description: Contains the inclusive low end of the range of
             acceptable values for an Information Element.

6.62. informationElementRangeEnd

elementId: TBD
name: informationElementRangeEnd
dataType: unsigned64
dataTypeSemantics: quantity
status: current
description: Contains the inclusive high end of the range of
             acceptable values for an Information Element.

6.63. informationElementSemantics

elementId: TBD
name: informationElementSemantics
dataType: unsigned8
dataTypeSemantics: 
status: current
description: A description of the semantics of an IPFIX 
             Information Element.  These are taken from the data 
             type semantics defined in section 3.2 of the IPFIX 
             Information Model [RFC5102]; see that section for 
             more information on the types defined in the 
             informationElementSemantics sub-registry.  This 
             field may take the values in Table ; the special 
             value 0x00 (default) is used to note that no 
             semantics apply to the field; it cannot be 
             manipulated by a Collecting Process or File Reader 
             that does not understand it a priori.
                       
             These semantics are registered in the IANA IPFIX 
             Information Element Semantics subregistry.  This 
             subregistry is intended to assign numbers for 
             semantics names, not to provide a mechanism for 
             adding semantics to the IPFIX Protocol, and as such 
             requires a Standards Action [RFC5226] to modify.

6.64. informationElementUnits

elementId: TBD
name: informationElementUnits
dataType: unsigned16
dataTypeSemantics: 
status: current
description: A description of the units of an IPFIX Information
             Element.  These correspond to the units implicitly 
             defined in the Information Element definitions in 
             section 5 of the IPFIX Information Model [RFC5102]; 
             see that section for more information on the types 
             described in the informationElementsUnits 
             sub-registry. This field may take the values in 
             Table 3 below; the special value 0x00 (none) is 
             used to note that the field is unitless.
                          
             These types are registered in the IANA IPFIX 
             Information Element Units subregistry; new types 
             may be added on a First Come First Served [RFC5226] 
             basis.

6.65. userName

elementId: TBD
name: userName
dataType: string
dataTypeSemantics: default
status: current
description: User name associated with the flow.

6.66. applicationCategoryName

elementId: TBD
name: applicationCategoryName
dataType: string
dataTypeSemantics: default
status: current
description: An attribute that provides a first level 
             categorization for each Application ID.

6.67. mibObjectValueInteger

elementId: TBD
name: mibObjectValueInteger
dataType: signed64
dataTypeSemantics: identifier
status: current
description: An IPFIX Information Element which denotes that the
             integer value of a MIB object will be exported.  
             The MIB Object Identifier ("mibObjectIdentifier") 
             for this field MUST be exported in a MIB Field 
             Option or via another means.  This Information
             Element is used for MIB objects with the Base 
             Syntax of Integer32 and INTEGER with IPFIX Reduced 
             Size Encoding used as required. The value is 
             encoded as per the standard IPFIX Abstract Data Type
             of signed64.

6.68. mibObjectValueOctetString

elementId: TBD
name: mibObjectValueOctetString
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that an
             Octet String or Opaque value of a MIB object will 
             be exported. The MIB Object Identifier 
             ("mibObjectIdentifier") for this field MUST be 
             exported in a MIB Field Option or via another means. 
             This Information Element is used for MIB objects 
             with the Base Syntax of OCTET STRING and Opaque. The 
             value is encoded as per the standard IPFIX Abstract 
             Data Type of octetArray.

6.69. mibObjectValueOID

elementId: TBD
name: mibObjectValueOID
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that an
             Object Identifier or OID value of a MIB object will 
             be exported. The MIB Object Identifier 
             ("mibObjectIdentifier") for this field MUST be 
             exported in a MIB Field Option or via another means.  
             This Information Element is used for MIB objects 
             with the Base Syntax of OBJECT IDENTIFIER.  Note - 
             In this case the "mibObjectIdentifier" will define 
             which MIB object is being exported while the value 
             contained in this Information Element will be an 
             OID as a value.  The mibObjectValueOID Information
             Element is encoded as ASN.1/BER [BER] in an 
             octetArray.

6.70. mibObjectValueBits

elementId: TBD
name: mibObjectValueBits
dataType: octetArray
dataTypeSemantics: flags
status: current
description: An IPFIX Information Element which denotes that a 
             set of Enumerated flags or bits from a MIB object 
             will be exported. The MIB Object Identifier 
             ("mibObjectIdentifier") for this field MUST be 
             exported in a MIB Field Option or via another means.  
             This Information Element is used for MIB objects 
             with the Base Syntax of BITS.  The flags or bits are 
             encoded as per the standard IPFIX Abstract Data Type 
             of octetArray, with sufficient length to accommodate 
             the required number of bits.  If the number of bits 
             is not an integer multiple of octets then the most 
             significant bits at end of the octetArray MUST be 
             set to zero.

6.71. mibObjectValueIPAddress

elementId: TBD
name: mibObjectValueIPAddress
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that the
             IPv4 Address of a MIB object will be exported.  The 
             MIB Object Identifier ("mibObjectIdentifier") for 
             this field MUST be exported in a MIB Field Option 
             or via another means.  This Information Element is 
             used for MIB objects with the Base Syntax of 
             IPaddress. The value is encoded as per the standard 
             IPFIX Abstract Data Type of ipv4Address.

6.72. mibObjectValueCounter

elementId: TBD
name: mibObjectValueCounter
dataType: unsigned64
dataTypeSemantics: snmpCounter
status: current
description: An IPFIX Information Element which denotes that the
             counter value of a MIB object will be exported.  
             The MIB Object Identifier ("mibObjectIdentifier") 
             for this field MUST be exported in a MIB Field 
             Option or via another means.  This Information 
             Element is used for MIB objects with the Base 
             Syntax of Counter32 or Counter64 with IPFIX Reduced 
             Size Encoding used as required. The value is encoded 
             as per the standard IPFIX Abstract Data Type
             of unsigned64.

6.73. mibObjectValueGauge

elementId: TBD
name: mibObjectValueGauge
dataType: unsigned32
dataTypeSemantics: snmpGauge
status: current
description: An IPFIX Information Element which denotes that the
             Gauge value of a MIB object will be exported.  The 
             MIB Object Identifier ("mibObjectIdentifier") for 
             this field MUST be exported in a MIB Field Option 
             or via another means.  This Information Element is 
             used for MIB objects with the Base Syntax of Gauge32.
             The value is encoded as per the standard IPFIX 
             Abstract Data Type of unsigned64.  This value will 
             represent a non-negative integer, which may increase 
             or decrease, but shall never exceed a maximum
             value, nor fall below a minimum value.

6.74. mibObjectValueTimeTicks

elementId: TBD
name: mibObjectValueTimeTicks
dataType: unsigned32
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that the
             TimeTicks value of a MIB object will be exported.  
             The MIB Object Identifier ("mibObjectIdentifier") 
             for this field MUST be exported in a MIB Field 
             Option or via another means.  This Information 
             Element is used for MIB objects with the Base 
             Syntax of TimeTicks. The value is encoded as per 
             the standard IPFIX Abstract Data Type of unsigned32.

6.75. mibObjectValueUnsigned

elementId: TBD
name: mibObjectValueUnsigned
dataType: unsigned64
dataTypeSemantics: identifier
status: current
description: An IPFIX Information Element which denotes that an
             unsigned integer value of a MIB object will be 
             exported.  The MIB Object Identifier 
             ("mibObjectIdentifier") for this field MUST be
             exported in a MIB Field Option or via another means.  
             This Information Element is used for MIB objects 
             with the Base Syntax of unsigned64 with IPFIX 
             Reduced Size Encoding used as required. The value is 
             encoded as per the standard IPFIX Abstract Data Type
             of unsigned64.

6.76. mibObjectValueTable

elementId: TBD
name: mibObjectValueTable
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: An IPFIX Information Element which denotes that a 
             complete or partial conceptual table will be 
             exported.  The MIB Object Identifier 
             ("mibObjectIdentifier") for this field MUST be 
             exported in a MIB Field Option or via another means.  
             This Information Element is used for MIB objects 
             with a SYNTAX of SEQUENCE.  This is encoded as a 
             subTemplateList of mibObjectValue Information 
             Elements.  The template specified in the
             subTemplateList MUST be an Options Template and 
             MUST include all the Objects listed in the INDEX 
             clause as Scope Fields.

6.77. mibObjectValueRow

elementId: TBD
name: mibObjectValueRow
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: An IPFIX Information Element which denotes that a 
             single row of a conceptual table will be exported.  
             The MIB Object Identifier ("mibObjectIdentifier") 
             for this field MUST be exported in a MIB Field 
             Option or via another means.  This Information 
             Element is used for MIB objects with a SYNTAX of 
             SEQUENCE.  This is encoded as a subTemplateList of 
             mibObjectValue Information Elements.  The 
             subTemplateList exported MUST contain exactly one 
             row (i.e., one instance of the subtemplate).  The 
             template specified in the subTemplateList MUST be 
             an Options Template and MUST include all the 
             Objects listed in the INDEX clause as Scope Fields.

6.78. mibObjectIdentifier

elementId: TBD
name: mibObjectIdentifier
dataType: octetArray
dataTypeSemantics: default
status: current
description: An IPFIX Information Element which denotes that a 
             MIB Object Identifier (MIB OID) is exported in the 
             (Options) Template Record.  The mibObjectIdentifier 
             Information Element contains the OID assigned to 
             the MIB Object Type Definition encoded as 
             ASN.1/BER [BER].

6.79. mibSubIdentifier

elementId: TBD
name: mibSubIdentifier
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: A non-negative sub-identifier of an Object 
             Identifier (OID).

6.80. mibIndexIndicator

elementId: TBD
name: mibIndexIndicator
dataType: unsigned64
dataTypeSemantics: flags
status: current
description: This set of bit fields is used for marking the
             Information Elements of a Data Record that serve as 
             INDEX MIB objects for an indexed Columnar MIB 
             object.  Each bit represents an Information Element 
             in the Data Record with the n-th bit representing 
             the n-th Information Element.  A bit set to value 1
             indicates that the corresponding Information Element 
             is an index of the Columnar Object represented by 
             the mibFieldValue.  A bit set to value 0 indicates 
             that this is not the case.
                            
             If the Data Record contains more than 64 
             Information Elements, the corresponding Template 
             SHOULD be designed such that all INDEX
             Fields are among the first 64 Information Elements, 
             because the mibIndexIndicator only contains 64 bits.  
             If the Data Record contains less than 64 
             Information Elements, then the extra bits in the 
             mibIndexIndicator for which no corresponding 
             Information Element exists MUST have the value 0, 
             and must be disregarded by the Collector.  This 
             Information Element may be exported with
             IPFIX Reduced Size Encoding.

6.81. mibCaptureTimeSemantics

elementId: TBD
name: mibCaptureTimeSemantics
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: Indicates when in the lifetime of the flow the MIB
             value was retrieved from the MIB for a 
             mibObjectIdentifier.  This is used to indicate if 
             the value exported was collected from the MIB 
             closer to flow creation or flow export time and 
             will refer to the Timestamp fields included in the 
             same record.  This field SHOULD be used when 
             exporting a mibObjectValue that specifies counters 
             or statistics.
                         
             If the MIB value was sampled by SNMP prior to the 
             IPFIX Metering Process or Exporting Process 
             retrieving the value (i.e., the data is already 
             stale) and it's important to know the exact sampling 
             time, then an additional observationTime* element 
             should be paired with the OID using structured data.  
             Similarly, if different mibCaptureTimeSemantics 
             apply to different mibObject elements within the 
             Data Record, then individual mibCaptureTimeSemantics
             should be paired with each OID using structured data.           
                          
             Values:           
             0.  undefined
             1.  begin - The value for the MIB object is captured 
             from the MIB when the Flow is first observed
             2.  end - The value for the MIB object is captured 
             from the MIB when the Flow ends
             3.  export - The value for the MIB object is 
             captured from the MIB at export time
             4.  average - The value for the MIB object is an 
             average of multiple captures from the MIB over the 
             observed life of the Flow

6.82. mibContextEngineID

elementId: TBD
name: mibContextEngineID
dataType: octetArray
dataTypeSemantics: default
status: current
description: A mibContextEngineID that specifies the SNMP engine
             ID for a MIB field being exported over IPFIX.  
             Definition as per [RFC3411] section 3.3.

6.83. mibContextName

elementId: TBD
name: mibContextName
dataType: string
dataTypeSemantics: default
status: current
description: This Information Element denotes that a MIB Context
             Name is specified for a MIB field being exported 
             over IPFIX. Reference [RFC3411] section 3.3.

6.84. mibObjectName

elementId: TBD
name: mibObjectName
dataType: string
dataTypeSemantics: default
status: current
description: The name (called a descriptor in [RFC2578] 
             of an object type definition.

6.85. mibObjectDescription

elementId: TBD
name: mibObjectDescription
dataType: string
dataTypeSemantics: default
status: current
description: The value of the DESCRIPTION clause of an MIB object
             type definition.

6.86. mibObjectSyntax

elementId: TBD
name: mibObjectSyntax
dataType: string
dataTypeSemantics: default
status: current
description: The value of the SYNTAX clause of an MIB object type
             definition, which may include a Textual Convention 
             or Subtyping. See [RFC2578].

6.87. mibModuleName

elementId: TBD
name: mibModuleName
dataType: string
dataTypeSemantics: default
status: current
description: The textual name of the MIB module that defines a MIB
             Object.

7. SACM Usage Scenario Example

TODO: this section needs to refer out to wherever the operations / generalized workflow content ends up

TODO: revise to eliminate graph references

This section illustrates the proposed SACM Information Model as applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations [RFC7632]. The following subsections describe the elements (components and elements), graph model, and operations (sample workflow) required to support the Detection of Posture Deviations scenario.

The Detection of Posture Deviations scenario involves multiple elements interacting to accomplish the goals of the scenario. Figure 10 illustrates those elements along with their major communication paths.

7.1. Graph Model for Detection of Posture Deviation

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.

7.1.1. Components

The proposed SACM Information Model contains three components, as defined in the SACM Architecture [I-D.ietf-sacm-architecture]: Posture Attribute Information Provider, Posture Attribute Information Consumer, and Control Plane.

In this example, the components are instantiated as follows:

• 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.
• 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.
• 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.

7.1.2. Identifiers

To represent the elements listed above, the set of identifiers might include (but is not limited to):

• Identity - a device itself, or a user operating a device, categorized by type of identity (e.g. username or X.509 certificate [RFC5280])
• Software asset
• Network Session
• Address - categorized by type of address (e.g. MAC address, IP address, Host Identity Protocol (HIP) Host Identity Tag (HIT) [RFC5201], etc.)
• Task - categorized by type of task (e.g. internal collector, external collector, evaluator, or reporting task)
• Result - categorized by type of result (e.g. evaluation result or report)
• Guidance

7.1.3. Metadata

To characterize the elements listed above, the set of metadata types might include (but is not limited to):

• 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.
• Location metadata attached to a link between a network session identifier and an address identifier.
• 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.
• 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.

7.1.4. Relationships between Identifiers and Metadata

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.

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.

7.2. Workflow

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 [TNC-IF-MAP-SOAP-Binding] or XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows:

1. The analytics engine (Posture Assessment Information Consumer) establishes connectivity and authorization with the transport fabric, and subscribes to updates on posture deviations.
2. The endpoint security service (Posture Assessment Information Provider) requests connection to the transport fabric.
3. Transport fabric authenticates and establishes authorized privileges (e.g. privilege to publish and/or subscribe to security data) for the requesting components.
4. The endpoint security service evaluates the endpoint, detects posture deviation, and publishes information on the posture deviation.
5. The transport fabric notifies the analytics engine, based on its subscription of the new posture deviation information.

Other components, such as access control policy servers or remediation systems, may also consume the posture deviation information provided by the endpoint security service.

8. Acknowledgements

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.

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.

8.1. Contributors

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.

9. IANA Considerations

This memo includes no request to IANA.

10. Operational Considerations

TODO: Need to include various operational considerations here. Proposed sections include timestamp accuracy and which attributes attributes designate an endpoint.

11. Privacy Considerations

TODO: Need to include various privacy considerations here.

12. Security Considerations

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.

Initial list of security considerations include:

Authentication:

Every component and asset needs to be able to identify itself and verify the identity of other components and assets.

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.

Integrity:

The information exchanged between components needs to be protected from modification. some exchanges between assets and components will also have this requirement.

Restricted Access:

Access to the information collected, evaluated, reported, and stored should only be viewable/consumable to authenticated and authorized entities.

The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF-MAP Metadata for Network Security [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.

13. References

13.1. Normative References

13.2. Informative References

Appendix A. Change Log

A.1. Changes in Revision 01

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".

Removed Session, because an endpoint's network activity is not SACM's initial focus

Removed Authorization, for the same reason

Added many-to-many relationship between Hardware Component and Endpoint, for clarity

Added many-to-many relationship between Software Component and Endpoint, for clarity

Added "contains" relationship between Network Interface and Network Interface

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.

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

Made identity-to-account a many-to-one relationship.

A.2. Changes in Revision 02

Added Section 6.1, Identifying Attributes.

Split the figure into Figure 10 and Figure 11.

Added Figure 12, proposing a triple-store model.

Some editorial cleanup

A.3. Changes in Revision 03

Moved Appendix A.1, Appendix A.2, and Appendix B into the Appendix. Added a reference to it in Section 1

Added the Section 4 section. Provided notes for the type of information we need to add in this section.

Added the Section 5 section. Moved sections on Endpoint, Hardware Component, Software Component, Hardware Instance, and Software Instance there. Provided notes for the type of information we need to add in this section.

Removed the Provenance of Information Section. SACM is not going to solve provenance rather give organizations enough information to figure it out.

Updated references to the Endpoint Security Posture Assessment: Enterprise Use Cases document to reflect that it was published as an RFC.

Fixed the formatting of a few figures.

Included references to [RFC3580] where RADIUS is mentioned.

A.4. Changes in Revision 04

Integrated the IPFIX [RFC7012] syntax into Section 4.

Converted many of the existing SACM Information Elements to the IPFIX syntax.

Included existing IPFIX Information Elements and datatypes that could likely be reused for SACM in Section 6 and Section 4 respectively.

Removed the sections related to reports as described in https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/30.

Cleaned up other text throughout the document.

A.5. Changes in Revision 05

Merged proposed changes from the I-D IM into the WG IM (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/41).

Fixed some formatting warnings.

Removed a duplicate IE and added a few IE datatypes that were missing.

Appendix B. Mapping to SACM Use Cases

TODO: revise

(wandw)This information model directly corresponds to all four use cases defined in the SACM Use Cases draft [RFC7632]. It uses these use cases in coordination to achieve a small set of well-defined tasks.

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 [I-D.ietf-sacm-requirements].

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.

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)

Appendix C. Security Automation with TNC IF-MAP

C.1. What is Trusted Network Connect?

Trusted Network Connect (TNC) is a vendor-neutral open architecture [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 [TNC-IF-M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-IF-T-TLS] were used as the base for the IETF NEA RFCs [RFC5792][RFC5793][RFC7171][RFC6876].

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) [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.

C.2. What is TNC IF-MAP?

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.

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.

C.3. What is the TNC Information Model?

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 [TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of identifiers and data types.

Each IF-MAP client may interact with the IF-MAP graph data store through three fundamental types of operation requests:

• Publish, which may create, modify, or delete metadata associated with one or more identifiers and/or links in the graph
• Search, which retrieves a selected sub-graph according to a set of search criteria
• 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

The reader is invited to review the existing IF-MAP specification [TNC-IF-MAP-SOAP-Binding] for more details on the above graph data store operation requests and their associated arguments.

The current IF-MAP specification provides a SOAP [W3C.REC-soap12-part1-20070427] binding for the above operations, as well as associated SOAP operations for managing sessions, error handling, etc.

Appendix D. Text for Possible Inclusion in the Terminology Draft

D.1. Terms and Definitions

This section describes terms that have been defined by other RFCs and Internet Drafts, as well as new terms introduced in this document.

D.1.1. Pre-defined and Modified Terms

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 [I-D.ietf-sacm-terminology] are not repeated here unless the original meaning has been changed in this document.

Asset

For this Information Model it is necessary to change the scope of the definition of asset from the one provided in [I-D.ietf-sacm-terminology]. Originally defined in [RFC4949] and referenced in [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.

In [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.

D.1.2. New Terms

IT Asset

Originally defined in [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."

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 [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 [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.

Appendix E. Text for Possible Inclusion in the Architecture or Use Cases

E.1. Introduction

The posture of an endpoint is the status of the endpoint with respect to the security policies and risk models of the organization.

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.

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.

E.2. Core Principles

This information model is built on the following core principles:

• Collection and Evaluation are separate tasks.
• 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.
• 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.
• Policies are reflected in guidance for collection, evaluation, and reporting.
• 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.
• 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.
• 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.

E.3. Architecture Assumptions

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:

• 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.
• 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.
• 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.
• 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.

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.

In the most trivial example, illustrated in Figure 13, Consumers either request information from, or are notified by, Producers.

+----------+     Request     +----------+
|          <-----------------+          |
| Producer |                 | Consumer |
|          +----------------->          |
+----------+    Response     +----------+
                                         
+----------+                 +----------+
|          |     Notify      |          |
| Producer +-----------------> Consumer |
|          |                 |          |
+----------+                 +----------+

+----------+                +----------+
|          |                |          |
| Producer |                | Consumer |
|          |                |          |
+-----+----+                +----^-----+
      |                          |
Write |     +------------+       | Query
      |     |            |       |
      +-----> Repository +-------+
            |            |
            +------------+

                            +-------------+
                            |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  |
                                      |             |
                                      +-------------+
        

      asset
       +-it-asset
       | +-circuit
       | +-computing-device
       | +-database
       | +-network
       | +-service
       | +-software
       | +-system
       | +-website
       +-data 
       +-organization
       +-person
    

                                          +------------+
                    +-----------------+   | Variables  |
                    | Common          <---+            |
           +-------->                 |   +------------+
           |        |                 |   +------------+
           |        |                 <---+ Directives |
           |        +--------^----^---+   |            |
           |                 |    |       +--------+---+
           |                 |    +-----+          |
           |                 |          |          |
           |        +--------+--------+ |          |
           |        | System          | |          |
           |        | Characteristics | |          |
    +------+------+ |                 | | +--------v---+
    | Definitions | |                 | | | Results    |
    |             | +--------^--------+ +-+            |
    |             |          |            |            |
    |             |          +------------+            |
    +------^------+                       +-------+----+
           |                                      |
           +--------------------------------------+
    

   +------------------+                 +-----------------+
   | Id:          1   |   parent-of     |Id:          2   |
   | Given name:  Sue | --------------> |Given name:  Ann |
   | Family name: Wong|                 |Family name: Wong|
   +------------------+                 +-----------------+

         A VERTEX          AN EDGE           A VERTEX