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

Figure 6: 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

5.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 (This is not simple, as Section 1.1.1 explains.)
• 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".

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

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

5.1.3. Certificate

5.1.3.1. Range of values

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

5.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?

5.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?

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

5.1.3.5. Accuracy

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

5.1.3.6. Data model requirements

All SACM data models MUST support this entire subsection.

5.1.4. Public Key

TODO

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

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

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

5.1.8. Security Considerations

Effects of misidentification

Things that can cause misidentification

How minimize misidentification

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

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

5.4. Endpoint Attribute Assertion

TODO: Integrate into the Section 3 as appropriate.

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

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

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

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

5.4.5. Event

An event is represented as a Posture Attribute Assertion whose time interval has length zero.

Some potential kinds of events are:

• A structured syslog message [RFC5424]
• IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
• A NetFlow message [RFC3954]

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

5.5. Attribute-Value Pair

TODO: Integrate into the Section 3 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 4:

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

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

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

5.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 4 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.

5.7. SACM Component

Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them to the architecture document?

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

5.7.1. External Attribute Collector

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

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

[cek-to jmf's comment, that is what they are examples of; is a text change needed?]

Examples:

• A RADIUS server [RFC3580] whereby an endpoint has logged onto the network
• A network profiling system, which discovers and classifies network nodes
• A Network Intrusion Detection System (NIDS) sensor
• A vulnerability scanner
• A hypervisor that peeks into the endpoint, the endpoint being a virtual machine
• A management system that configures and installs software on the endpoint

5.7.2. Evaluator

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

[cek-I like the change. I think it *does* require a change in the terminology doc, though.]

Example: a NEA posture validator [RFC5209]

[jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?]

[cek-Why isn't a NEA posture validator an example?]

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

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

5.9.1. Internal Collection Guidance

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

5.9.2. External Collection Guidance

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

5.9.3. Evaluation Guidance

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

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

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

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

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

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

5.11. User

5.11.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?

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

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

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

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

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

5.17. 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:
    

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

5.19. softwareIdentifier

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

5.20. softwareTitle

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

5.21. softwareCreator

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

5.22. simpleVersion

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

5.23. rpmVersion

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

5.24. ciscoTrainVersion

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

5.25. 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,
                simpleVersion,
                rpmVersion,
                ciscoTrainVersion,
                ...
               )     
      

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

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

5.28. globallyUniqueIdentifier

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

5.29. dataOrigin

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

5.30. dataSource

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

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

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

5.33. publicationTimestamp

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

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

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

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

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

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

5.39. sourceIPv4PrefixLength

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

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

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

5.42. sourceIPv6PrefixLength

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

5.43. sourceIPv4Prefix

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

5.44. destinationIPv4Prefix

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

5.45. sourceMacAddress

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

5.46. ipVersion

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

5.47. interfaceName

elementId: TBD
name: interfaceName	
dataType: string
dataTypeSemantics: default
status: current
description: A short name uniquely describing an interface, eg "Eth1/0".

5.48. interfaceDescription

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

5.49. applicationDescription

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

5.50. applicationId

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

5.51. applicationName

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

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

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

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

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

5.56. collectorIPv4Address

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

5.57. collectorIPv6Address

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

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

5.59. basicList

elementId: TBD
name: basicList	
dataType: basicList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a basicList abstract
             data type.  For example, a list of port numbers, a list of
             interface indexes, etc.

5.60. subTemplateList

elementId: TBD
name: subTemplateList	
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a subTemplateList
             abstract data type.

5.61. subTemplateMultiList

elementId: TBD
name: subTemplateMultiList	
dataType: subTemplateMultiList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a
             subTemplateMultiList abstract data type.

5.62. informationElementId

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

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

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

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

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

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

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

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

5.70. userName

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

5.71. applicationCategoryName

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

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

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

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

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

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

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

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

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

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

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

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

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

5.84. mibSubIdentifier

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

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

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

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

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

5.89. mibObjectName

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

5.90. mibObjectDescription

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

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

5.92. mibModuleName

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

6. 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 4 illustrates those elements along with their major communication paths.

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

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

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

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

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

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

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

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

8. IANA Considerations

This memo includes no request to IANA.

9. Operational Considerations

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

10. Privacy Considerations

TODO: Need to include various privacy considerations here.

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

12. References

12.1. Normative References

12.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 5.1, Identifying Attributes.

Split the figure into Figure 4 and Figure 5.

Added Figure 6, 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 3 section. Provided notes for the type of information we need to add in this section.

Added the Section 4 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 3.

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 5 and Section 3 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.

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