One document matched: draft-ietf-sacm-information-model-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml2rfc.ietf.org/authoring/rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3416 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3416.xml">
<!ENTITY RFC3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY RFC3954 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3954.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4287 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml">
<!ENTITY RFC5201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6313.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7012.xml">
<!ENTITY RFC7013 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7013.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC7632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-terminology-05.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-requirements-01.xml">
<!ENTITY I-D.ietf-sacm-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-architecture-00.xml">
<!ENTITY I-D.salowey-sacm-xmpp-grid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-salowey-sacm-xmpp-grid-00.xml">
<!ENTITY W3C.REC-soap12-part1-20070427 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-soap12-part1-20070427.xml">
<!ENTITY W3C.REC-rdf11-concepts-20140225 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.REC-rdf11-concepts-20140225.xml">
]>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.ietf.org/authoring/rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of <xref target="TNC-Architecture"/> -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sacm-information-model-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SACM Information Model">SACM Information Model</title>
<author fullname="David Waltermire" initials="D." surname="Waltermire" role="editor">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<code>20877</code>
<country>USA</country>
</postal>
<phone/>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<author fullname="Kim Watson" initials="K.K." surname="Watson">
<organization abbrev="DHS">United States Department of Homeland Security</organization>
<address>
<postal>
<street>DHS/CS&C/FNR</street>
<street>245 Murray Ln. SW, Bldg 410</street>
<street>MS0613</street>
<city>Washington</city>
<region>DC</region>
<code>20528</code>
<country>USA</country>
</postal>
<email>kimberly.watson@hq.dhs.gov</email>
</address>
</author>
<author fullname="Clifford Kahn" initials="C." surname="Kahn">
<organization>Pulse Secure, LLC</organization>
<address>
<postal>
<street>2700 Zanker Road, Suite 200</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>cliffordk@pulsesecure.net</email>
</address>
</author>
<author fullname="Lisa Lorenzin" initials="L." surname="Lorenzin">
<organization>Pulse Secure, LLC</organization>
<address>
<postal>
<street>2700 Zanker Road, Suite 200</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>llorenzin@pulsesecure.net</email>
</address>
</author>
<author fullname="Michael Cokus"
initials="M.C." surname="Cokus">
<organization>The MITRE
Corporation</organization>
<address>
<postal>
<street>903 Enterprise Parkway, Suite 200</street>
<!-- Reorder these if your country does things differently -->
<city>Hampton</city>
<region>VA</region>
<code>23666</code>
<country>USA</country>
</postal>
<phone/>
<email>msc@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Daniel Haynes" initials="D.H." surname="Haynes">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>202 Burlington Road</street>
<!-- Reorder these if your country does things differently -->
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<phone/>
<email>dhaynes@mitre.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016"/>
<area>General</area>
<workgroup>SACM</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>todo</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document defines the information model
for SACM.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="INTRO">
<t>This document defines an information model for endpoint
posture assessment. The scope of the information model
is to describe the mandatory-to-implement information
needs required to realize the assessment of an endpoint
in a scalable and extensible way. The information model
aims to inform the development of specific data models
that support the endpoint posture assessment process.
The terms "information model" and "data model" align with
the definitions in <xref target="RFC3444"/>.</t>
<t>The five primary activities to support this information model are:<list
style="numbers">
<t>Endpoint Identification</t>
<t>Endpoint Characterization</t>
<t>Endpoint Attribute Expression</t>
<t>Guidance Expression</t>
<t>Endpoint Evaluation Result Expression</t>
</list></t>
<t>These activities are aimed at the level of the technology that performs operations to
support the collection, communication, and evaluation of endpoint information.</t>
<t>Review of the SACM Use Case <xref target="RFC7632"/> usage scenarios
show a common set of business process areas that are critical to understanding
endpoint posture such that appropriate policies, security capabilities, and
decisions can be developed and implemented.</t>
<t>For this information model we have chosen to focus on the following business process
areas:<list style="symbols">
<t>Endpoint Management</t>
<t>Software Inventory Management</t>
<t>Hardware Inventory Management</t>
<t>Configuration Management</t>
<t>Vulnerability Management</t>
</list></t>
<t>These management process areas are a way to connect the SACM use cases and building
blocks <xref target="RFC7632"/> to the organizational needs such
that the definition of information requirements has a clearly understood
context. For more information, see <xref
target="mapping-to-sacm-use-cases"/> which maps the SACM information model to the SACM use cases.</t>
<t>The SACM information model offers a loose coupling between providers and
consumers of security information. A provider can relay what it observes or infers,
without knowing which consumers will use the information, or how they will use it. A
consumer need not know exactly which provider generated a piece of information, or
by what method.</t>
<t>At the same time, a consumer *can* know these things, if necessary.</t>
<t>As things evolve, a provider can relay supplemental information. Some consumers will
understand and benefit from the supplemental information; other consumers will not
understand and will disregard it.</t>
<section title="Problem Statement">
<!-- TODO: May need additional revision -->
<t>SACM requires a large and broad set of mission and business processes, and to make
the most effective use of technology, the same data must support multiple
processes. The activities and processes described within this document tend to build off
of each other to enable more complex characterization and assessment. In an effort
to create an information model that serves a common set of management processes
represented by the usage scenarios in the SACM Use Cases <xref target="RFC7632"/>, we have narrowed
down the scope of this model to focus on the
information needs required for endpoint
identification, endpoint characterization, endpoint
attribute expression, guidance expression, and
endpoint evaluation result expression.</t>
<t>Administrators can't get technology from disparate
sources to work together; they need information to make decisions, but the information
is not available. Everyone is collecting the same data, but storing it as different
information. Administrators therefore need to collect data and craft their own information,
which may not be accurate or interoperable because it's customized by each administrator, not
shared. A standard information model enables
flexibility in collecting, storing, and exchanging
information despite platform differences.</t>
<t>A way is needed to exchange
information that (a) has breadth, meaning the pieces
of the notation are useful for a
variety of endpoint information, and (b) has longevity, meaning that the
pieces of the notation will stay useful over time.</t>
<t>When creating standards, it's not sufficient to go
from the requirements directly to the protocol;
the standards must eliminate ambiguity in the information transported. This is
the purpose of information models generally. The SACM problem space is about integrating
many information sources. This information model addresses the need to integrate security
components, support multiple data models, and provide interoperability in a way that is
platform agnostic, scales, and works over time.</t>
<section anchor="section-referring-to-an-endpoint" title="Referring to an Endpoint">
<t>How to refer to an endpoint is problematic. Ideally, an endpoint would have a
unique identifier. These identifiers would have a one-to-one relationship with
endpoints. Every observation of an endpoint, or inference about an endpoint
would be labeled with its identifier.</t>
<t>However:
<list style="symbols">
<t>An external posture attribute collector typically cannot observe the unique
identifier directly. An external posture attribute collector should be able to
report exactly what it has observed, unembellished. It should not have to
*infer* which endpoint it has observed; that inference should be left to
other SACM components. So, SACM cannot require that every observation include
the unique endpoint identifier.</t>
<t>Internal posture attribute collectors are not present on all endpoints.
They are not present on "dumb" devices such as Internet of Things (IoT) devices,
or on Bring Your Own Device (BYOD) devices. In these cases, *no* observers have
direct access to the unique endpoint identifier.</t>
<t>An endpoint identifier is generally subject to cloning, when a system image
is cloned. Then, it is no longer unique.</t>
<t>Suppose the endpoint identifier is highly
clone resistant -- such as a unique certificate within a hardware cryptographic
module. Even so, it is possible to replace all of the software -- for example,
changing a Windows machine to a Linux machine. Is it still the same endpoint?
For SACM purposes, it isn't really the same endpoint. </t>
</list>
</t>
<t>So SACM components must be able to put disparate observations together and form a
picture of an endpoint -- somewhat like a detective. The SACM information model must
facilitate this.</t>
</section>
<section title="Dealing with Uncertainty">
<t>With many information models, the information is considered certain.
In SACM, information is not certain.
Attackers may develop countermeasures to fool some SACM components.
Attackers may compromise some SACM components.</t>
<t>So the model must let SACM components and humans reason with
uncertainty. There are no facts, only assertions. </t>
<t>SACM components must be able to cross check
observations and inferences against each other.
They should be able to give weight if an
observation or inference is corroborated by more
than one method. Although SACM will probably not
prescribe *how* to do this cross checking, SACM
should provide the components with information
that can be used to determine provenance.</t>
<t>SACM components must be able to consider the
reputation of the observer or inferrer. That
reputation should account for the method of
observing or inferring, the implementer of the
SACM component that made the observation or
inference, and the compliance status of the
endpoint on which the observation or inference
was made. For example, if some observers are
found to be vulnerable to a Day 1 exploit,
observations from those observers deserve less
weight. The details of reputation technology may
be out of scope for SACM. However, again, SACM
should provide components with information that
enables them to make this determination.</t>
</section>
</section>
</section>
<section title="Conventions used in this document">
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Information Model Framework" anchor="information-model-framework">
<t>The SACM information model is structured around a core
framework that can be easily extended to support the
modeling needs for endpoint posture assessment. This
section describes the key concepts that make up this
framework as well as the IP Information Flow Export
(IPFIX) Information Model <xref target="RFC7012"/>
syntax used to model the different information model
concepts.</t>
<section title="Attributes" anchor="attributes">
<t>Attributes are used to model specific endpoint
information. At a minimum, an attribute must have a name
and a value. Additional information about attributes can
be modeled using metadata as described in <xref
target="metadata"/>.</t>
<section title="Syntax">
<t>Attributes must be defined using the IPFIX Information
Element Specification Template as described in Section
2.1 of <xref target="RFC7012"/>. The following is a
modified version of the template for Information
Elements provided in Section 9.1 of <xref
target="RFC7013"/>.</t>
<figure
anchor="Attribute-Information-Element-Specification-Template">
<artwork>
elementId: Element identifier goes here if known, or
"TBD" if it will be assigned by IANA and
filled in at publication time.; obligatory
name: Name goes here.; obligatory
dataType: Data type goes here; obligatory
status: Status goes here; obligatory
description: Description goes here.; obligatory
For Information Elements that
represent flags, please include a
table that lists each flag value
(hexadecimal) and description.
The following is a template for that
table.
+-------+----------------------------------+
| Value | Description |
+-------+----------------------------------+
| | |
+-------+----------------------------------+
dataTypeSemantics: Data type semantics, if any, go here; optional
units: Units, if any, go here; optional
range: Range, if not implied by the data type, goes
here; optional
references: References to other RFCs or documents outside
the IETF, in which additional information is
given, or which are referenced by the
description, go here; optional
</artwork>
</figure>
</section>
</section>
<section title="Objects"><!-- TODO: Should we call this
container, construct, class, object, list? I went with
object for now because I don't believe it implies a
hierarchy like "containers" and because I am going to
use "constructs" to describe IPFIX syntax constructs
like basicList, subTemplateList, etc. -->
<t>Objects are the mechanism by which attributes
(<xref target="attributes"/>) and/or other objects
can be logically grouped together to create more
complex models. Additional information about objects
can be modeled using metadata as described in
<xref target="metadata"/>.</t>
<section title="Syntax">
<t>Objects are complex Information Elements that can
be created using one of the following IPFIX constructs
that are defined in Section 3.1 of <xref target="RFC7012"/>.
<list style="symbols">
<t>basicList: a list of zero or more instances of
any Information Element</t>
<t>subTemplateList: a list of zero or more
instances of a single, specific Template</t>
<t>subTemplateMultiList: a list of zero or more
instances of any Template</t>
</list>
The following is a modified version of the template
for Information Elements provided in Section 9.1 of
<xref target="RFC7013"/> that can be used to model
objects.
<figure
anchor="Object-Information-Element-Specification-Template">
<artwork>
elementId: Element identifier goes here if known, or
"TBD" if it will be assigned by IANA and
filled in at publication time.; obligatory
name: Name goes here.; obligatory
dataType: Data type goes here; obligatory
status: Status goes here; obligatory
description: Description goes here.; obligatory
Please include a high-level model diagram that uses
the following format which is a simplified version
of a high-level diagram format used in [RFC6313].
<IE-Name> = (<IE-DataType>, <IE-DataTypeSemantic>,
<IE-1>,
<IE-2>,
<IE-3>,
...
)
dataTypeSemantics: Data type semantics, if any, go here; optional
units: Units, if any, go here; optional
range: Range, if not implied by the data type, goes
here; optional
references: References to other RFCs or documents outside
the IETF, in which additional information is
given, or which are referenced by the
description, go here; optional
</artwork>
</figure>
</t>
</section>
</section>
<section title="Metadata" anchor="metadata">
<t>Metadata allows components to annotate objects and
attributes with additional information that will allow
other components to make a determination about the provenance
of the objects and attributes during exchanges and
evaluations.
A proposal outlining various options for
representing metadata attributes/objects in the IPFIX syntax is being
discussed on the mailing list. TODO: See IM issue #39 at
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information.
</t>
</section>
<section title="Relationships">
<t>TODO: Define what a relationship is. At the end of the day, we want to be able to describe the
relationships between assets, endpoints, and attributes. QUESTION: Are relationships just metadata?
Lisa's notes have some information on relationships: https://mailarchive.ietf.org/arch/msg/sacm/kWxlnboHAXD87cned9WavwPZy5w.
We also want to consider the relationships proposed by Nancy and Henk in
https://www.ietf.org/proceedings/94/slides/slides-94-sacm-7.pdf.
Nancy and Henk expect to provide additional information related to their Information Model work
that can be merged into this document at some point.
The information is expected to be ready in advance of
IETF 95. Please see issue #39 at
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information.</t>
</section>
<section title="Designation">
<t>TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, the
Endpoint ID Design Team proposes that "endpoint identity" be changed to "endpoint designation". Designation
attributes can be used to correlate endpoints, information about endpoints, events, etc. NOTE: Designation
attributes are just those that are mandatory-to-implement. In practice, organizations may need to select additional
attributes beyond the mandatory-to-implement attributes to successfully identify an endpoint on their network. Operational
and privacy concerns will be covered in Operational Considerations and Privacy Considerations sections respectively.
A proposal outlining various options for
representing designation attributes/objects in the IPFIX syntax is being
discussed on the mailing list. See IM issue #39 at
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information.
</t>
</section>
<section title="Privacy">
<t>TODO: In the IETF, there are privacy concerns with respect to endpoint identity and monitoring. As a result, it was proposed that a
privacy property be included to denote when a information element represents a privacy concern.
A proposal outlining various options for
representing privacy attributes/objects in the IPFIX syntax is being
discussed on the mailing list. See IM issue #39 at
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/39
for more information.
</t>
</section>
<section title="Type Space" anchor="type-space">
<t>This section describes the abstract data types that
can be used for the specification of the SACM
Information Elements in <xref target="information-model-elements"/>.
<xref target="abstract-data-types"/> describes the set
of abstract data types. This section used Section 3
of <xref target="RFC7012"/> as a starting point and was modified
to address the needs of SACM.</t>
<section title="Abstract Data Types" anchor="abstract-data-types">
<t>This section describes the set of valid abstract data
types of the SACM information model, independent of how
they are implemented in a data model. Note that
further abstract data types may be specified by future
extensions of the SACM information model.</t>
<section title="unsigned8">
<t>The type "unsigned8" represents a non-negative
integer value in the range of 0 to 255.</t>
</section>
<section title="unsigned16">
<t>The type "unsigned16" represents a non-negative
integer value in the range of 0 to 65535.</t>
</section>
<section title="unsigned32">
<t>The type "unsigned32" represents a non-negative
integer value in the range of 0 to 4294967295.</t>
</section>
<section title="unsigned64">
<t>The type "unsigned64" represents a non-negative
integer value in the range of 0 to
18446744073709551615.</t>
</section>
<section title="signed8">
<t>The type "signed8" represents an integer value in
the range of -128 to 127.</t>
</section>
<section title="signed16">
<t>The type "signed16" represents an integer value
in the range of -32768 to 32767.</t>
</section>
<section title="signed32">
<t>The type "signed32" represents an integer value
in the range of -2147483648 to 2147483647.</t>
</section>
<section title="signed64">
<t>The type "signed64" represents an integer value
in the range of -9223372036854775808 to
9223372036854775807.</t>
</section>
<section title="float32">
<t>The type "float32" corresponds to an IEEE
single-precision 32-bit floating point type as
defined in [IEEE.754.1985].</t>
</section>
<section title="float64">
<t>The type "float64" corresponds to an IEEE
double-precision 64-bit floating point type as
defined in [IEEE.754.1985].</t>
</section>
<section title="boolean">
<t>The type "boolean" represents a binary value.
The only allowed values are "true" and "false".</t>
</section>
<section title="macAddress">
<t>The type "macAddress" represents a MAC-48 address
as defined in [IEEE.802-3.2012].</t>
</section>
<section title="string">
<t>The type "string" represents a finite-length
string of valid characters from the Unicode coded
character set [ISO.10646]. Unicode incorporates
ASCII [RFC20] and the characters of many other
international character sets.</t>
</section>
<section title="dateTimeSeconds">
<t>The type "dateTimeSeconds" represents a time
value expressed with second-level precision.</t>
</section>
<section title="dateTimeMilliseconds">
<t>The type "dateTimeMilliseconds" represents a time
value expressed with millisecond-level precision.</t>
</section>
<section title="dateTimeMicroseconds">
<t>The type "dateTimeMicroseconds" represents a time
value expressed with microsecond-level precision.</t>
</section>
<section title="dateTimeNanoseconds">
<t>The type "dateTimeNanoseconds" represents a time
value expressed with nanosecond-level precision.</t>
</section>
<section title="ipv4Address">
<t>The type "ipv4Address" represents an IPv4 address as
defined in <xref target="RFC0791"/>.</t>
</section>
<section title="ipv6Address">
<t>The type "ipv6Address" represents an IPv6 address as
defined in <xref target="RFC3587"/>.</t>
</section>
<section title="basicList">
<t>The type "basicList" represents a list of zero or
more instances of any Information Element as defined
in <xref target="RFC6313"/>.</t>
</section>
<section title="subTemplateList">
<t>The type "subTemplateList" represents a list of zero
or more instances of a structured data type, where
the data type of each list element is the same and
corresponds with a single Template Record as defined
in <xref target="RFC6313"/>.</t>
</section>
<section title="subTemplateMultiList">
<t>The type "subTemplateMultiList" represents a list
of zero or more instances of a structured data type,
where the data type of each list element can be
different and corresponds with different Template
definitions as defined in <xref target="RFC6313"/>.</t>
</section>
</section>
<section title="Data Type Semantics"
anchor="data-type-semantics">
<t>This section describes the set of valid data type
semantics of the IPFIX information model.</t>
<t>Further data type semantics may be specified by future
updates to this document. Changes to the associated
"IPFIX Information Element Semantics" subregistry
[IANA-IPFIX] require a Standards Action [RFC5226].</t>
</section>
<section title="quantity" anchor="quantity">
<t>"quantity" is a numeric (integral or floating point)
value representing a measured value pertaining to the
record. This is distinguished from counters that
represent an ongoing measured value whose "odometer"
reading is captured as part of a given record. This
is the default semantic type of all numeric data types.</t>
</section>
<section title="totalCounter" anchor="titleCounter">
<t>"totalCounter" is an integral value reporting the
value of a counter. Counters are unsigned and wrap
back to zero after reaching the limit of the type.
For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of
2**64 - 1. At this point, the next increment will
wrap its value to zero and continue counting from
zero. The semantics of a total counter is similar to
the semantics of counters used in the Simple Network
Management Protocol (SNMP), such as Counter32 as
defined in [RFC2578]. The only difference between
total counters and counters used in SNMP is that the
total counters have an initial value of 0. A total
counter counts independently of the export of its
value.</t>
</section>
<section title="deltaCounter" anchor="deltaCounter">
<t>"deltaCounter" is an integral value reporting the value
of a counter. Counters are unsigned and wrap back to
zero after reaching the limit of the type. For example,
an unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1. At
this point, the next increment will wrap its value to
zero and continue counting from zero. The semantics of
a delta counter is similar to the semantics of counters
used in SNMP, such as Counter32 as defined in [RFC2578].
The only difference between delta counters and counters
used in SNMP is that the delta counters have an initial
value of 0. A delta counter is reset to 0 each time
it is exported and/or expires without export.</t>
</section>
<section title="identifier" anchor="identifier">
<t>"identifier" is an integral value that serves as an
identifier. Specifically, mathematical operations on two
identifiers (aside from the equality operation) are
meaningless. Identifiers MUST be one of the signed or
unsigned data types.</t>
</section>
<section title="flags" anchor="flags">
<t>"flags" is an integral value that represents a set
of bit fields. Logical operations are appropriate on
such values, but other mathematical operations are
not. Flags MUST always be of an unsigned data type.</t>
</section>
<section title="list" anchor="list">
<t>A list represents an arbitrary-length sequence of
zero or more Information Elements, either composed
of regular Information Elements or composed of data
conforming to a Template Record. See <xref
target="RFC6313"/>.</t>
</section>
</section>
</section>
<section title="Information Model Assets" anchor="information-model-assets">
<t>TODO: Explain the different SACM assets. Right now, we have distilled this down to an endpoint, hardware,
software, and identity. Previously, this diagram also included account, location, address, and network
inteface, but, these things are not assets and can either be consolidated into one of the existing asset
types (e.g. network interface => hardware, account => identity, etc.) or are just metadata about the
assets (e.g. location => endpoint). We should also explain the types of assets below rather than just
referencing out to the Terminology draft.
</t>
<t>TODO: The figure below needs to be updated to show the relationships between the different types of assets.</t>
<figure title="Model of an Endpoint"
anchor="figure-model-of-an-endpoint">
<artwork>
<![CDATA[
+---------+*______in>_______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !|
+---------+ |Software |in> |! !|
1| |Component|____|! !|
| +---------+* *|! !|
| 1| |! !|
| *| | | +----------+
| +---------+ |End- |*_____*| Identity |
*| |Software |in> |point| acts +----------+
+---------+ |Instance |____| | for>
|Hardware | +---------+* 1|! !|
|Instance |__________________|! !|
+---------+* in> 1|! !|
|! !|
|! !|____
|! !|0..1|
+-----+ |
|* |
|_______|
in>
]]>
</artwork>
</figure>
<section title="Asset">
<t> TODO: Define Asset here in the context of the information model.</t>
<t><xref target="I-D.ietf-sacm-terminology"/>
defines an asset as:
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".
In the scope of SACM, an asset can be composed of other
assets. Examples of Assets include: Endpoints, Software,
Guidance, or X.509 public key certificates. An asset is
not necessarily owned by an organization.</t>
</section>
<section title="Endpoint">
<t>TODO: Define an Endpoint asset. Explain how it is made up of HW components,
SW components, asset identity, etc.</t>
<t>An endpoint is the hollow center of the model. An endpoint is an abstract ideal.
Any endpoint attribute assertion that mentions an endpoint mentions it by specifying
identifying attributes. Even if there is one preferred endpoint identity, that is
modeled as an identity. We do not anticipate any AVP whose attribute type is "endpoint".</t>
</section>
<section title="Hardware Component">
<t>TODO: Define a Hardware Component asset. Explain how it is things like motherboards,
network cards, etc.</t>
<t>Hardware components may also be assets and/or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.</t>
<t>A data model MAY designate a hardware component by its manufacturer and a part number.</t>
<section title="Hardware Instance">
<t>A hardware instance is just an instance of a particular
component.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A hardware instance is an "instance of" a hardware component.</t>
<t>A hardware instance is "in" an endpoint.</t>
</list></t>
<t>Hardware instances may need to be modeled because (a) an endpoint may have multiple instances of a hardware component, (b) a hardware instance may be compromised, whereas other instances may remain intact.</t>
<t>A data model MAY designate a hardware instance
by its component and a unique serial number.</t>
</section>
</section>
<section title="Software Component">
<t>TODO: Define a Software Component asset. Explain how it is the software installed on
the endpoint including the operating system.</t>
<t>An endpoint contains and runs software components.</t>
<t>Relationship:
<list style="symbols">
<t>If an endpoint has an instance of a software component, we say that the software component is "in" the endpoint. This is a shorthand.</t>
</list>
</t>
<t>Some software components are assets.
"Asset" is defined in RFC4949 <xref target="RFC4949"/> as "a system
resource that is (a) required to be protected by an information
system's security policy, (b) intended to be protected by a
countermeasure, or (c) required for a system's mission."</t>
<t>An examination of software needs to
consider both (a) software assets and (b) software that may
do harm. A posture attribute collector may not know (a) from (b). It is useful
to define Software Component as the union of (a) and (b).</t>
<t>Examples of Software Assets:
<list style="symbols">
<t>An application</t>
<t>A patch</t>
<t>The operating system kernel</t>
<t>A boot loader</t>
<t>Firmware that controls a disk drive</t>
<t>A piece of JavaScript found in a web page the user visits</t>
</list>
</t>
<t>Examples of harmful software components:
<list style="symbols">
<t>A malicious entertainment app</t>
<t>A malicious executable</t>
<t>A web page that contains malicious JavaScript</t>
<t>A business application that shipped with a virus</t>
</list>
</t>
<t>Software components SHOULD be disjoint from each other. In other words,
software componennts SHOULD be so defined that
a given byte of software on an endpoint
belongs to only one software component.</t>
<t>Different versions of the same piece of software MUST be modeled as
different components. Software versioning is not built into the
information model.</t>
<t>Each separately installable piece of software SHOULD be modeled as a
component. Sometimes it may be better to divide more finely:
what an installer installs MAY be modeled as several components.</t>
<t>A data model MAY identify a software component by parts of an ISO SWID tag.</t>
<section title="Software Instance">
<t>Each copy of a piece of software is called a software instance.
The configuration of a software instance is regarded
as part of the software instance.
Configuration can strongly affect security posture.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A software instance is an "instance of" a software component.</t>
<t>A software instance is "in" an endpoint.</t>
</list></t>
<t>A data model MAY use ISO SWID tags to describe software instances.</t>
</section>
</section>
<section title="Asset Identity">
<t>TODO: Define an Asset Identity asset. Explain how it is things like user, device, etc.
where certificates, usernames, etc. come into place since they are not really hardware
or software. NOTE: Make sure it is clear that this is not identity in the sense
of what we have been saying endpoint identity (now designation).</t>
</section>
<section title="Relationships">
<t>TODO: Define the relationships between assets (endpoints, hardware, software, etc.).
These will depicted in the overview diagram.</t>
</section>
</section>
<section title="Information Model Elements" anchor="information-model-elements">
<t>TODO: Define specific containers, attributes, and metadata. We may want to consider
adding small diagrams showing the relationships between each (see Lisa's notes:
https://mailarchive.ietf.org/arch/msg/sacm/kWxlnboHAXD87cned9WavwPZy5w). This may be
too much work, but, not sure yet.</t>
<t>The SACM Information Model contains several elements
of the architecture, including:<list style="symbols">
<t>SACM Components, which may be Collectors, Evaluators, etc.
Collectors may be internal (performed within the
endpoint itself) or external (performed outside of the endpoint,
such as by a hypervisor or remote sensor)</t>
<t>Guidance, which tells SACM components what to do</t>
<t>Posture, in the form of posture attributes and evaluation results</t>
<t>Additional information about the endpoint, such as a representation
of a software component, endpoint identity, user identity, address,
location, and authorization constraining the endpoint</t>
</list></t>
<t>The SACM Information Model does not (in this draft) specify
how long information is retained. Historical information is
modeled the same way as current information. Historical information
may be represented
differently in an implementation, but that difference would be in data models,
not in the information model.
</t>
<t><xref target="figure-model-of-endpoint"/>
introduces the endpoint attributes
and their relationships.</t>
<figure title="Model of an Endpoint"
anchor="figure-model-of-endpoint">
<artwork>
<![CDATA[
+---------+*____in>______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !| +--------+*______________
+---------+ |Software |in>|! !|*____*|Location|_________ <in|
1| |Component|___|! !| in> +--------+* <in *| |
| +---------+* *|! !| +-------+ |
| 1| |! !| |Account| |
| *| | | +----------+ +-------+ |
| +--------+ |End- |*____*| Identity |______|0..1 |
*| |Software|in> |point| acts +----------+* belongs |
+--------+ |Instance|_____| | for> 0..1|^ to> |
|Hardware| +--------+* 1|! !| |acts |
|Instance|________________|! !| *|for |*
+--------+* in> 1|! !|______+---------+ +-------+
|! !|1 <in *|Network |1_______*|Address|
|! !|____ |Interface| <bound +-------+
|! !|0..1| +---------+ to
+-----+ | *| |0..1
|* | |___|
|_______| in>
in>
]]>
</artwork>
</figure>
<t>ISSUE (CEK): we agreed to remove location and account
from the model, did we not? TODO: Remove Network Interface, Location,
Address, and Account from this diagram if we end up removing the
corresponding sections from the information model.</t>
<t><xref target="figure-information-elements"/>
is the core of the information model. It represents
the information elements and their relationships.</t>
<figure title="Information Elements"
anchor="figure-information-elements">
<artwork>
<![CDATA[
+-----+ +---------+
| AVP |____________|Endpoint |
+-----+1..* 1|Attribute|
|Assertion|
+---------+
|* +-------+
| |Summary|
| +-------+
|produced-by *|
|V |
1| |
+--------+ +-----------+ |
| | | SACM |____________________|
|Guidance| | Component |1 <produced-by
+--------+*____________1+-----------+
<produced-by
]]>
</artwork>
</figure>
<t><xref target="figure-information-elements-take-2"/>
is a potential alternative structure for assertions.
It is inspired by triple stores.
See http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.</t>
<figure title="Information Elements, Take 2"
anchor="figure-information-elements-take-2">
<artwork><![CDATA[
+-----+______________+---------+ +---------+
| AVP |1 <subject *|assertion|________________|predicate|
| |______________| |* predicate> 1+---------+
+-----+1 <object *+---------+
1^ |*
|_____________________|
<asserter
]]></artwork>
</figure>
<t>Note: UML 2 is specified by <xref target="UML"/>.</t>
<t>TODO: update text to match new figure:</t>
<t>Need to be clear in the description that ???</t>
<t>For some of
the relationships, will need some language and guidance to
the interfaces and relationships we expect to have happen,
MUSTs and SHOULDs, as well as explaining the extensibility
that other relationships can exist, show examples of how
that can happen. Others that we haven't thought of yet, might
be added by another RFC or in another way</t>
<section anchor="section-identifying-attributes" title="Identifying Attributes">
<t>TODO: Need to rename this section to align with new "designation" term.</t>
<t>Identifying attributes let a consumer identify an endpoint,
for two purposes:<list style="symbols">
<t>To tell whether two endpoint
attribute assertions concern the same endpoint
(This is not simple,
as <xref target="section-referring-to-an-endpoint"/> explains.)</t>
<t>To respond to compliance measurements, for example
by reporting, remediating, and quarantining
(SACM does not specify these responses,
but SACM exists to enable them.)</t>
</list></t>
<t>Out of scope of this section: *classifying* an endpoint
so as to apply appropriate collection guidance to it.
We don't call this "identification".</t>
<section title="How Known">
<t>Each attribute-value pair or triple
MUST be marked with how the provider knows.
There MUST be at least one marking.
The possible markings follow.
<list style="symbol">
<t>"Self" means that the endpoint furnished the information:
it is self-reported. "Self" does not (necessarily) mean that the
provider runs on the the monitored endpoint.
Self-reported information is generally subject to the
Lying Endpoint Problem. (TODO: citation)</t>
<t>"Authority" means that the provider got the information,
directly or indirectly, from an authority that assigned it.
For example, the producer got an IP-MAC association
from a DHCP server
(or was itself the DHCP server).</t>
<t>"Observation" means that the provider got the information
from observations of network traffic.
For example, the producer saw the source address in
an IP packet.</t>
<t>"Verification" means that the provider has verified
the information.
For example:<list style="symbols">
<t>The provider does IP communication with the endpoint
and knows the IP address with which it communicates.</t>
<t>The provider makes an SSH connection to the endpoint
and knows the endpoint's public key by virtue of
authenticating it.</t>
<t>The monitored endpoint is a virtual machine and
the provider knows by peeking into it.</t>
</list></t>
</list></t>
<t>TODO: Explain security considerations and how
consumers are meant to use these markings.</t>
</section>
<section title="Whether to Include">
<t>When publishing an endpoint attribute assertion,
the provider MUST publish at least all common identifying AVPs
that it knows through
verification.
If the provider knows none through verification but it knows at least
one in another way, it MUST publish at least one.
The provider SHOULD publish all common identifying AVPs it knows.
</t>
</section>
<!--
<section title="IP Address">
<section title="Range of Values">
<t>MUST be an IPv4 or IPv6 address,
and optionally a scope string.
MUST NOT be a broadcast, multicast, or loopback address.</t>
<t>An IPv4 address MUST conform to <xref target="RFC0791"/>,
section 3.2.</t>
<t>An IPv6 address MUST conform to <xref target="RFC3587"/>.
SHOULD NOT be a link-local address.</t>
<t>Scope string: an administratively assigned string
denoting the IP routing domain.
Implementations MUST support this.
Administrators may use it to avoid ambiguity,
for example if network address translation (NAT) is in use.</t>
<t>ISSUE (Jim Schaad): Scope strings are interesting.
However does this imply a potential need to create a new DHCP item so that
it can be sent out to a device for reporting back?
Is there such a string already?</t>
<t>(Cliff): Scope strings are like administrative-domain in IF-MAP.
It would solve many problems if DHCP servers could provide this
string to endpoints and to observers.
I am not sure whether there is a standard DHCP option that
fills the bill or not.
I am not sure how easily application software can get
the DHCP options from the underlying OS.
But this is worth exploring.</t>
<t>(Jim): We may need to look at what happens if
a scope identifier is either not set or not available.
I am thinking of the virtual network that is NATed on my machine.
If those VMs reported [on themselves] then the network configuring
systems may not know about that VM and there would not
necessarily be a reasonable scope string to report for it.</t>
</section>
<section title="Meaning">
<t>Throughout the time interval of the AVP,
the endpoint had the right to use,
or was communicating using, the specified IP address.</t>
</section>
<section title="Relationships">
<t>A network profiler might know an endpoint's address
and something about the software running on the endpoint.
The profiler might know nothing else.
So data models MUST support an endpoint attribute assertion
relating the IP address to a set of software components.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>An address is "bound to" a network interface.</t>
<t>An address is considered "bound to" an endpoint just if the
address is "bound to" an interface that is "in" the endpoint.</t>
<t>An address may be "in" one or more locations. (DELETE?)</t>
</list></t>
</section>
<section title="Multiplicity">
<t>An endpoint attribute assertion MAY contain
one or more IP addresses.</t>
<t>An IP address may be used by more than one endpoint at a time,
largely because of Network Address Translation (NAT).
Where practical, a scope string SHOULD be included,
to disambiguate.</t>
<t>In practice, an IP address can be used by only one
endpoint in an IP routing domain at a time.</t>
</section>
<section title="Stability">
<t>The stability of IP address assignments varies widely.
Some assignments are persistent, some volatile.
The time interval of the AVP MUST NOT reach into the future,
not even if (for example) the DHCP lease is infinite.</t>
</section>
<section title="Accuracy">
<t>For IP addresses that a provider knows by
observation or verification: <list style="symbols">
<t>Network Address Translation (NAT, RFC2663) is a pitfall.</t>
<t>The provider MUST NOT include an IP address that
the provider knows to be a translated address.</t>
<t>The provider SHOULD be configurable with
a set of IP address blocks to be excluded.
Address blocks set aside for NAT devices SHOULD
be excluded, by administrators for example.</t>
<t>ISSUE: In a later SACM version, it would be good to
overcome this, by publishing the association
between the internal and external address-port
combinations.</t>
</list></t>
<t>For IP addresses that a provider
knows by observation or verification,
IP address spoofing is a pitfall.
Network administrators SHOULD take countermeasures.
Ingress filtering (RFC3704) is one.
DHCP snooping is another: many Network Access Devices
can confine endpoints to IP addresses assigned
by authorized DHCP servers.</t>
</section>
<section title="Data Model Requirements">
<t>All SACM data models MUST support this entire subsection.</t>
</section>
</section>
-->
<!-- TODO: Integrate what we need into the information element and
remove what is unneeded.
<section title="Hardware Serial Number">
<section title="Range of Values">
<t>MUST be a vendor ID string and a serial number string string.
The vendor ID string MAY be empty, a URI, or a vendor number.</t>
</section>
<section title="Meaning">
<t>Throughout the time interval of the AVP,
the endpoint had a hardware component by
the indicated manufacturer and having the specified serial number.</t>
</section>
<section title="Multiplicity">
<t>An endpoint may have any number of hardware instances,
each with a different serial number.
An endpoint attribute assertion may contain AVPs
for any subset of the
hardware instances.</t>
<t>Vendors generally ensure that each serial number goes to
only one hardware instance.</t>
</section>
<section title="Stability">
<t>Each hardware component is immutably associated
with a hardware serial number.
But hardware can be replaced or removed.
As endpoint attributes, hardware serial numbers are *persistent*
but not *immutable*.</t>
</section>
<section title="Accuracy">
</section>
<section title="Data Model Requirements">
<t>All SACM data models MUST support this entire subsection.</t>
</section>
</section>-->
<section title="Certificate">
<section title="Range of values">
<t>MUST be X.509 certificate, per <xref target="RFC5280"/>.</t>
</section>
<section title="Meaning">
<t>Throughout the time interval of the AVP,
the endpoint had the private key corresponding to
the specified certificate.</t>
<t>Throughout the time interval,
the certificate was valid: it had a valid
certificate chain from a CA certificate that the asserter
trusted; every certificate in the chain was time-valid;
no certificate in in the chain (excluding the CA certificate)
was revoked. ISSUE (CEK): Do we want to get this PKI-ish? If so,
would we include the CA certificate as well?</t>
</section>
<section title="Multiplicity">
<t>An endpoint may use, or have the right to use, one or more
certificates.</t>
<t>Some certificates may be used on more than one endpoint.
Other certificates are (by intent) bound to a single endpoint.
ISSUE (CEK): Is there a standard way to distinguish the two?
We could perhaps provide a configurable criterion,
as an information element. Should we?</t>
</section>
<section title="Stability">
<t>Certificates are replaced, due to expiration and other
reasons.
By and large, they are not replaced often.
A year is a typical interval.
In sum, they are persistent.</t>
<t>A private key is baked into hardware is almost immutable.
But again, hardware can be replaced.</t>
</section>
<section title="Accuracy">
<t>If a certificate is known by verification, the attribute
is highly accurate.</t>
</section>
<section title="Data model requirements">
<t>All SACM data models MUST support this entire subsection.</t>
</section>
</section>
<section title="Public Key">
<t>TODO</t>
</section>
<section title="Username?">
<t>ISSUE (CEK): If a user certificate can be an identifying attribute,
why not a username also?
At an earlier stage of our discussions, usernames were
considered common identifying attributes.
Did we decide they should not be? Or just forget them?</t>
<t>Many endpoints do not have client certificates.
An authenticated username is a useful clue for identifying
such an endpoint.
I log in only to a handful of personal endpoints.
I also present my username and password to many multi-user
servers. We would have to distinguish personal endpoints
from server endpoints somehow.</t>
</section>
<section title="Tool-Specific Identifier">
<t>TODO</t>
<t>TODO: "Tool-specific identifier" suggests that two tools could
never agree on a tool-specific identifier.
But a community may agree on an identifier notation,
and might even create a formal standard.
All that's important is that each of these attributes has a type
and meaning *not* specified by the SACM internet drafts.
"Vendor-specific identifier?" "Custom identifier?"
</t>
</section>
<section title="Identification of Endpoints where SACM Components Reside">
<t>Every information element needs identifying attributes
of its producer's endpoint.
(TODO: Provide normative language. SHOULD? MUST?)
</t>
<t>Specifically, in an endpoint attribute assertion,
we need identifying attributes of the asserter's endpoint.
If the asserter is external, the assertion will contain
identifying attributes of two endpoints.
(TODO: Discuss what this information is for.)
</t>
</section>
<section title="Security Considerations">
<t>Effects of misidentification</t>
<t>Things that can cause misidentification</t>
<t>How minimize misidentification</t>
</section>
</section>
<!-- TODO: Re-integrate this text into information element once we know how we are
representing relationships.
<section title="Network Interface">
<t>An endpoint generally has at least one network interface.</t>
<t>Interfaces nest. A virtual interface can nest in a physical interface.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>A network interface is "in" an endpoint.</t>
<t>A network interface is "in" another network interface; this
is for a nested interface. CEK: And this allows representing
compliance policies that are worthwhile. But is this too advanced
for the initial set of SACM RFCs?</t>
<t>A network interface "acts for" an identity.
This occurs, for example, when the network interface is online
because of successful 802.1X.
An internal collector may be aware of the identity.
An external collector (such as a RADIUS server <xref target="RFC3580"/>) will be aware of the identity.</t>
</list></t>-->
<section title="Identity">
<t>TODO: Delete this section?</t>
<t>An identity is the non-secret part of a credential. Examples are a username,
an X.500 distinguished name, and a public key. Passwords, private keys,
and other secrets are not considered part of an identity.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>An endpoint may "act for" an identity.
This SHALL mean that the endpoint claims or proves that it has this
identity. For example, if the endpoint is part of an
Active Directory domain and Alice logs into the endpoint with her
AD username (alice) and password, the endpoint "acts for" alice.
An endpoint MAY "act for" more than one identity,
such as a machine identity and a user identity.</t>
<t>A identity may "belong to" an account.
For example, an enterprise may have a database
that maps identities to accounts.
CEK: Is this relevant? I don't see how we'd use the notion
of an account in identifying an endpoint or in specifying
compliance measurements to be taken.</t>
</list></t>
</section>
<section title="Location">
<t>TODO: Delete this section?</t>
<t>Location can be logical or physical.
Location can be a clue to an endpoint's identity.</t>
<t>A data model MUST support the following relationships:<list style="symbols">
<t>One or more endpoints may be "in" a location</t>
<t>A location may be "in" one or more locations</t>
<t>A network address may be "in" a location</t>
<t>An account may be "in" a location; this would happen
if the account represents a user, and a physical access
control system reports on the user's location</t>
</list></t>
<t>Examples of location:<list style="symbols">
<t>The switch, access point, VPN gateway, or cell tower to which the endpoint is
linked</t>
<t>The switch port where the endpoint is plugged in</t>
<t>The location of the endpoint's IP address in the network
topology</t>
<t>The geographic location of the endpoint (which is often
self-reported)</t>
<t>A user location (may be reported by a physical access control
system)</t>
</list></t>
<t>CEK: The last three examples seem too advanced for the first set of SACM RFCs.
I do not know a notation that would be interoperable and
useful for endpoint identification. Should we drop them?</t>
<t>CEK: If we do drop them, all we have left is the device and port at which the
endpoint is linked to the network. Maybe we should regard that as a kind
of address.</t>
<t>A data model MUST support switch + port number,
access point, and VPN gateway as locations.
The other examples are optional.</t>
<t>More than one of kind of location may pertain to an endpoint. Endpoint has a
many-to-many relationship with Location.</t>
</section>
<section title="Endpoint Attribute Assertion">
<t>TODO: Integrate into the <xref target="information-model-framework"/> as appropriate.</t>
<section title="Form and Precise Meaning">
<t>An endpoint attribute assertion has:
<list style="symbols">
<t>One or more attribute-value pairs (AVPs)</t>
<t>Time intervals over which the AVPs hold</t>
<t>Endpoint uniquely identified? True or false</t>
<t>Provenance, including:
<list style="symbols">
<t>The SACM component that made the assertion</t>
<t>Information about the method used to derive the assertion</t>
</list>
</t>
</list>
</t>
<t>It means that over the specified time interval, there was an endpoint for which all of the listed attribute-value pairs were true.</t>
<t>If the "Endpoint uniquely identified" is true, the set of attributes-value
pairs together make this assertion apply to only one endpoint.</t>
<t>The attributes can include posture attributes and
identification attributes. The model does not make a
rigid distinction between the two uses of attributes.</t>
<t>Some of the attributes may be multi-valued.
</t>
<t>One of the AVPs may be a unique endpoint identifier.
Not every endpoint will have one. If there is one, the SACM component that produces
the Endpoint Attribute Assertion will not necessarily know what it is.</t>
</section>
<section title="Asserter">
<t>An Endpoint Attribute Assertion may come from an
attribute collector or an evaluator. It may come from a SACM component that derives
it from out-of-band sources, such as
a physical inventory system. A SACM component may derive it
from other Endpoint Attribute Assertions.</t>
</section>
<section title="Example">
<t> For example, an attribute assertion might have these attribute-value pairs:<list>
<t>mac-address = 01:23:45:67:89:ab</t>
<t>os = OS X</t>
<t>os-version = 10.6.8</t>
</list></t>
<t>This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran OS X 10.6.8 throughout the specified time interval. A profiler might have provided this assertion.</t>
</section>
<section title="A Use Case">
<t>For example, Endpoint Attribute Assertions should help SACM components to track an endpoint as it roams or stays stationary. They must track endpoints because they must track endpoints' postures over time. Tracking of an endpoint can employ many clues, such as:<list>
<t>The endpoint's MAC address</t>
<t>The authenticated identity (even if it identifies a user)</t>
<t>The location of the endpoint and the user</t>
</list></t>
</section>
<section title="Event">
<t>An event is represented as a Posture Attribute Assertion
whose time interval has length zero.</t>
<t>Some potential kinds of events are:<list style="symbols">
<t>A structured syslog message <xref target="RFC5424"/></t>
<t>IF-MAP event metadata <xref
target="TNC-IF-MAP-NETSEC-METADATA"/></t>
<t>A NetFlow message <xref target="RFC3954"/></t>
</list></t>
</section>
<section title="Difference between Attribute and Event">
<t>Author: Henk Birkholz</t>
<t>"Attribute" and "event" are often used fairly interchangeably. A
clear distinction makes the words more useful.</t>
<t>An *attribute* tends not to change until something causes a change. In
contrast, an *event* occurs at a moment in time.</t>
<t>For a nontechnical example, let us consider "openness" as an attribute of a door, with two values, "open" and "closed". A
closed door tends to stay closed until something opens it (a breeze,
a person, or a dog).</t>
<t>The door's opening or closing is an event.</t>
<t>Similarly, "Host firewall enabled" may be modeled as a true/false attribute of an endpoint.
Enabling or disabling the host firewall may be modeled as
an event. An endpoint's crashing also may be modeled as an
event.</t>
<t>Although events are not attributes,
we use one kind of information element,
the "Endpoint Attribute Assertion",
to describe both attributes and events.</t>
</section>
</section> <!-- Endpoint Attribute Assertion -->
<section title="Attribute-Value Pair">
<t>TODO: Integrate into the <xref target="information-model-framework"/> as appropriate.</t>
<t>The set of attribute types must be extensible, by other IETF standards, by other standards groups, and by vendors. How to express attribute types is not defined here, but is left to data models.</t>
<t>The value may be structured. For example, it may something like XML.</t>
<t>The information model requires a standard attribute type (or possibly more than one) for each box in
<xref target="figure-model-of-endpoint"/>:
<list style="symbols">
<t>Hardware Component: the value identifies the hardware type. For example, it may consist of the make and model number.</t>
<t>Hardware Instance: the value, together with the Hardware Component value, uniquely identifies the hardware instance. For example, it may be a manufacturer-assigned
serial number. This notion might not apply to all virtual hardware components.</t>
<t>Software Component: the value identifies a unit of software. Each
installable piece of software should be separately identifiable.
For example, this might be a Software Identifier (SWID). Therefore, a software inventory for an endpoint should be expressed as an Endpoint Attribute Assertion.</t>
<t>Software Instance: the value describes how the software component is installed and configured.</t>
<t>Endpoint: The value is a unique endpoint identifier.</t>
<t>Location</t>
<t>Identity: The value is the non-secret part of a credential.
For example, it may be a certificate, or just a subject Distinguished Name extracted from a certificate. It may be a username.</t>
<t>Network Interface: TBD</t>
<t>User: [cek: Do we want this? If one user uses different
credentials at different times, do we think SACM components
will need know that it's the same user?]</t>
<t>Address: The value is an IP, MAC, or other network address,
possibly qualified with its scope.</t>
</list></t>
<section title="Unique Endpoint Identifier">
<t>An organization should try to uniquely identify and label an endpoint, whether the endpoint is enrolled or is discovered in the operational environment. The identifier should be assigned by or used in the enrollment process. </t>
<t>Here "unique" means one-to-one. In practice, uniqueness is not always attainable. Even if an endpoint has a unique identifier, an attribute collector may not always know it.</t>
<t>If the attribute type of an AVP is "endpoint", the value
is a unique identifier of the endpoint.</t>
</section>
<section title="Posture Attribute">
<t>Some AVPs will be posture attributes.</t>
<t>See the definition in the SACM Terminology for Security Assessment
<xref target="I-D.ietf-sacm-terminology"/>.</t>
<t>Some potential kinds of posture attributes are:<list style="symbols">
<t>A NEA posture attribute (PA) <xref target="RFC5209"/></t>
<t>A YANG model <xref target="RFC6020"/></t>
<t>An IF-MAP device-characteristics metadata item <xref
target="TNC-IF-MAP-NETSEC-METADATA"/></t>
</list></t>
</section>
</section>
<section title="Evaluation Result">
<t>Evaluation Results (see <xref
target="I-D.ietf-sacm-terminology"/>) are modeled as Endpoint Attribute Assertions.</t>
<t>An Evaluation
Result derives from one or more other Endpoint Attribute Assertions.</t>
<t>An example is: a NEA access recommendation <xref target="RFC5793"/></t>
<t>An evaluator may be able to evaluate better if history is
available. This is a use case for retaining Endpoint Attribute Assertions for a time.</t>
<t>An Evaluation Result may be retained longer than the Endpoint Attribute Assertions from which it derives. (<xref
target="figure-model-of-endpoint"/> does not show this.) In the
limiting case, Endpoint Attribute Assertions are not retained. When
as an Endpoint Attribute Assertion arrives, an evaluator produces
an Evaluation Result. These mechanics are out of the scope of the Information Model.</t>
</section>
<section title="SACM Component">
<t>Although SACM components are mainly covered by the SACM architecture, we have some remarks. TODO: Move them to the architecture document?</t>
<t>ISSUE (CEK): Why do we need information elements that model SACM compoments?</t>
<section title="External Attribute Collector">
<t>An external collector is a collector
that observes endpoints from
outside. [kkw-many of these [collectors] are
actually configured and operated to manage assets for reasons other
than posture assessments. it is critical to bring them into this, so
i like it...but does it matter if the [collector] isn't intended to support
posture assessment, but happens to have information that can be
used by posture assessment collection consumers? do we lump them
together with collectors that are intended to support posture
assessment but run external to the endpoint?]
[jmf: ditto. The exampled below are of things that would perform external collection].
</t>
<t>[cek-to kkw's comment, I think the purpose here is to capture their
contribution to continuous monitoring. I don't see the need to separate
things whose primary job is monitoring from things whose primary job is
something else. Is there a need?]</t>
<t>[cek-to jmf's comment, that is what they are examples of; is a text
change needed?]</t>
<t>Examples:<list style="symbols">
<t>A RADIUS server <xref target="RFC3580"/> whereby an endpoint has logged onto the
network</t>
<t>A network profiling system, which discovers and classifies
network nodes</t>
<t>A Network Intrusion Detection System (NIDS) sensor</t>
<t>A vulnerability scanner</t>
<t>A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine</t>
<t>A management system that configures and installs software on the
endpoint</t>
</list></t>
</section>
<section title="Evaluator">
<t>An evaluator can consume
endpoint attribute assertions, previous evaluations of posture attributes,
or previous reports of evaluation results. [kkw-i don't think this
conflicts with the definition in the terminology doc re: that
evaluation tasks evaluate posture attributes.]</t>
<t>[cek-I like the change. I think it *does* require a change in the terminology doc, though.]</t>
<t>Example: a NEA posture validator <xref target="RFC5209"/></t>
<t>[jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?]</t>
<t>[cek-Why isn't a NEA posture validator an example?]</t>
</section>
</section>
<section title="Organization?">
<t>[kkw-from a reporting standpoint there needs to be
some concept like organization or system. without this, there is no
way to produce result reports that can be acted upon to provide the
insight or accountability that almost all continuous monitoring
instances are trying to achieve. from a scoring or grading
standpoint, an endpoint needs to be associated with exactly one
organization or system. it can have a many to many relationship
with other types of results reporting "bins". is this important
to include here? we had organization as a core asset type for this
reason, so i think it is a key information element. but i also
know that i do not want to define all the different reporting
types, so i am unsure.]</t>
<t>[cek-I had not thought of this at all. Would it make sense to treat the organization and the bins
as part of the guidance for creating reports? Maybe not. We should discuss.]</t>
</section>
<section title="Guidance">
<t>[jmf- the guidance sections need more detail. . .]</t>
<t>[cek - What is missing? We would welcome a critique or text.]</t>
<t>Guidance is generally configurable by human administrators.</t>
<section title="Internal Collection Guidance">
<t>An internal collector may need guidance to govern what it
collects and when.</t>
</section>
<section title="External Collection Guidance">
<t>An external collector may need guidance to govern what it
collects and when.</t>
</section>
<section title="Evaluation Guidance">
<t>An evaluator typically needs Evaluation Guidance to govern
what it considers to be a good or bad security posture.</t>
</section>
<section title="Retention Guidance">
<t>A SACM deployment may retain posture attributes, events, or
evaluation results for some time. Retention supports ad hoc
reporting and other use cases.</t>
<t>If information is retained, retention guidance controls what is
retained and for how long.</t>
<t>If two or more pieces of retention guidance apply to a piece of information,
the guidance calling for the longest retention should take
precedence.</t>
</section>
</section>
<section title="Endpoint">
<t>See the definition in the SACM Terminology for Security Assessment <xref
target="I-D.ietf-sacm-terminology"/>.</t>
<t>In the model, an endpoint can be part of another endpoint.
This covers cases where multiple physical endpoints act as one endpoint. The constituent endpoints may not be distinguishable by external observation of network behavior.</t>
<t>For example, a hosting center may maintain a redundant set (redundancy group) of
multi-chassis setups to provide active redundancy and load distribution
on network paths to WAN gateways. Multi-chassis link aggregation
groups make the chassis appear as one endpoint.
Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state of
redundancy groups. Even if a physical endpoint (e.g. router) that is
part of a redundancy group is replaced, the redundancy group can remain
the same.
</t>
<section title="Endpoint Identity">
<t>An endpoint identity provides both identification and
authentication of the endpoint. For example, an identity may be an
X.509 certificate <xref target="RFC5280"/> and corresponding private
key.
[jmf- this example should be formatted like the other examples in this section]
</t>
<t>Not all kinds of identities are guaranteed to be unique.</t>
</section>
<section title="Software Component">
<t>An endpoint contains and runs software components.</t>
<t>Some of the software components are assets.
"Asset" is defined in RFC4949 <xref target="RFC4949"/> as "a system
resource that is (a) required to be protected by an information
system's security policy, (b) intended to be protected by a
countermeasure, or (c) required for a system's mission."</t>
<t>An examination of software needs to
consider both (a) software assets and (b) software that may
do harm. A posture attribute collector may not know (a) from (b). It is useful
to define Software Component as the union of (a) and (b).</t>
<t>Examples of Software Assets:<list style="symbols">
<t>An application</t>
<t>A patch</t>
<t>The operating system kernel</t>
<t>A boot loader</t>
<t>Firmware that controls a disk drive</t>
<t>A piece of JavaScript found in a web page the user visits</t>
</list></t>
<t>Examples of harmful software components:<list style="symbols">
<t>A malicious entertainment app</t>
<t>A malicious executable</t>
<t>A web page that contains malicious JavaScript</t>
<t>A business application that shipped with a virus</t>
</list></t>
<section title="Unique Software Identifier">
<t>Organizations need to be able to uniquely identify and label software installed or run on an endpoint. Specifically, they need to know the name, publisher, unique ID, and version; and any related patches. In some cases the software's identity might be known a priori by the organization; in other cases, a software identity might be first detected by an organization when the software is first inventoried in an operational environment. Due to this, it is important that an organization have a stable and consistent means to identify software found during collection.</t>
<t>A piece of software may have a unique identifier, such as a SWID tag
(ISO/IEC 19770).</t>
</section>
</section>
</section> <!-- endpoint -->
<section title="User">
<section title="User Identity">
<t>An endpoint is often - but not always - associated with one or more
users.</t>
<t>A user's identity provides both identification and authentication
of the user. @@@ Eh?</t>
</section>
</section>
<section title="hardwareSerialNumber">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="interfaceName">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="interfaceIndex">
<figure>
<artwork>
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].
</artwork>
</figure>
</section>
<section title="interfaceMacAddress">
<figure>
<artwork>
elementId: TBD
name: interfaceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 MAC address associated with a network
interface on an endpoint.
</artwork>
</figure>
</section>
<section title="interfaceType">
<figure>
<artwork>
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].
</artwork>
</figure>
</section>
<section title="interfaceFlags">
<figure>
<artwork>
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:
</artwork>
</figure>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<c>0x1</c>
<c>interface is up</c>
<c>0x2</c>
<c>broadcast address valid</c>
<c>0x4</c>
<c>turn on debugging</c>
<c>0x8</c>
<c>is a loopback net</c>
<c>0x10</c>
<c>interface is point-to-point link</c>
<c>0x20</c>
<c>avoid use of trailers</c>
<c>0x40</c>
<c>resources allocated</c>
<c>0x80</c>
<c>no address resolution protocol</c>
<c>0x100</c>
<c>receive all packets</c>
</texttable>
</section>
<section title="networkInterface">
<figure>
<artwork>
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.
</artwork>
</figure>
<figure>
<artwork>
networkInterface = (basicList, allof,
interfaceName,
interfaceIndex,
macAddress,
ifType,
flags
)
</artwork>
</figure>
</section>
<section title="softwareIdentifier">
<figure>
<artwork>
elementId: TBD
name: softwareIdentifier
dataType: string
dataTypeSemantics: default
status: current
description: A globally unique identifier for a particular
software application.
</artwork>
</figure>
</section>
<section title="softwareTitle">
<figure>
<artwork>
elementId: TBD
name: softwareTitle
dataType: string
dataTypeSemantics: default
status: current
description: The title of the software application.
</artwork>
</figure>
</section>
<section title="softwareCreator">
<figure>
<artwork>
elementId: TBD
name: softwareCreator
dataType: string
dataTypeSemantics: default
status: current
description: The software developer (e.g., vendor or author).
</artwork>
</figure>
</section>
<section title="simpleVersion">
<figure>
<artwork>
elementId: TBD
name: simpleVersion
dataType: simpleVersionType
dataTypeSemantics: default
status: current
description: The version string for a software application that
follows the simple versioning scheme.
</artwork>
</figure>
</section>
<section title="rpmVersion">
<figure>
<artwork>
elementId: TBD
name: rpmVersion
dataType: rpmVersionType
dataTypeSemantics: default
status: current
description: The version string for a software application that
follows the RPM versioning scheme.
</artwork>
</figure>
</section>
<section title="ciscoTrainVersion">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="softwareVersion">
<figure>
<artwork>
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,
...
)
</artwork>
</figure>
</section>
<section title="lastUpdated">
<figure>
<artwork>
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)
</artwork>
</figure>
</section>
<section title="softwareInstance">
<figure>
<artwork>
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
)
</artwork>
</figure>
</section>
<section title="globallyUniqueIdentifier">
<figure>
<artwork>
elementId: TBD
name: globallyUniqueIdentifier
dataType: unsigned8
dataTypeSemantics: identifier
status: current
metadata: true
description: TODO.
</artwork>
</figure>
</section>
<section title="dataOrigin">
<figure>
<artwork>
elementId: TBD
name: dataOrigin
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The origin of the data. TODO make a better
description.
</artwork>
</figure>
</section>
<section title="dataSource">
<figure>
<artwork>
elementId: TBD
name: dataSource
dataType: string
dataTypeSemantics: default
status: current
metadata: true
description: The source of the data. TODO make a better
description.
</artwork>
</figure>
</section>
<section title="creationTimestamp">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="collectionTimestamp">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="publicationTimestamp">
<figure>
<artwork>
elementId: TBD
name: publicationTimestamp
dataType: dateTimeSeconds
dataTypeSemantics: default
status: current
metadata: true
description: The date and time when the posture
information was published.
</artwork>
</figure>
</section>
<section title="relayTimestamp">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="storageTimestamp">
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title="type">
<figure>
<artwork>
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 |
+-------+----------------------------------+
|... | ... |
+-------+----------------------------------+
</artwork>
</figure>
</section>
<section title="protocolIdentifier">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="sourceTransportPort">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="sourceIPv4PrefixLength">
<figure>
<artwork>
elementId: TBD
name: sourceIPv4PrefixLength
dataType: unsigned8
dataTypeSemantics:
status: current
description: The number of contiguous bits that are relevant in the
sourceIPv4Prefix Information Element.</artwork>
</figure>
</section>
<section title="ingressInterface">
<figure>
<artwork>
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].</artwork>
</figure>
</section>
<section title="destinationTransportPort">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="sourceIPv6PrefixLength">
<figure>
<artwork>
elementId: TBD
name: sourceIPv6PrefixLength
dataType: unsigned8
dataTypeSemantics:
status: current
description: The number of contiguous bits that are relevant in the
sourceIPv6Prefix Information Element.</artwork>
</figure>
</section>
<section title="sourceIPv4Prefix">
<figure>
<artwork>
elementId: TBD
name: sourceIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 source address prefix.</artwork>
</figure>
</section>
<section title="destinationIPv4Prefix">
<figure>
<artwork>
elementId: TBD
name: destinationIPv4Prefix
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: IPv4 destination address prefix.</artwork>
</figure>
</section>
<section title="sourceMacAddress">
<figure>
<artwork>
elementId: TBD
name: sourceMacAddress
dataType: macAddress
dataTypeSemantics: default
status: current
description: The IEEE 802 source MAC address field.</artwork>
</figure>
</section>
<section title="ipVersion">
<figure>
<artwork>
elementId: TBD
name: ipVersion
dataType: unsigned8
dataTypeSemantics: identifier
status: current
description: The IP version field in the IP packet header.</artwork>
</figure>
</section>
<section title="interfaceName">
<figure>
<artwork>
elementId: TBD
name: interfaceName
dataType: string
dataTypeSemantics: default
status: current
description: A short name uniquely describing an interface, eg "Eth1/0".</artwork>
</figure>
</section>
<section title="interfaceDescription">
<figure>
<artwork>
elementId: TBD
name: interfaceDescription
dataType: string
dataTypeSemantics: default
status: current
description: The description of an interface, eg "FastEthernet 1/0" or "ISP
connection".</artwork>
</figure>
</section>
<section title="applicationDescription">
<figure>
<artwork>
elementId: TBD
name: applicationDescription
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the description of an application.</artwork>
</figure>
</section>
<section title="applicationId">
<figure>
<artwork>
elementId: TBD
name: applicationId
dataType: octetArray
dataTypeSemantics: default
status: current
description: Specifies an Application ID per [RFC6759].</artwork>
</figure>
</section>
<section title="applicationName">
<figure>
<artwork>
elementId: TBD
name: applicationName
dataType: string
dataTypeSemantics: default
status: current
description: Specifies the name of an application.</artwork>
</figure>
</section>
<section title="exporterIPv4Address">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="exporterIPv6Address">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="portId">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="templateId">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="collectorIPv4Address">
<figure>
<artwork>
elementId: TBD
name: collectorIPv4Address
dataType: ipv4Address
dataTypeSemantics: default
status: current
description: An IPv4 address to which the Exporting Process sends Flow
information.</artwork>
</figure>
</section>
<section title="collectorIPv6Address">
<figure>
<artwork>
elementId: TBD
name: collectorIPv6Address
dataType: ipv6Address
dataTypeSemantics: default
status: current
description: An IPv6 address to which the Exporting Process sends Flow
information.</artwork>
</figure>
</section>
<section title="informationElementIndex">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="basicList">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="subTemplateList">
<figure>
<artwork>
elementId: TBD
name: subTemplateList
dataType: subTemplateList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a subTemplateList
abstract data type.</artwork>
</figure>
</section>
<section title="subTemplateMultiList">
<figure>
<artwork>
elementId: TBD
name: subTemplateMultiList
dataType: subTemplateMultiList
dataTypeSemantics: list
status: current
description: Specifies a generic Information Element with a
subTemplateMultiList abstract data type.</artwork>
</figure>
</section>
<section title="informationElementId">
<figure>
<artwork>
elementId: TBD
name: informationElementId
dataType: unsigned16
dataTypeSemantics: identifier
status: current
description: This Information Element contains the ID of another Information
Element.</artwork>
</figure>
</section>
<section title="informationElementDataType">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementDescription">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementName">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementRangeBegin">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementRangeEnd">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementSemantics">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="informationElementUnits">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="userName">
<figure>
<artwork>
elementId: TBD
name: userName
dataType: string
dataTypeSemantics: default
status: current
description: User name associated with the flow.</artwork>
</figure>
</section>
<section title="applicationCategoryName">
<figure>
<artwork>
elementId: TBD
name: applicationCategoryName
dataType: string
dataTypeSemantics: default
status: current
description: An attribute that provides a first level categorization for
each Application ID.</artwork>
</figure>
</section>
<section title="mibObjectValueInteger">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueOctetString">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueOID">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueBits">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueIPAddress">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueCounter">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueGauge">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueTimeTicks">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueUnsigned">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueTable">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectValueRow">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectIdentifier">
<figure>
<artwork>
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].</artwork>
</figure>
</section>
<section title="mibSubIdentifier">
<figure>
<artwork>
elementId: TBD
name: mibSubIdentifier
dataType: unsigned32
dataTypeSemantics: identifier
status: current
description: A non-negative sub-identifier of an Object Identifier (OID).</artwork>
</figure>
</section>
<section title="mibIndexIndicator">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibCaptureTimeSemantics">
<figure>
<artwork>
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</artwork>
</figure>
</section>
<section title="mibContextEngineID">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibContextName">
<figure>
<artwork>
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.</artwork>
</figure>
</section>
<section title="mibObjectName">
<figure>
<artwork>
elementId: TBD
name: mibObjectName
dataType: string
dataTypeSemantics: default
status: current
description: The name (called a descriptor in [RFC2578]
of an object type definition.</artwork>
</figure>
</section>
<section title="mibObjectDescription">
<figure>
<artwork>
elementId: TBD
name: mibObjectDescription
dataType: string
dataTypeSemantics: default
status: current
description: The value of the DESCRIPTION clause of an MIB object
type definition.</artwork>
</figure>
</section>
<section title="mibObjectSyntax">
<figure>
<artwork>
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].</artwork>
</figure>
</section>
<section title="mibModuleName">
<figure>
<artwork>
elementId: TBD
name: mibModuleName
dataType: string
dataTypeSemantics: default
status: current
description: The textual name of the MIB module that defines a MIB
Object.</artwork>
</figure>
</section>
</section>
<section title="SACM Usage Scenario Example">
<t>TODO: this section needs to refer out to wherever the operations / generalized workflow
content ends up</t>
<t>TODO: revise to eliminate graph references</t>
<t>This section illustrates the proposed SACM Information Model as applied to
SACM Usage Scenario 2.2.3, Detection of Posture Deviations <xref
target="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.</t>
<t>The Detection of Posture Deviations scenario involves multiple elements
interacting to accomplish the goals of the scenario. <xref target="figure-model-of-endpoint"/> illustrates those elements along with their major communication paths.</t>
<section title="Graph Model for Detection of Posture Deviation">
<t>The following subsections contain examples of identifiers and metadata which
would enable detection of posture deviation. These lists are by no means
exhaustive - many other types of metadata would be enumerated in a data model
that fully addressed this usage scenario.</t>
<section title="Components">
<t>The proposed SACM Information Model contains three components, as defined in
the SACM Architecture <xref target="I-D.ietf-sacm-architecture"/>:
Posture Attribute Information Provider, Posture Attribute Information
Consumer, and Control Plane.</t>
<t>In this example, the components are instantiated as follows:<list style="symbols">
<t>The Posture Attribute Information Provider is an endpoint security
service which monitors the compliance state of the endpoint and
reports any deviations for the expected posture.</t>
<t>The Posture Attribute Information Consumer is an analytics engine
which absorbs information from around the network and generates a
"heat map" of which areas in the network are seeing unusually high
rates of posture deviations.</t>
<t>The Control Plane is a security automation broker which receives
subscription requests from the analytics engine and authorizes
access to appropriate information from the endpoint security
service.</t>
</list></t>
</section>
<section title="Identifiers">
<t>To represent the elements listed above, the set of identifiers might include
(but is not limited to):<list style="symbols">
<t>Identity - a device itself, or a user operating a device, categorized
by type of identity (e.g. username or X.509 certificate <xref
target="RFC5280"/>)</t>
<t>Software asset</t>
<t>Network Session</t>
<t>Address - categorized by type of address (e.g. MAC address, IP
address, Host Identity Protocol (HIP) Host Identity Tag (HIT) <xref
target="RFC5201"/>, etc.)</t>
<t>Task - categorized by type of task (e.g. internal collector,
external collector, evaluator, or reporting task)</t>
<t>Result - categorized by type of result (e.g. evaluation result or
report)</t>
<t>Guidance</t>
</list></t>
</section>
<section title="Metadata">
<t>To characterize the elements listed above, the set of metadata types might
include (but is not limited to):<list style="symbols">
<t>Authorization metadata attached to an identity identifier, or to a
link between a network session identifier and an identity
identifier, or to a link between a network session identifier and an
address identifier.</t>
<t>Location metadata attached to a link between a network session
identifier and an address identifier.</t>
<t>Event metadata attached to an address identifier or an identity
identifier of an endpoint, which would be made available to
interested parties at the time of publication, but not stored
long-term. For example, when a user disables
required security software, an internal collector associated with
an endpoint security service might publish guidance violation event
metadata attached to the identity identifier of the endpoint, to notify consumers of the
change in endpoint state.</t>
<t>Posture attribute metadata attached to an identity identifier of an
endpoint. For example, when required security software
is not running, an internal collector associated with
an endpoint security service might publish posture attribute
metadata attached to the identity identifier of the endpoint,
to notify consumers of the
current state of the endpoint.</t>
</list></t>
</section>
<section title="Relationships between Identifiers and Metadata">
<t>Interaction between multiple sets of identifiers and metadata lead to some
fairly common patterns, or "constellations", of metadata. For example, an
authenticated-session metadata constellation might include a central network
session with authorizations and location attached, and links to a user
identity, an endpoint identity, a MAC address, an IP address, and the
identity of the policy server that authorized the session, for the duration
of the network session.</t>
<t>These constellations may be independent of each other, or one constellation
may be connected to another. For example, an authenticated-session metadata
constellation may be created when a user connects an endpoint to the
network; separately, an endpoint- posture metadata constellation may be
created when an endpoint security system and other collectors gather
and publish posture information related to an endpoint. These two
constellations are not necessarily connected to each other, but may be
joined if the component publishing the authenticated-session metadata
constellation is able to link the network session identifier to the identity
identifier of the endpoint.</t>
</section>
</section>
<section title="Workflow">
<t>The workflow for exchange of information supporting detection of posture
deviation, using a standard publish/subscribe/query transport model such as
available with IF-MAP <xref target="TNC-IF-MAP-SOAP-Binding"/> or XMPP-Grid
<xref target="I-D.salowey-sacm-xmpp-grid"/>, is as follows:<list
style="numbers">
<t>The analytics engine (Posture Assessment Information Consumer)
establishes connectivity and authorization with the transport fabric,
and subscribes to updates on posture deviations.</t>
<t>The endpoint security service (Posture Assessment Information Provider)
requests connection to the transport fabric.</t>
<t>Transport fabric authenticates and establishes authorized privileges
(e.g. privilege to publish and/or subscribe to security data) for the
requesting components.</t>
<t>The endpoint security service evaluates the endpoint, detects posture
deviation, and publishes information on the posture deviation.</t>
<t>The transport fabric notifies the analytics engine, based on its
subscription of the new posture deviation information.</t>
</list></t>
<t>Other components, such as access control policy servers or remediation systems,
may also consume the posture deviation information provided by the endpoint
security service.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many of the specifications in this document have been developed in a public-private
partnership with vendors and end-users. The hard work of the SCAP community is
appreciated in advancing these efforts to their current level of adoption.</t>
<t>Over the course of developing the initial draft, Brant Cheikes, Matt Hansbury, Daniel
Haynes, Scott Pope, Charles Schmidt, and Steve Venema have contributed text to many sections of this
document.</t>
<section anchor="contributors" title="Contributors">
<t>The RFC guidelines no longer allow RFCs to be published with a large number of authors.
Some additional authors contributed to specific sections of this document; their names are
listed in the individual section headings as well as alphabetically listed with their
affiliations below.</t>
<texttable>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Affiliation</ttcol>
<ttcol align='left'>Contact</ttcol>
<c>Henk Birkholz</c>
<c>Fraunhofer SIT</c>
<c>henk.birkholz@sit.fraunhofer.de</c>
</texttable>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section title="Operational Considerations" anchor="Operational">
<t>TODO: Need to include various operational considerations here. Proposed sections include
timestamp accuracy and which attributes attributes designate an endpoint.</t>
</section>
<section title="Privacy Considerations" anchor="Privacy">
<t>TODO: Need to include various privacy considerations here.</t>
</section>
<section title="Security Considerations" anchor="Security">
<t>Posture Assessments need to be performed in a safe and secure manner. In that regard,
there are multiple aspects of security that apply to the communications between
components as well as the capabilities themselves. Due to time constraints, this
information model only contains an initial listing of items that need to be
considered with respect to security. This list is not exhaustive, and will need to
be augmented as the model continues to be developed/refined.</t>
<t>Initial list of security considerations include:<list style="hanging" hangIndent="8">
<t hangText="Authentication:">Every component and asset needs to be able to
identify itself and verify the identity of other components and assets.</t>
<t hangText="Confidentiality:">Communications between components need to be
protected from eavesdropping or unauthorized collection. Some communications
between components and assets may need to be protected as well.</t>
<t hangText="Integrity:">The information exchanged between components needs to
be protected from modification. some exchanges between assets and components
will also have this requirement.</t>
<t hangText="Restricted Access:">Access to the information collected, evaluated,
reported, and stored should only be viewable/consumable to authenticated and
authorized entities.</t>
</list></t>
<!-- EDIT: begin TNC -->
<t>The TNC IF-MAP Binding for SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/> and TNC
IF-MAP Metadata for Network Security <xref target="TNC-IF-MAP-NETSEC-METADATA"/>
document security considerations for sharing information via security automation.
Most, and possibly all, of these considerations also apply to information shared via
this proposed information model.</t>
<!-- EDIT: end TNC -->
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC0791; &RFC2119; &RFC3587; &RFC5280; &RFC6313;</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. --> &RFC3411; &RFC3416;
&RFC3418; &RFC3444; &RFC3580; &RFC3954; &RFC4287; &RFC4949; &RFC5201; &RFC5209;
&RFC5424; &RFC5792; &RFC5793; &RFC6020; &RFC6241;
&RFC6876; &RFC7012; &RFC7013; &RFC7171; &RFC7632;
&I-D.ietf-sacm-requirements; &I-D.ietf-sacm-terminology;
&I-D.ietf-sacm-architecture;
&I-D.salowey-sacm-xmpp-grid;
&W3C.REC-rdf11-concepts-20140225;
&W3C.REC-soap12-part1-20070427;
<reference
anchor="IM-LIAISON-STATEMENT-NIST"
target="http://datatracker.ietf.org/liaison/1329/">
<front>
<title>Liaison Statement: Call for Contributions for the SACM Information Model
to NIST</title>
<author fullname="Adam W. Montville" surname="Montville" initials="A.">
<address>
<email>adam@stoicsecurity.com</email>
</address>
</author>
<date year="2014" month="May" day="21"/>
</front>
</reference>
<reference anchor="NISTIR-7693"
target="http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf">
<front>
<title abbrev="Asset identification Specification v1.1">Specification for Asset
Identification 1.1</title>
<author fullname="John Wunder" surname="Wunder" initials="J."/>
<author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<date month="June" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7693"/>
</reference>
<reference anchor="NISTIR-7694"
target="http://csrc.nist.gov/publications/nistir/ir7694/NISTIR-7694.pdf">
<front>
<title abbrev="Asset Reporting Format v1.1">Specification for the Asset
Reporting Format 1.1</title>
<author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Mark Johnson" surname="Johnson" initials="M."/>
<date month="June" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7694"/>
</reference>
<reference anchor="CPE-WEBSITE" target="http://scap.nist.gov/specifications/cpe/">
<front>
<title>Common Platform Enumeration</title>
<author>
<organization abbrev="NIST">The National Institute of Standards and
Technology</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="SP800-117" target="http://csrc.nist.gov/publications/drafts/800-117-R1/Draft-SP800-117-r1.pdf">
<front>
<title abbrev="SCAP 1.2 Overview">Guide to Adopting and Using the Security Content Automation Protocol (SCAP) Version 1.2</title>
<author fullname="Stephen Quinn" surname="Quinn" initials="S."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<date month="January" year="2012"/>
</front>
<seriesInfo name="SP" value="800-117"/>
</reference>
<reference anchor="SP800-126" target="http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf">
<front>
<title abbrev="SCAP 1.2 Specification">The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2</title>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Stephen Quinn" surname="Quinn" initials="S."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
<date month="September" year="2011"/>
</front>
<seriesInfo name="SP" value="800-126"/>
</reference>
<reference anchor="NISTIR-7275"
target="http://csrc.nist.gov/publications/nistir/ir7275-rev4/nistir-7275r4_updated-march-2012_clean.pdf">
<front>
<title abbrev="XCCDF v1.2">Specification for the Extensible Configuration
Checklist Description Format (XCCDF) Version 1.2</title>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Charles Schmidt" surname="Schmidt" initials="C."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<author fullname="Neal Ziring" surname="Ziring" initials="N."/>
<date month="March" year="2013"/>
</front>
<seriesInfo name="NISTIR" value="7275r4"/>
</reference>
<reference anchor="NISTIR-7695"
target="http://csrc.nist.gov/publications/nistir/ir7695/NISTIR-7695-CPE-Naming.pdf">
<front>
<title abbrev="CPE Naming v2.3">Common Platform Enumeration: Naming
Specification Version 2.3</title>
<author fullname="Brant A. Cheikes" surname="Cheikes" initials="B.A."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<date month="August" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7695"/>
</reference>
<reference anchor="NISTIR-7696"
target="http://csrc.nist.gov/publications/nistir/ir7696/NISTIR-7696-CPE-Matching.pdf">
<front>
<title abbrev="CPE Name Matching v2.3">Common Platform Enumeration: Name
Matching Specification Version 2.3</title>
<author fullname="Mary C. Parmelee" surname="Parmelee" initials="M.C."/>
<author fullname="Harold Booth" surname="Booth" initials="H."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<date month="August" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7696"/>
</reference>
<reference anchor="NISTIR-7697"
target="http://csrc.nist.gov/publications/nistir/ir7697/NISTIR-7697-CPE-Dictionary.pdf">
<front>
<title abbrev="CPE Dictionary v2.3">Common Platform Enumeration: Dictionary
Specification Version 2.3</title>
<author fullname="Paul Cichonski" surname="Cichonski" initials="P."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<date month="August" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7697"/>
</reference>
<reference anchor="NISTIR-7698"
target="http://csrc.nist.gov/publications/nistir/ir7698/NISTIR-7698-CPE-Language.pdf">
<front>
<title abbrev="CPE Dictionary v2.3">Common Platform Enumeration: Applicability
Language Specification Version 2.3</title>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<author fullname="Paul Cichonski" surname="Cichonski" initials="P."/>
<author fullname="Karen Scarfone" surname="Scarfone" initials="K."/>
<date month="August" year="2011"/>
</front>
<seriesInfo name="NISTIR" value="7698"/>
</reference>
<reference anchor="NISTIR-7848"
target="http://csrc.nist.gov/publications/drafts/nistir-7848/draft_nistir_7848.pdf">
<front>
<title abbrev="ASR v1.0">Specification for the Asset Summary Reporting Format
1.0</title>
<author fullname="Mark Davidson" surname="Davidson" initials="M."/>
<author fullname="Adam Halbardier" surname="Halbardier" initials="A."/>
<author fullname="David Waltermire" surname="Waltermire" initials="D."/>
<date month="May" year="2012"/>
</front>
<seriesInfo name="NISTIR" value="7848"/>
</reference>
<reference anchor="ISO.19770-2">
<front>
<title abbrev="ISO/IEC 19770-2:2009">Information technology -- Software asset
management -- Part 2: Software identification tag</title>
<author/>
<date year="2009"/>
</front>
<seriesInfo name="ISO/IEC" value="19770-2"/>
</reference>
<reference anchor="ISO.18180"
target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c061713_ISO_IEC_18180_2013.zip">
<front>
<title abbrev="ISO/IEC 18180:2013">Information technology -- Specification for
the Extensible Configuration Checklist Description Format (XCCDF) Version
1.2</title>
<author/>
<date year="2013"/>
</front>
<seriesInfo name="ISO/IEC" value="18180"/>
</reference>
<reference anchor="CCE" target="http://nvd.nist.gov/CCE/">
<front>
<title>Common Configuration Enumeration</title>
<author>
<organization abbrev="NIST">The National Institute of Standards and
Technology</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="CCI" target="http://iase.disa.mil/cci/">
<front>
<title>Control Correlation Identifier</title>
<author>
<organization abbrev="DISA">United States Department of Defense Defense
Information Systems Agency</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="OVAL-LANGUAGE"
target="https://oval.mitre.org/language/version5.10.1/">
<front>
<title>The OVAL Language Specification version 5.10.1</title>
<author fullname="Jonathan Baker" surname="Baker" initials="J.">
<organization>The MITRE Corporation</organization>
</author>
<author fullname="Matthew Hansbury" surname="Hansbury" initials="M.">
<organization>The MITRE Corporation</organization>
</author>
<author fullname="Daniel Haynes" surname="Haynes" initials="D.">
<organization>The MITRE Corporation</organization>
</author>
<date day="20" month="January" year="2012"/>
</front>
</reference>
<reference anchor="CVE-WEBSITE" target="http://cve.mitre.org/about/">
<front>
<title>Common Vulnerabilities and Exposures</title>
<author>
<organization abbrev="MITRE">The MITRE Corporation</organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="UML">
<front>
<title abbrev="UML v2.4.1">"Unified Modeling Language TM (UML (R))", Version 2.4.1</title>
<author>
<organization abbrev="OMG">Object Management Group</organization>
</author>
<date month="August" year="2011"/>
</front>
</reference>
<reference anchor="TNC-Architecture">
<front>
<title abbrev="TNC Architecture v1.5">"TNC Architecture", Specification Version 1.5</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2012"/>
</front>
</reference>
<reference anchor="TNC-IF-M-TLV-Binding">
<front>
<title abbrev="TNC IF-M: TLV Binding v1.0">"TNC IF-M: TLV Binding", Specification Version 1.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2014"/>
</front>
</reference>
<reference anchor="TNC-IF-TNCCS-TLV-Binding">
<front>
<title abbrev="TNC IF-TNCCS: TLV Binding v2.0">"TNC IF-TNCCS: TLV Binding", Specification Version 2.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2014"/>
</front>
</reference>
<reference anchor="TNC-IF-T-Tunneled-EAP">
<front>
<title abbrev="TNC IF-T Tunneled EAP v2.0">"TNC IF-T: Protocol Bindings for Tunneled EAP Methods", Specification Version 2.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2014"/>
</front>
</reference>
<reference anchor="TNC-IF-T-TLS">
<front>
<title abbrev="TNC IF-T: TLS Binding v2.0">"TNC IF-T: Binding to TLS", Specification Version 2.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="TNC-IF-MAP-SOAP-Binding">
<front>
<title abbrev="TNC IF-MAP: SOAP Binding v2.2">"TNC IF-MAP Binding for SOAP", Specification Version 2.2</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="March" year="2014"/>
</front>
</reference>
<reference anchor="TNC-IF-MAP-NETSEC-METADATA">
<front>
<title abbrev="TNC IF-MAP: Network Security Metadata v1.1">"TNC IF-MAP Metadata for Network Security", Specification Version 1.1</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2012"/>
</front>
</reference>
<reference anchor="TNC-IF-MAP-ICS-METADATA">
<front>
<title abbrev="TNC IF-MAP: ICS Security Metadata v1.0">"TNC IF-MAP Metadata for ICS Security", Specification Version 1.0</title>
<author>
<organization abbrev="TCG">Trusted Computing Group</organization>
</author>
<date month="May" year="2014"/>
</front>
</reference>
</references>
<section title="Change Log">
<section title="Changes in Revision 01" anchor="changes-in-revision-01">
<t>Renamed "credential" to "identity", following industry usage. A credential includes
proof, such as a key or password. A username or a distinguished name is called an
"identity".</t>
<t>Removed Session, because an endpoint's network activity is not SACM's initial focus</t>
<t>Removed Authorization, for the same reason</t>
<t>Added many-to-many relationship between Hardware Component and Endpoint, for clarity</t>
<t>Added many-to-many relationship between Software Component and Endpoint, for clarity</t>
<t>Added "contains" relationship between Network Interface and Network Interface</t>
<t>Removed relationship between Network Interface and Account. The endpoint knows the identity it used to gain network access. The PDP also knows that. But they probably do not know the account.</t>
<t>Added relationship between Network Interface and Identity. The endpoint and the PDP will typically know the identity.</t>
<t>Made identity-to-account a many-to-one relationship.</t>
</section>
<section title="Changes in Revision 02" anchor="changes-in-revision-02">
<t>Added <xref target="section-identifying-attributes"/>, Identifying Attributes.</t>
<t>Split the figure into <xref target="figure-model-of-endpoint"/> and <xref target="figure-information-elements"/>.</t>
<t>Added <xref target="figure-information-elements-take-2"/>, proposing a triple-store model.</t>
<t>Some editorial cleanup</t>
</section>
<section title="Changes in Revision 03">
<t>Moved <xref target="changes-in-revision-01"/>, <xref target="changes-in-revision-02"/>, and <xref target="mapping-to-sacm-use-cases"/> into the Appendix. Added a reference to it in <xref target="INTRO"/></t>
<t>Added the <xref target="information-model-framework"/> section. Provided notes for the type of information we need to add in this section.</t>
<t>Added the <xref target="information-model-assets"/> 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.</t>
<t>Removed the Provenance of Information Section. SACM is not going to solve provenance rather give organizations enough information to figure it out.</t>
<t>Updated references to the Endpoint Security Posture Assessment: Enterprise Use Cases document to reflect that it was published as an RFC.</t>
<t>Fixed the formatting of a few figures.</t>
<t>Included references to <xref target="RFC3580"/> where RADIUS is mentioned.</t>
</section>
<section title="Changes in Revision 04">
<t>Integrated the IPFIX <xref target="RFC7012"/> syntax
into <xref target="information-model-framework"/>.</t>
<t>Converted many of the existing SACM Information
Elements to the IPFIX syntax.</t>
<t>Included existing IPFIX Information Elements and
datatypes that could likely be reused for SACM in <xref
target="information-model-elements"/> and <xref
target="information-model-framework"/>
respectively.</t>
<t>Removed the sections related to reports as described
in https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/30.</t>
<t>Cleaned up other text throughout the document.</t>
</section>
</section>
<section title="Mapping to SACM Use Cases" anchor="mapping-to-sacm-use-cases">
<t>TODO: revise</t>
<t>(wandw)This information model directly corresponds to all four use cases defined in the
SACM Use Cases draft <xref target="RFC7632"/>. It uses these use
cases in coordination to achieve a small set of well-defined tasks.</t>
<t>Sections [removed] thru [removed] address each of the process areas. For each
process area, a "Process Area Description" sub-section represent an end state
that is consistent with all the General Requirements and many of the Use Case
Requirements identified in the requirements draft <xref
target="I-D.ietf-sacm-requirements"/>.</t>
<t>The management process areas and supporting operations defined in this memo
directly support REQ004 Endpoint Discovery; REQ005-006 Attribute and Information
Based Queries, and REQ0007 Asynchronous Publication.</t>
<t>In addition, the operations that defined for each business process in this memo
directly correlate with the typical workflow identified in the SACM Use Case
document.(/wandw)</t>
</section>
<section title="Security Automation with TNC IF-MAP">
<section title="What is Trusted Network Connect?">
<t>Trusted Network Connect (TNC) is a vendor-neutral open architecture <xref
target="TNC-Architecture"/> and a set of open standards for network security
developed by the Trusted Computing Group (TCG). TNC standards integrate security
components across end user systems, servers, and network infrastructure devices
into an intelligent, responsive, coordinated defense. TNC standards have been
widely adopted by vendors and customers; the TNC endpoint assessment protocols
<xref target="TNC-IF-M-TLV-Binding"/><xref target="TNC-IF-TNCCS-TLV-Binding"
/><xref target="TNC-IF-T-Tunneled-EAP"/><xref target="TNC-IF-T-TLS"/> were
used as the base for the IETF NEA RFCs <xref target="RFC5792"/><xref
target="RFC5793"/><xref target="RFC7171"/><xref target="RFC6876"/>.</t>
<t>Traditional information security architectures have separate silos for endpoint
security, network security, server security, physical security, etc. The TNC
architecture enables the integration and categorization of security telemetry
sources via the information model contained in its Interface for Metadata Access
Points (IF-MAP) <xref target="TNC-IF-MAP-SOAP-Binding"/>. IF-MAP provides a
query-able repository of security telemetry that may be used for storage or
retrieval of such data by multiple types of security systems and endpoints on a
vendor-neutral basis. The information model underlying the IF-MAP repository
covers, directly or indirectly, all of the security information types required
to serve SACM use-cases.</t>
</section>
<section title="What is TNC IF-MAP?">
<t>IF-MAP provides a standard client-server protocol for MAP clients to exchange
security-relevant information via database server known as the Metadata Access
Point or MAP. The data (known as "metadata") stored in the MAP is XML data. Each
piece of metadata is tagged with a metadata type that indicates the meaning of
the metadata and identifies an XML schema for it. Due to the XML language, the
set of metadata types is easily extensible.</t>
<t>The MAP is a graph database, not a relational database. Metadata can be
associated with an identifier (e.g. the email address "user@example.com") or
with a link between two identifiers (e.g. the link between MAC address
00:11:22:33:44:55 and IPv4 address 192.0.2.1) where the link defines an
association (for example: a relation or state) between the identifiers. These
links between pairs of identifiers create an ad hoc graph of relationships
between identifiers. The emergent structure of this graph reflects a
continuously evolving knowledge base of security-related metadata that is shared
between various providers and consumers.</t>
</section>
<section title="What is the TNC Information Model?">
<t>The TNC Information Model underlying IF-MAP relies on the graph database
architecture to enable a (potentially distributed) MAP service to act as a
shared clearinghouse for information that infrastructure devices can act upon.
The IF-MAP operations and metadata schema specifications (TNC IF-MAP Binding for
SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/>, TNC IF-MAP Metadata for Network
Security <xref target="TNC-IF-MAP-NETSEC-METADATA"/>, and TNC IF-MAP Metadata
for ICS Security <xref target="TNC-IF-MAP-ICS-METADATA"/>) define an extensible
set of identifiers and data types.</t>
<t>Each IF-MAP client may interact with the IF-MAP graph data store through three
fundamental types of operation requests:<list style="symbols">
<t>Publish, which may create, modify, or delete metadata associated with one
or more identifiers and/or links in the graph</t>
<t>Search, which retrieves a selected sub-graph according to a set of search
criteria</t>
<t>Subscribe, which allows a client to manage a set of search commands which
asynchronously return selected sub-graphs when changes to that sub-graph
are made by other IF-MAP clients</t>
</list></t>
<t>The reader is invited to review the existing IF-MAP specification <xref
target="TNC-IF-MAP-SOAP-Binding"/> for more details on the above graph data
store operation requests and their associated arguments.</t>
<t>The current IF-MAP specification provides a SOAP <xref
target="W3C.REC-soap12-part1-20070427"/> binding for the above operations,
as well as associated SOAP operations for managing sessions, error handling,
etc.</t>
</section>
</section>
<section title="Text for Possible Inclusion in the Terminology Draft">
<section anchor="im-terminology" title="Terms and Definitions">
<t>This section describes terms that have been defined by other RFCs and Internet
Drafts, as well as new terms introduced in this document. </t>
<section anchor="im-terminology-pre-defined" title="Pre-defined and Modified Terms">
<t>This section contains pre-defined terms that are sourced from other IETF RFCs and
Internet Drafts. Descriptions of terms in this section will reference the
original source of the term and will provide additional specific context for the
use of each term in SACM. For sake of brevity, terms from <xref
target="I-D.ietf-sacm-terminology"/> are not repeated here unless the
original meaning has been changed in this document.</t>
<t><list hangIndent="8" style="hanging">
<t hangText="Asset">For this Information Model it is necessary to change the
scope of the definition of asset from the one provided in <xref
target="I-D.ietf-sacm-terminology"/>. Originally defined in <xref
target="RFC4949"/> and referenced in <xref
target="I-D.ietf-sacm-terminology"/> as "a system resource that is
(a) required to be protected by an information system's security policy,
(b) intended to be protected by a countermeasure, or (c) required for a
system's mission." This definition generally relates to an "IT Asset",
which in the context of this document is overly limiting. For use in
this document, a broader definition of the term is needed to represent
non-IT asset types as well.</t>
<t>In <xref target="NISTIR-7693"/> an asset is defined as "anything that has
value to an organization, including, but not limited to, another
organization, person, computing device, information technology (IT)
system, IT network, IT circuit, software (both an installed instance and
a physical instance), virtual computing platform (common in cloud and
virtualized computing), and related hardware (e.g., locks, cabinets,
keyboards)." This definition aligns better with common dictionary
definitions of the term and better fits the needs of this document. </t>
<t/>
</list></t>
</section>
<section anchor="im-terminology-new" title="New Terms">
<t><list hangIndent="8" style="hanging">
<t hangText="IT Asset">Originally defined in <xref target="RFC4949"/> as "a
system resource that is (a) required to be protected by an information
system's security policy, (b) intended to be protected by a
countermeasure, or (c) required for a system's mission."</t>
<t hangText="Security Content Automation Protocol (SCAP)">According to
SP800-126, SCAP, pronounced "ess-cap", is "a suite of specifications
that standardize the format and nomenclature by which software flaw and
security configuration information is communicated, both to machines and
humans." SP800-117 revision 1 <xref target="SP800-117"/> provides a
general overview of SCAP 1.2. The 11 specifications that comprise SCAP
1.2 are synthesized by a master specification, SP800-126 revision 2
<xref target="SP800-126"/>, that addresses integration of the
specifications into a coherent whole. The use of "protocol" in its name
is a misnomer, as SCAP defines only data models. SCAP has been adopted
by a number of operating system and security tool vendors.</t>
</list></t>
</section>
</section>
</section>
<section title="Text for Possible Inclusion in the Architecture or Use Cases">
<section title="Introduction">
<!-- TODO: This belongs in a SACM overview or architecture document, not here. -->
<t>The posture of an endpoint is the status of the endpoint with respect to the
security policies and risk models of the organization.</t>
<t>A system administrator needs to be able to determine which
elements of an endpoint have a security problem and which do not conform
the organization's security policies. The CIO needs to be able to determine whether
endpoints have security postures that conform to the organization's policies to
ensure that the organization is complying with its fiduciary and regulatory
responsibilities. The regulator or auditor needs to be able to assess the level of
due diligence being achieved by an organization to ensure that all regulations and
due diligence expectations are being met. The operator needs to understand which
assets have deviated from organizational policies so that those assets can be
remedied.</t>
<t>Operators will focus on which endpoints are composed of specific assets with
problems. CIO and auditors need a characterization of how an organization is
performing as a whole to manage the posture of its endpoints. All of these actors
need deployed capabilities that implement security automation standards in the form
of data formats, interfaces, and protocols to be able to assess, in a timely and
secure fashion, all assets on all endpoints within their enterprise. This
information model provides a basis to identify the desirable characteristics of data
models to support these scenarios. Other SACM specifications, such as the SACM
Architecture, will describe the potential components of an interoperable system
solution based on the SACM information model to address the requirements for
scalability, timeliness, and security.</t>
</section>
<section title="Core Principles">
<t>This information model is built on the following core principles:<list style="symbols">
<t>Collection and Evaluation are separate tasks.</t>
<t>Collection and Evaluation can be performed on the endpoint, at a local
server that communicates directly with the endpoint, or based on data
queried from a back end data store that does not communicate directly
with any endpoints.</t>
<t>Every entity (human or machine) that notifies, queries, or responds to
any guidance, collection, or evaluator must have a way of
identifying itself and/or presenting credentials. Authentication is a
key step in all of the processes, and while needed to support the
business processes, information needs to support authentication are not
highlighted in this information model. There is already a large amount
of existing work that defines information needs for authentication.</t>
<t>Policies are reflected in guidance for collection, evaluation, and
reporting.</t>
<t>Guidance will often be generated by humans or through the use of
transformations on existing automation data. In some cases, guidance
will be generated dynamically based on shared information or current
operational needs. As guidance is created it will be published to an
appropriate guidance data store allowing guidance to be managed in and
retrieved from convenient locations.</t>
<t>Operators of a continuous monitoring or security automation system will
need to make decisions when defining policies about what guidance to use
or reference. The guidance used may be directly associated with policy
or may be queried dynamically based on associated metadata.</t>
<t>Guidance can be gathered from multiple data stores. It may be retrieved
at the point of use or may be packaged and forwarded for later use.
Guidance may be retrieved in event of a collection or evaluation trigger
or it may be gathered ahead of time and stored locally for use/reference
during collection and evaluation activities.</t>
</list></t>
</section>
<section title="Architecture Assumptions">
<t>This information model will focus on WHAT information needs to be exchanged to
support the business process areas. The architecture document is the best place
to represent the HOW and the WHERE this information is used. In an effort to
ensure that the data models derived from this information model scale to the
architecture, four core architectural components need to be defined. They are
producers, consumers, capabilities, and repositories. These elements are defined
as follows:<list style="symbols">
<t>Producers (e.g., Evaluation Producer) collect, aggregate, and/or derive
information items and provide them to consumers. For this model there
are Collection, Evaluation, and Results Producers. There may or may not
be Guidance Producers.</t>
<t>Consumers (e.g., Collection Consumer) request and/or receive information
items from producers for their own use. For this model there are
Collection, Evaluation, and Results Consumers. There may or may not be
Guidance Consumers.</t>
<!-- Of course there are Guidance Consumers. -->
<t>Capabilities (e.g., Posture Evaluation Capability) take the input from
one or more producers and perform some function on or with that
information. For this model there are Collection Guidance, Collection,
Evaluation Guidance, Evaluation, Reporting Guidance, and Results
Reporting Capabilities.</t>
<t>Repositories (e.g., Enterprise Repository) store information items that
are input to or output from Capabilities, Producers, and Consumers. For
this model we refer to generic Enterprise and Guidance Repositories.</t>
</list></t>
<t>Information that needs to be communicated by or made available to any of these
components will be specified in each of the business process areas.</t>
<t>In the most trivial example, illustrated in <xref
target="figure-producer-consumer"/>, Consumers either request information
from, or are notified by, Producers.</t>
<figure title="Example Producer/Consumer Interactions"
anchor="figure-producer-consumer">
<artwork><![CDATA[
+----------+ Request +----------+
| <-----------------+ |
| Producer | | Consumer |
| +-----------------> |
+----------+ Response +----------+
+----------+ +----------+
| | Notify | |
| Producer +-----------------> Consumer |
| | | |
+----------+ +----------+
]]></artwork>
</figure>
<t>As illustrated in <xref target="figure-producer-consumer-repository"/>, writing
and querying from data repositories are a way in which this interaction can
occur in an asynchronous fashion.</t>
<figure title="Producer/Consumer Repository Interaction"
anchor="figure-producer-consumer-repository">
<artwork><![CDATA[
+----------+ +----------+
| | | |
| Producer | | Consumer |
| | | |
+-----+----+ +----^-----+
| |
Write | +------------+ | Query
| | | |
+-----> Repository +-------+
| |
+------------+
]]></artwork>
</figure>
<t>To perform an assessment, these elements are chained together. The diagram below
is illustrative of this and process, and is meant to demonstrate WHAT basic
information exchanges need to occur, while trying to maintain flexibility in HOW
and WHERE they occur.</t>
<t>For example:<list style="symbols">
<t>the collection capability can reside on the endpoint or not.</t>
<t>the collection producer can be part of the collection capability or
not.</t>
<t>a repository can be directly associated with a producer and/or an
evaluator or stand on its own.</t>
<t>there can be multiple "levels" of producers and consumers.</t>
</list></t>
<figure title="Producer/Consumer Complex Example"
anchor="figure-producer-consumer-complex-example">
<artwork><![CDATA[
+-------------+
|Evaluation |
+-------------+ |Guidance +--+
|Endpoint | |Capability | |
+-------+ | +-------------+ |
| | | |
| +-------+-----+ +-----v-------+
| Collection | |Evaluation |
+-> Capability +--+--------+ |Capability |
| | |Collection | +-----------+ +----------+
| +------------+Producer | | |---| |
| | | |Collection | |Evaluation|
| | | |Consumer | |Producer |
| +----+------+ +----^------+ +---+------+
++---------+ | | |
|Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | |
|Capability| |Collection | |Producer | |
| | |Consumer |-----| | |
+----------+ +------------+ +------------+ |
| Collection | |
| Repository | |
+------------+ |
|
+--------------+ +---------------+ |
|Evaluation | |Evaluation | |
|Results | |Consumer <-----+
|Producer |-----------| |
+-----+--------+ +---------------+
| |Results Reporting|
| |Capability |
| +------------^----+
| |
+-----v--------+ +----+------+
|Evaluation | |Reporting |
|Results | |Guidance |
|Consumer | |Repository |
+---+----------+ +-----------+ +-------------+
| | Results |
+-----------------------------> Repository |
| |
+-------------+
]]></artwork>
</figure>
<t>This illustrative example in <xref
target="figure-producer-consumer-complex-example"/> provides a set of
information exchanges that need to occur to perform a posture assessment. The
rest of this information model is using this set of exchanges based on these
core architectural components as the basis for determining information
elements.</t>
</section>
</section>
<section title="Text for Possible Inclusion in the Requirements Draft">
<section title="Problem Statement">
<t>Scalable and sustainable collection, expression, and evaluation of endpoint
information is foundational to SACM's objectives. To secure and defend one's network
one must reliably determine what devices are on the network, how those devices are
configured from a hardware perspective, what software products are installed on
those devices, and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely, consistent, and
automated manner to perform endpoint posture assessments.</t>
</section>
<section title="Problem Scope">
<t>The goal of this iteration of the information model is to define the
information needs for an organization to effectively monitor the endpoints
operating on their network, the software installed on those endpoints, and the
configuration of that software. Once we have those three business processes in
place, we can identify vulnerable endpoints in a very efficient manner.</t>
<t>The four business process areas represent a large set of tasks that support
endpoint posture assessment. In an effort to address the most basic and
foundational needs, we have also narrowed down the scope inside of each of the
business processes to a set of defined tasks that strive to achieve specific
results in the operational environment and the organization. These tasks
are:<list style="numbers">
<t>Define the assets. This is what we want to know about an asset. For
instance, organizations will want to know what software is installed and
its many critical security attributes such as patch level.</t>
<t>Resolve what assets compose an endpoint. This requires
populating the data elements and attributes needed to exchange
information pertaining to the assets composing an endpoint.</t>
<t>Express what expected values for the data elements and attributes need to
be evaluated against the actual collected instances of asset data. This
is how an organization can express its policy for an acceptable data
element or attribute value. A system administrator can also identify
specific data elements and attributes that represent problems, such as
vulnerabilities, that need to be detected on an endpoint.</t>
<t>Evaluate the collected instances of the asset data against those
expressed in the policy.</t>
<t>Report the results of the evaluation.</t>
</list></t>
</section>
</section>
<section title="Text With No Clear Home Yet">
<section title="Operations">
<t>Operations that may be carried out the proposed SACM Information Model are:<list
style="symbols">
<t>Publish data: Security information is made available in the information
model when a component publishes data to it.</t>
<t>Subscribe to data: A component seeking to consume an on-going stream of
security information "subscribes" to such data from the information
model.</t>
<t>Query: This operation enables a component to request a specific set of
security data regarding a specific asset (such as a specific user
endpoint).</t>
</list></t>
<t>The subscribe capability will allow SACM components to monitor for selected
security-related changes in the graph data store without incurring the
performance penalties associated with polling for such changes.</t>
<section title="Generalized Workflow">
<t>The proposed SACM Information Model would be most commonly used with a
suitable transport protocol for collecting and distributing security data
across appropriate network platforms and endpoints. The information model is
transport agnostic and can be used with its native transport provided by
IF-MAP or by other data transport protocols such as the recently proposed
XMPP-Grid.</t>
<t><list style="numbers">
<t>A Posture Assessment Information Consumer (Consumer) establishes
connectivity and authorization with the transport fabric.</t>
<t>A Posture Assessment Information Provider (Provider) with a source of
security data requests connection to the transport fabric.</t>
<t>Transport fabric authenticates and establishes authorized privileges
(e.g. privilege to publish and/or subscribe to security data) for
the requesting components.</t>
<t>Components may either publish security data, subscribe to security
data, query for security data, or any combination of these
operations.</t>
</list></t>
<t>Any component sharing information - either as Provider or Consumer - may do
so on a one-to-one, one-to-many and/or many-to-many meshed basis.</t>
</section>
</section>
<section title="From Information Needs to Information Elements">
<t>The previous sections highlighted information needs for a set of management process
areas that use posture assessment to achieve organizational security goals. A single
information need may be made up of multiple information elements. Some information
elements may be required for two different process areas, resulting in two different
requirements. In an effort to support the main idea of collect once and reuse the
data to support multiple processes, we try to define a singular set of information
elements that will support all the associated information needs.</t>
</section>
<section title="Information Model Elements" anchor="im-elements">
<t>TODO: Kim to pull up relevant content into section 4 / Elements</t>
<t>Traditionally, one would use the SACM architecture to define interfaces that required
information exchanges. Identified information elements would then be based on those
exchanges. Because the SACM architecture document is still in the personal draft
stage, this information model uses a different approach to the identification of
information elements. First it lists the four main endpoint posture assessment
activities. Then it identifies management process areas that use endpoint posture
assessment to achieve organizational security objectives. These process areas were
then broken down into operations that mirrored the typical workflow from the SACM
Use Cases draft <xref target="RFC7632"/>. These operations identify
architectural components and their information needs. In this section, information
elements derived from those information needs are mapped back to the four main
activities listed above.</t>
<t>The original liaison statement <xref target="IM-LIAISON-STATEMENT-NIST"/> requested
contributions for the SACM information model in the four areas described below.
Based on the capabilities defined previously in this document, the requested areas
alone do not provide a sufficient enough categorization of the necessary information
model elements. The following sub-sections directly address the requested areas as
follows:<list style="numbers">
<t>Endpoint Identification<list style="letters">
<t><xref target="IM-ELEMENTS-ASSET-IDENTIFIERS"/>
<xref target="IM-ELEMENTS-ASSET-IDENTIFIERS" format="title"/>:
Describes identification of many different asset types including
endpoints.</t>
</list>
</t>
<t>Endpoint Characterization <list style="letters">
<t><xref target="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION"/>
<xref target="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION" format="title"
/>: This directly maps to the requested area.</t>
</list>
</t>
<t>Endpoint Attribute Expression/Representation <list style="letters">
<t><xref target="IM-ELEMENTS-PA-EXPRESSION"/>
<xref target="IM-ELEMENTS-PA-EXPRESSION" format="title"/>: This
corresponds to the first part of "Endpoint Attribute
Expression/Representation."</t>
<t><xref target="IM-ELEMENTS-ACTUAL-VALUE"/>
<xref target="IM-ELEMENTS-ACTUAL-VALUE" format="title"/>: This
corresponds to the second part of "Endpoint Attribute
Expression/Representation."</t>
</list>
</t>
<t>Policy evaluation expression and results reporting <list style="letters">
<t><xref target="IM-ELEMENTS-EVALUATION-GUIDANCE"/>
<xref target="IM-ELEMENTS-EVALUATION-GUIDANCE" format="title"/>:
This corresponds to the first part of "Policy evaluation expression
and results reporting."</t>
<t><xref target="IM-ELEMENTS-EVAL-REPORTING"/>
<xref target="IM-ELEMENTS-EVAL-REPORTING" format="title"/>:
corresponds to the second part of "Policy evaluation expression and
results reporting."</t>
</list>
</t>
</list></t>
<t>Additionally, <xref target="IM-ELEMENTS-OTHER-IDENTIFIERS"/>
<xref target="IM-ELEMENTS-OTHER-IDENTIFIERS" format="title"/>: describes other
important identification concepts that were not directly requested by the liaison
statement.</t>
<t>Per the liaison statement, each subsection references related work that provides a
basis for potential data models. Some analysis is also included for each area of
related work on how directly applicable the work is to the SACM efforts. In general,
much of the related work does not fully address the general or use case-based
requirements for SACM, but they do contain some parts that can be used as the basis
for data models that correspond to the information model elements. In these cases
additional work will be required by the WG to adapt the specification. In some
cases, existing work can largely be used in an unmodified fashion. This is also
indicated in the analysis. Due to time constraints, the work in this section is very
biased to previous work supported by the authors and does not reflect a
comprehensive listing. An attempt has been made where possible to reference existing
IETF work. Additional research and discussion is needed to include other related
work in standards and technology communities that could and should be listed here.
The authors intend to continue this work in subsequent revisions of this draft.</t>
<t>Where possible when selecting and developing data models in support of these
information model elements, extension points and IANA registries SHOULD be used to
provide for extensibility which will allow for future data models to be
addressed.</t>
<section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS" title="Asset Identifiers">
<t>In this context an "asset" refers to "anything that has value to an organization"
(see <xref target="NISTIR-7693"/>). This use of the term "asset" is broader than
the current definition in <xref target="I-D.ietf-sacm-terminology"/>. To support
SACM use cases, a number of different asset types will need to be addressed. For
each type of asset, one or more type of asset identifier will be needed for use
in establishing contextual relationships within the SACM information model. The
following asset types are referenced or implied by the SACM use cases: <list
hangIndent="8" style="hanging">
<t hangText="Endpoint:">Identifies an individual endpoint for which posture
is collected and evaluated.</t>
<t hangText="Hardware:">Identifies a given type of hardware that may be
installed within an endpoint.</t>
<t hangText="Software:">Identifies a given type of software that may be
installed within an endpoint.</t>
<t hangText="Network:">Identifies a network for which a given endpoint may
be connected or request a connection to.</t>
<t hangText="Organization:">Identifies an organizational unit.</t>
<t hangText="Person:">Identifies an individual, often within an
organizational context.</t>
</list></t>
<section title="Related Work" toc="exclude">
<section title="Asset Identification" anchor="AI-BACKGROUND" toc="exclude">
<t>The Asset Identification specification <xref target="NISTIR-7693"/> is an
XML-based data model that "provides the necessary constructs to uniquely
identify assets based on known identifiers and/or known information
about the assets." Asset identification plays an important role in an
organization's ability to quickly correlate different sets of
information about assets. The Asset Identification specification
provides the necessary constructs to uniquely identify assets based on
known identifiers and/or known information about the assets. Asset
Identification provides a relatively flat and extensible model for
capturing the identifying information about a one or more assets, and
also provides a way to represent relationships between assets.</t>
<t>The model is organized using an inheritance hierarchy of specialized
asset types/classes (see <xref target="figure-ai-class-hierarchy"/>),
providing for extension at any level of abstraction. For a given asset
type, a number of properties are defined that provide for capturing
identifying characteristics and the referencing of namespace qualified
asset identifiers, called "synthetic IDs."</t>
<t/>
<figure anchor="figure-ai-class-hierarchy"
title="Asset Identification Class Hierarchy">
<preamble>The following figure illustrates the class hierarchy defined
by the Asset Identification specification.</preamble>
<artwork><![CDATA[
asset
+-it-asset
| +-circuit
| +-computing-device
| +-database
| +-network
| +-service
| +-software
| +-system
| +-website
+-data
+-organization
+-person
]]></artwork>
</figure>
<texttable anchor="table-sacm-to-ai"
title="Mapping of SACM to Asset Identification Asset Types" style="all">
<preamble>This table presents a mapping of notional SACM asset types to
those asset types provided by the Asset Identification
specification.</preamble>
<ttcol>SACM Asset Type</ttcol>
<ttcol>Asset Identification Type</ttcol>
<ttcol>Notes</ttcol>
<c>Endpoint</c>
<c>computing-device</c>
<c>This is not a direct mapping since a computing device is not required
to have network-connectivity. Extension will be needed to define a
directly aligned endpoint asset type.</c>
<c>Hardware</c>
<c>Not Applicable</c>
<c>The concept of hardware is not addressed by the asset identification
specification. An extension can be created based on the it-asset
class to address this concept.</c>
<c>Software</c>
<c>software</c>
<c>Direct mapping.</c>
<c>Network</c>
<c>network</c>
<c>Direct mapping.</c>
<c>Organization</c>
<c>organization</c>
<c>Direct mapping.</c>
<c>Person</c>
<c>person</c>
<c>Direct mapping.</c>
</texttable>
<t>This specification has been adopted by a number of SCAP validated
products. It can be used to address asset identification and
categorization needs within SACM with minor modification.</t>
</section>
</section>
<section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-ENDPOINT"
title="Endpoint Identification">
<t>An unique name for an endpoint. This is a foundational piece of information
that will enable collected posture attributes to be related to the endpoint
from which they were collected. It is important that this name either be
created from, provide, or be associated with operational information (e.g.,
MAC address, hardware certificate) that is discoverable from the endpoint or
its communications on the network. It is also important to have a method of
endpoint identification that can persist across network sessions to allow
for correlation of collected data over time.</t>
<section title="Related Work" toc="exclude">
<t>The previously introduced asset identification specification (see <xref
target="AI-BACKGROUND"/> provides a basis for endpoint
identification using the "computing-device" class. While the meaning of
this class is broader than the current definition of an endpoint in the
SACM terminology <xref target="I-D.ietf-sacm-terminology"/>, either that
class or an appropriate sub-class extension can be used to capture
identification information for various endpoint types.</t>
</section>
</section>
<section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-SOFTWARE"
title="Software Identification">
<t>A unique name for a unit of installable software. Software names should
generally represent a unique release or installable version of software.
Identification approaches should allow for identification of commercially
available, open source, and organizationally developed custom software. As
new software releases are created, a new software identifier should be
created by the releasing party (e.g., software creator, publisher,
licensor). Such an identifier is useful to:<list style="symbols">
<t>Relate metadata that describes the characteristics of the unit of
software, potentially stored in a repository of software
information. Typically, the software identifier would be used as an
index into such a repository.</t>
<t>Indicate the presence of the software unit on a given endpoint.</t>
<t>To determine what endpoints are the targets for an assessment based
on what software is installed on that endpoint.</t>
<t>Define guidance related to a software unit that represents
collection, evaluation, or other automatable policies.</t>
</list></t>
<t>In general, an extensible method of software identification is needed to
provide for adequate coverage and to address legacy identification
approaches. Use of an IANA registry supporting multiple software
identification methods would be an ideal way forward.</t>
<section title="Related Work" toc="exclude">
<t>While we are not aware of a one-size-fits-all solution for software
identification, there are two existing specifications that should be
considered as part of the solution set. They are described in the
following subsections.</t>
<section title="Common Platform Enumeration">
<section title="Background" anchor="IM-ELEMENTS-CPE-BACKGROUND">
<t>The Common Platform Enumeration (CPE) <xref target="CPE-WEBSITE"
/> is composed of a family of four specification that are
layered to build on lower-level functionality. The following
describes each specification:<list style="numbers">
<t>CPE Naming: A standard machine-readable format <xref
target="NISTIR-7695"/> for encoding names of IT
products and platforms. This defines the notation used
to encode the vendor, software name, edition, version
and other related information for each platform or
product. With the 2.3 version of CPE, a second, more
advanced notation was added to the original
colon-delimited notation for CPE naming.</t>
<t>CPE Matching: A set of procedures <xref
target="NISTIR-7696"/> for comparing names. This
describes how to compare two CPE names to one another.
It describes a logical method that ensures that
automated systems comparing two CPE names would arrive
at the same conclusion.</t>
<t>CPE Applicability Language: An XML-based language <xref
target="NISTIR-7698"/> for constructing
"applicability statements" that combine CPE names with
simple logical operators.</t>
<t>CPE Dictionary: An XML-based catalog format <xref
target="NISTIR-7697"/> that enumerates CPE Names and
associated metadata. It details how to encode the
information found in a CPE Dictionary, thereby allowing
multiple organizations to maintain compatible CPE
Dictionaries.</t>
</list></t>
<t>The primary use case of CPE is for exchanging software inventory
data, as it allows the usage of unique names to identify
software platforms and products present on an endpoint. The NIST
currently maintains and updates a dictionary of all agreed upon
CPE names, and is responsible for ongoing maintenance of the
standard. Many of the names in the CPE dictionary have been
provided by vendors and other 3rd-parties.</t>
<t>While the effort has seen wide adoption, most notably within the
US Government, a number of critical flaws have been identified.
The most critical issues associated with the effort are:<list
style="symbols">
<t>Because there is no requirement for vendors to publish
their own, official CPE names, CPE necessarily requires
one or more organizations for curation. This centralized
curation requirement ensures that the effort has
difficulty scaling.</t>
<t>Not enough primary source vendors provide platform and
product naming information. As a result, this pushes too
much of the effort out onto third-party groups and
non-authoritative organizations. This exacerbates the
ambiguity in names used for identical platforms and
products and further reduces the utility of the
effort.</t>
</list></t>
</section>
<section title="Applicability to Software Identification">
<t>The Common Platform Enumeration (CPE) Naming specification
version 2.3 defines a scheme for human-readable standardized
identifiers of hardware and software products.</t>
<t>CPE names are the identifier format for software and hardware
products used in SCAP 1.2 and is currently adopted by a number
of SCAP product vendors.</t>
<t>CPE names can be directly referenced in the asset identification
software class (see <xref target="AI-BACKGROUND"/>.)</t>
<t>Although relevant, CPE has an unsustainable maintenance "tail"
due to the need for centralized curation and naming-consistency
enforcement. Its mention in this document is to support the
historic inclusion of CPE as part of SCAP and implementation of
this specification in a number of security processes and
products. Going forward, software identification (SWID) tags are
recommended as a replacement for CPE. To this end, work has been
started to align both efforts to provide translation for
software units identified using SWID tags to CPE Names. This
translation would allow tools that currently use CPE-based
identifiers to map to SWID identifiers during a transition
period.</t>
</section>
</section>
<section title="Software Identification (SWID) Tags"
anchor="SWID-BACKGROUND">
<t>The software identification tag specification <xref
target="ISO.19770-2"/> is an XML-based data model that is used
to describe a unit of installable software. A SWID tag contains data
elements that:<list style="symbols">
<t>Identify a specific unit of installable software,</t>
<t>Enable categorization of the software (e.g., edition,
bundle),</t>
<t>Identification and hashing of software artifacts (e.g.,
executables, shared libraries),</t>
<t>References to related software and dependencies, and</t>
<t>Inclusion of extensible metadata.</t>
</list></t>
<t>SWID tags can be associated with software installation media,
installed software, software updates (e.g., service packs, patches,
hotfixes), and redistributable components. SWID tags also provide
for a mechanism to relate these concepts to each other. For example,
installed software can be related back to the original installation
media, patches can be related to the software that they patch, and
software dependencies can be described for required redistributable
components. SWID tags are ideally created at build-time by the
software creator, publisher or licensor; are bundled with software
installers; and are deployed to an endpoint during software
installation.</t>
<t>SWID tags should be considered for two primary uses:<list
style="numbers">
<t>As the data format for exchanging descriptive information
about software products, and</t>
<t>As the source of unique identifiers for installed
software.</t>
</list></t>
<t>In addition to usage for software identification, a SWID tag can
provide the necessary data needed to target guidance based on
included metadata, and to support verification of installed software
and software media using cryptographic hashes. This added
information increases the value of using SWID tags as part of the
larger security automation and continuous monitoring solution
space.</t>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-ASSET-IDENTIFIERS-HARDWARE"
title="Hardware Identification">
<t>Due to the time constraints, research into information elements and related
work for identifying hardware is not included in this revision of the
information model.</t>
</section>
</section>
<section anchor="IM-ELEMENTS-OTHER-IDENTIFIERS" title="Other Identifiers">
<t>In addition to identifying core asset types, it is also necessary to have stable,
globally unique identifiers to represent other core concepts pertaining to
posture attribute collection and evaluation. The concept of "global uniqueness"
ensures that identifiers provided by multiple organization do not collide. This
may be handled by a number of different mechanisms (e.g., use of
namespaces).</t>
<section anchor="IM-ELEMENTS-OTHER-IDENTIFIERS-PLATFORM-CI"
title="Platform Configuration Item Identifier">
<t>A name for a low-level, platform-dependent configuration mechanism as
determined by the authoritative primary source vendor. New identifiers will
be created when the source vendor makes changes to the underlying platform
capabilities (e.g., adding new settings, replacing old settings with new
settings). When created each identifier should remain consistent with
regards to what it represents. Generally, a change in meaning would
constitute the creation of a new identifier.</t>
<t>For example, if the configuration item is for "automatic execution of code",
then the platform vendor would name the low-level mechanism for their
platform (e.g., autorun for mounted media).</t>
<section title="Related Work" toc="exclude">
<section title="Common Configuration Enumeration">
<t>The Common Configuration Enumeration (CCE) <xref target="CCE"/> is an
effort managed by NIST. CCE provides a unique identifier for
platform-specific configuration items that facilitates fast and
accurate correlation of configuration items across multiple
information sources and tools. CCE does this by providing an
identifier, a human readable description of the configuration
control, parameters needed to implement the configuration control,
various technical mechanisms that can be used to implement the
configuration control, and references to documentation that describe
the configuration control in more detail.</t>
<t>By vendor request, NIST issues new blocks of CCE identifiers. Vendors
then populate the required fields and provided the details back to
NIST for publication in the "CCE List", a consolidated listing of
assigned CCE identifiers and associated data. Many vendors also
include references to these identifiers in web pages, SCAP content,
and prose configuration guides they produce.</t>
<t>CCE the identifier format for platform specific configuration items
in SCAP and is currently adopted by a number of SCAP product
vendors.</t>
<t>While CCE is largely supported as a crowd-sourced effort, it does
rely on a central point of coordination for assignment of new CCE
identifiers. This approach to assignment requires a single
organization, currently NIST, to manage allocations of CCE
identifiers which doesn't scale well and introduces sustainability
challenges for large volumes of identifier assignment. If this
approach is used going forward by SACM, a namespaced approach is
recommended for identifier assignment that allows vendors to manage
their own namespace of CCE identifiers. This change would require
additional work to specify and implement.</t>
</section>
<section title="Open Vulnerability and Assessment Language">
<section anchor="IM-ELEMENTS-OVAL-BACKGROUND" title="Background">
<t>The Open Vulnerability and Assessment Language (OVAL®) is an
XML schema-based data model developed as part of a
public-private information security community effort to
standardize how to assess and report upon the security posture
of endpoints. OVAL provides an established framework for making
assertions about an endpoint's posture by standardizing the
three main steps of the assessment process:<list style="numbers">
<t>representing the current endpoint posture;</t>
<t>analyzing the endpoint for the presence of the specified
posture; and</t>
<t>representing the results of the assessment.</t>
</list></t>
<t>OVAL facilitates collaboration and information sharing among the
information security community and interoperability among tools.
OVAL is used internationally and has been implemented by a
number of operating system and security tools vendors.</t>
<figure anchor="figure-oval-data-model" title="The OVAL Data Model">
<preamble>The following figure illustrates the OVAL data
model.</preamble>
<artwork><![CDATA[
+------------+
+-----------------+ | Variables |
| Common <---+ |
+--------> | +------------+
| | | +------------+
| | <---+ Directives |
| +--------^----^---+ | |
| | | +--------+---+
| | +-----+ |
| | | |
| +--------+--------+ | |
| | System | | |
| | Characteristics | | |
+------+------+ | | | +--------v---+
| Definitions | | | | | Results |
| | +--------^--------+ +-+ |
| | | | |
| | +------------+ |
+------^------+ +-------+----+
| |
+--------------------------------------+
]]></artwork>
<postamble>Note: The direction of the arrows indicate a model
dependency</postamble>
</figure>
<t>The OVAL data model <xref target="OVAL-LANGUAGE"/>, visualized in
<xref target="figure-oval-data-model"/>, is composed of a
number of different components. The components are:<list
style="symbols">
<t>Common: Constructs, enumerations, and identifier formats
that are used throughout the other model components.</t>
<t>Definitions: Constructs that describe assertions about
system state. This component also includes constructs
for internal variable creation and manipulation through
a variety of functions. The core elements are:<list
style="symbols">
<t>Definition: A collection of logical statements
that are combined to form an assertion based on
endpoint state.</t>
<t>Test(platform specific): A generalized construct
that is extended in platform schema to describe
the evaluation of expected against actual
state.</t>
<t>Object(platform specific): A generalized
construct that is extended in platform schema to
describe a collectable aspect of endpoint
posture.</t>
<t>State(platform specific): A generalized construct
that is extended in platform schema to describe a
set of criteria for evaluating posture
attributes.</t>
</list></t>
<t>Variables: Constructs that allow for the parameterization
of the elements used in the Definitions component based
on externally provided values.</t>
<t>System Characteristics: Constructs that represent
collected posture from one or more endpoints. This
element may be embedded with the Results component, or
may be exchanged separately to allow for separate
collection and evaluation. The core elements of this
component are:<list style="symbols">
<t>CollectedObject: Provides a mapping of collected
Items to elements defined in the Definitions
component.</t>
<t>Item(platform specific): A generalized construct
that is extended in platform schema to describe
specific posture attributes pertaining to an
aspect of endpoint state.</t>
</list></t>
<t>Results: Constructs that represent the result of
evaluating expected state (state elements) against
actual state (item elements). It includes the true/false
evaluation result for each evaluated Definition and
Test. Systems characteristics are embedded as well to
provide low-level posture details.</t>
<t>Directives: Constructs that enable result reporting
detail to be declared, allowing for result production to be
customized.</t>
</list></t>
<t>End-user organizations and vendors create assessment guidance
using OVAL by creating XML instances based on the XML schema
implementation of the OVAL Definitions model. The OVAL
Definitions model defines a structured identifier format for
each of the Definition, Test, Object, State, and Item elements.
Each instantiation of these elements in OVAL XML instances are
assigned a unique identifier based on the specific elements
identifier syntax. These XML instances are used by tools that
support OVAL to drive collection and evaluation of endpoint
posture. When posture collection is performed, an OVAL Systems
Characteristics XML instance is generated based on the collected
posture attributes. When this collected posture is evaluated, an
OVAL Result XML instance is generated that contains the results
of the evaluation. In most implementations, the collection and
evaluation is performed at the same time.</t>
<t>Many of the elements in the OVAL model (i.e., Test, Object,
State, Item) are abstract, requiring a platform-specific schema
implementation, called a "Component Model" in OVAL. These
platform schema implementations are where platform specific
posture attributes are defined. For each aspect of platform
posture a specialized OVAL Object, which appears in the OVAL
Definitions model, provides a format for expressing what posture
attribute data to collect from an endpoint through the
specification of a datatype, operation, and value(s) on entities
that uniquely identify a platform configuration item. For
example, a hive, key, and name is used to identify a registry
key on a Windows endpoint. Each specialized OVAL Object has a
corresponding specialized State, which represents the posture
attributes that can be evaluated, and an Item which represents
the specific posture attributes that can be collected.
Additionally, a specialized Test exists that allows collected
Items corresponding to a CollectedObject to be evaluated against
one or more specialized States of the same posture type.</t>
<t>The OVAL language provides a generalized approach suitable for
posture collection and evaluation. While this approach does
provide for a degree of extensibility, there are some concerns
that should be addressed in order to make OVAL a viable basis
for SACM's use. These concerns include:<list style="symbols">
<t>Platform Schema Creation and Maintenance: In OVAL
platform schema, the OVAL data model maintains a tight
binding between the Test, Object, State, and Item
elements used to assess an aspect of endpoint posture.
Creating a new platform schema or adding a new posture
aspect to an existing platform schema can be a very
labor intensive process. Doing so often involves
researching and understanding system APIs and can be
prone to issues with inconsistency within and between
platforms. To simplify platform schema creation and
maintenance, the model needs to be evolved to generalize
the Test, Object, and State elements, requiring only the
definition of an Item representation.</t>
<t>Given an XML instance based on the Definitions model, it
is not clear in the specification how incremental
collection and evaluation can occur. Because of this,
typically, OVAL assessments are performed on a periodic
basis. The OVAL specification needs to be enhanced to
include specifications for performing event-based and
incremental assessment in addition to full periodic
collection.</t>
<t>Defining new functions for manipulating variable values
is current handled in the Definitions schema. This
requires revision to the core language to add new
functions. The OVAL specification needs to be evolved to
provide for greater extensibility in this area, allowing
extension schema to define new functions.</t>
<t>The current process for releasing a new version of OVAL,
bundle releases of the core language with release of
community recognized platform schema. The revision
processes for the core and platform schema need to be
decoupled. Each platform schema should use some
mechanism to declare which core language version it
relies on.</t>
</list></t>
<t>If adopted by SCAM, these issues will need to be addressed as
part of the SCAM engineering work to make OVAL more broadly
adoptable as a general purpose data model for posture collection
and evaluation.</t>
</section>
<section
title="Applicability to Platform Configuration Item Identification">
<t>Each OVAL Object is identified by a globally unique identifier.
This globally unique identifier could be used by the SACM
community to identify platform-specific configuration items and
at the same time serve as collection guidance. If used in this
manner, OVAL Objects would likely need to undergo changes in
order to decouple it from evaluation guidance and to provide
more robust collection capabilities to support the needs of the
SACM community.</t>
</section>
</section>
</section>
</section>
<section title="Configuration Item Identifier">
<t>An identifier for a high-level, platform-independent configuration control.
This identification concept is necessary to allow similar configuration item
concepts to be comparable across platforms. For example, a configuration
item might be created for the minimum password length configuration control,
which may then have a number of different platform-specific configuration
settings. Without this type of identification, it will be difficult to
perform evaluation of expected versus actual state in a platform-neutral
way.</t>
<t>High-level configuration items tend to change much less frequently than the
platform-specific configuration items (see <xref
target="IM-ELEMENTS-OTHER-IDENTIFIERS-PLATFORM-CI"/>) that might be
associated with them. To provide for the greatest amount of sustainability,
collections of configuration item identifiers are best defined by specific
communities of interest, while platform-specific identifiers are best
defined by the source vendor of the platform. Under this model, the primary
source vendors would map their platform-specific configuration controls to
the appropriate platform-independent item allowing end-user organizations to
make use of these relationships.</t>
<t>To support different communities of interest, it may be necessary to support
multiple methods for identification of configuration items and for
associating related metadata. Use of an IANA registry supporting multiple
configuration item identification methods would be an ideal way forward. To
the extent possible, a few number of configuration item identification
approaches is desirable, to maximize the update by vendors who would be
maintain mapping of platform-specific configuration identifiers to the more
general platform-neutral configuration identifiers.</t>
<section title="Related Work" toc="exclude">
<section title="Control Correlation Identifier">
<t>The Control Correlation Identifier (CCI) <xref target="CCI"/> is
developed and managed by the United States Department of Defense
(US-DoD) Defense Information Systems Agency (DISA). According to
their website, CCI "provides a standard identifier and description
for each of the singular, actionable statements that comprise an
information assurance (IA) control or IA best practice. CCI bridges
the gap between high-level policy expressions and low-level
technical implementations. CCI allows a security requirement that is
expressed in a high-level policy framework to be decomposed and
explicitly associated with the low-level security setting(s) that
must be assessed to determine compliance with the objectives of that
specific security control. This ability to trace security
requirements from their origin (e.g., regulations, IA frameworks) to
their low-level implementation allows organizations to readily
demonstrate compliance to multiple IA compliance frameworks. CCI
also provides a means to objectively roll-up and compare related
compliance assessment results across disparate technologies."</t>
<t>It is recommended that this approach be analysed as a potential
candidate for use as a configuration item identifier method.</t>
<t>Note: This reference to CCI is for informational purposes. Since the
editors do not represent DISA's interests, its inclusion in this
document does not indicate the presence or lack of desire to
contribute aspects of this effort to SACM.</t>
</section>
<section title="A Potential Alternate Approach">
<t>There will likely be a desire by different communities to create
different collections of configuration item identifiers. This
fracturing may be caused by:<list style="symbols">
<t>Different requirements for levels of abstraction,</t>
<t>Varying needs for timely maintenance of the collection,
and</t>
<t>Differing scopes of technological needs.</t>
</list></t>
<t>Due to these and other potential needs, it will be difficult to
standardize around a single collection of configuration identifiers.
A workable solution will be one that is scalable and usable for a
broad population of end-user organizations. An alternate approach
that should be considered is the definition of data model that
contains a common set of metadata attributes, perhaps supported by
an extensible taxonomy, that can be assigned to platform-specific
configuration items. If defined at a necessary level of granularity,
it may be possible to query collections of platform-specific
configuration items provided by vendors to create groupings at
various levels of abstractions. By utilizing data provided by
vendors, technological needs and the timeliness of information can
be addressed based on customer requirements.</t>
<t> SACM should consider this and other approaches to satisfy the need
for configuration item roll-up in a way that provides the broadest
benefit, while achieving a sensible degree of scalability and
sustainability.</t>
</section>
</section>
</section>
<section title="Vulnerability Identifier">
<t>An unique name for a known software flaw that exists in specific versions of
one or more units of software. One use of a vulnerability identifier in the
SACM context is to associate a given flaw with the vulnerable software using
software identifiers. For this reason at minimum, software identifiers
should identify a software product to the patch or version level, and not
just to the level that the product is licensed.</t>
<section title="Related Work" toc="exclude">
<section title="Common Vulnerabilities and Exposures">
<t>Common Vulnerabilities and Exposures (CVE) <xref target="CVE-WEBSITE"
/> is a MITRE led effort to assign common identifiers to publicly
known security vulnerabilities in software to facilitate the sharing
of information related to the vulnerabilities. CVE is the industry
standard by which software vendors, tools, and security
professionals identify vulnerabilities and could be used to address
SACM's need for a vulnerability identifier.</t>
</section>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-ENDPOINT-CHARACTERIZATION"
title="Endpoint characterization">
<t>Target when policies (collection, evaluated, guidance) apply</t>
<t>Collection can be used to further characterize</t>
<t>Also human input</t>
<t>Information required to characterize an endpoint is used to determine what
endpoints are the target of a posture assessment. It is also used to determine
the collection, evaluation, and/or reporting policies and the associated
guidance that apply to the assessment. Endpoint characterization information may
be populated by:<list style="symbols">
<t>A manual input process and entered into records associated with the
endpoint, or</t>
<t>Using information collected and evaluated by an assessment.</t>
</list></t>
<t>Regardless of the method of collection, it will be necessary to query and
exchange endpoint characterization information as part of the assessment
planning workflow.</t>
<section title="Related Work" toc="exclude">
<section title="Extensible Configuration Checklist Description Format"
toc="exclude">
<section title="Background" anchor="XCCDF-BACKGROUND">
<t>The Extensible Configuration Checklist Description Format (XCCDF) is
a specification that provides an XML-based format for expressing
security checklists. The XCCDF 1.2 specification is published by
International Organization for Standardization (ISO) <xref
target="ISO.18180"/>. XCCDF contains multiple components and
capabilities, and various components align with different elements
of this information model.</t>
<t>This specification was originally published by NIST <xref
target="NISTIR-7275"/>. When contributed to ISO Joint Technical
Committee 1 (JTC 1), a comment was introduced indicating an interest
in the IETF becoming the maintenance organization for this standard.
If the SACM working group is interested in taking on engineering
work pertaining to XCCDF, a contribution through a national body can
be made to create a ballot resolution for transition of this
standard to the IETF for maintenance.</t>
</section>
<section title="Applicability to Endpoint characterization"
anchor="IM-ELEMENTS-XCCDF-CHARACTERIZATION">
<t>The target component of XCCDF provides a mechanism for capturing
characteristics about an endpoint including the fully qualified
domain name, network address, references to external identification
information (e.g. Asset Identification), and is extensible to
support other useful information (e.g. MAC address, globally unique
identifier, certificate, etc.). XCCDF may serve as a good starting
point for understanding the types of information that should be used
to identify an endpoint.</t>
</section>
</section>
<section title="Asset Reporting Format" toc="exclude">
<section title="Background" anchor="ARF-BACKGROUND" toc="exclude">
<t>The Asset Reporting Format (ARF) <xref target="NISTIR-7694"/> is a
data model to express information about assets, and the
relationships between assets and reports. It facilitates the
reporting, correlating, and fusing of asset information within and
between organizations. ARF is vendor and technology neutral,
flexible, and suited for a wide variety of reporting
applications.</t>
<t>There are four major sub-components of ARF:<list style="symbols">
<t>Asset: The asset component element includes asset
identification information for one or more assets. It simply
houses assets independent of their relationships to reports.
The relationship section can then link the report section to
specific assets.</t>
<t>Report: The report component element contains one or more
asset reports. An asset report is composed of content (or a
link to content) about one or more assets.</t>
<t>Report-Request: The report-request component element contains
the asset report requests, which can give context to asset
reports captured in the report section. The report-request
section simply houses asset report requests independent of
the report which was subsequently generated.</t>
<t>Relationship: The relationship component element links
assets, reports, and report requests together with
well-defined relationships. Each relationship is defined as
{subject} {predicate} {object}, where {subject} is the
asset, report request, or report of interest, {predicate} is
the relationship type being established, and {object} is one
or more assets, report requests, or reports.</t>
</list></t>
</section>
<section title="Relationship to Endpoint Characterization" toc="exclude">
<t>For Endpoint Characterization, ARF can be used in multiple ways due
to its flexibility. ARF supports the use of the Asset Identification
specification (more in <xref target="IM-ELEMENTS-CHAR-AI"/>) to
embed the representation of one or more assets as well as
relationships between those assets. It also allows the inclusion of
report-requests, which can provide details on what data was required
for an assessment.</t>
<t>ARF is agnostic to the data formats of the collected posture
attributes and therefore can be used within the SACM Architecture to
provide Endpoint Characterization without dictating data formats for
the encoding of posture attributes. The embedded Asset
Identification data model (see <xref target="AI-BACKGROUND"/>) can
be used to characterize one or more endpoints to allow targeting for
collection, evaluation, etc. Additionally, the report-request model
can dictate the type of reporting that has been requested, thereby
providing context as to which endpoints the guidance applies. </t>
</section>
<section title="Asset Identification" anchor="IM-ELEMENTS-CHAR-AI"
toc="exclude">
<t>Described earlier</t>
<t>In the context of Endpoint Characterization, the Asset Identification
data model could be used to encode information that identifies
specific endpoints and/or classes of endpoints to which a particular
assessment is relevant. The flexibility in the Asset Identification
specification allows usage of various endpoint identifiers as
defined by the SACM engineering work.</t>
<t>As stated in <xref target="IM-ELEMENTS-CHAR-AI"/>, the Asset
Identification specification is included within the Asset Reporting
Framework (ARF) and therefore can be used in concert with that
specification as well.</t>
</section>
</section>
<section title="The CPE Applicability Language"
anchor="CPE-APPLICABILITY-BACKGROUND" toc="exclude">
<t>CPE described earlier</t>
<t>Applicability in CPE is defined as an XML language <xref
target="NISTIR-7698"/> for using CPE names to create applicability
statements using logical expressions. These expressions can be used to
applicability statements that can drive decisions about assets, whether
or not to do things like collect data, report data, and execute policy
compliance checks.</t>
<t>It is recommended that SACM evolve the CPE Applicability Language through
engineering work to allow it to better fit into the security automation
vision laid out by the Use Cases and Architecture for SACM. This should
include de-coupling the identification part of the language from the
logical expressions, making it such that the language is agnostic to the
method by which assets are identified. This will allow use of SWID, CPE
Names, or other identifiers to be used, perhaps supported by an IANA
registry of identifier types.</t>
<t>The other key aspect that should be evolved is the ability to make use of
the Applicability Language against a centralized repository of collected
posture attributes. The language should be able to make applicability
statements against previously collected posture attributes, such that an
enterprise can quickly query the correct set of applicable endpoints in
an automated and scalable manner.</t>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-PA-EXPRESSION" title="Posture Attribute Expression">
<t>Discuss the catalog concept. Listing of things that can be chosen from. Things we
can know about. Vendors define catalogs. Ways for users to get vendor-provided
catalogs.</t>
<t>To support the collection of posture attributes, there needs to be a way for
operators to identify and select from a set of platform-specific attribute(s) to
collect. The same identified attributes will also need to be identified
post-collection to associate the actual value of that attribute pertaining to an
endpoint as it was configured at the time of the collection. To provide for
extensibility, the need exists to support a variety of possible identification
approaches. It is also necessary to enable vendors of software to provide a
listing, or catalog, of the available posture attributes to operators that can
be collected. Ideally, a federated approach will be used to allow organizations
to identify the location for a repository containing catalogs of posture
attributes provided by authoritative primary source vendors. By querying these
repositories, operators will be able to acquire the appropriate listings of
available posture attributes for their deployed assets. One or more posture
attribute expressions are needed to support these exchanges.</t>
<section title="Related Work" toc="exclude">
<t>The ATOM Syndication Format <xref target="RFC4287"/> provides an extensible,
flexible XML-based expression for organizing a collection of data feeds
consisting of entries. This standard can be used to express one or more
catalogs of posture attributes represented as data feeds. Groupings of
posture attributes would be represented as entries. These entries could be
defined using the data models described in the "Related Work" sections
below. Additionally, this approach can also be used more generally for
guidance repositories allowing other forms of security automation guidance
to be exchanged using the same format.</t>
</section>
<section title="Platform Configuration Attributes">
<t>A low-level, platform-dependent posture attribute as determined by the
authoritative primary source vendor. Collection guidance will be derived
from catalogs of platform specific posture attributes.</t>
<t>For example, a primary source vendor would create a platform-specific posture
attribute that best models the posture attribute data for their
platform.</t>
<section title="Related Work" toc="exclude">
<section title="Open Vulnerability and Assessment Language">
<t>A general overview of OVAL was provided previously in <xref
target="IM-ELEMENTS-OVAL-BACKGROUND"/>. The OVAL System
Characteristics platform extension models provide a catalog of the
posture attributes that can be collected from an endpoint. In OVAL
these posture attributes are further grouped into logical constructs
called OVAL Items. For example, the passwordpolicy_item that is part
of the Windows platform extension groups together all the posture
attributes related to passwords for an endpoint running Windows
(e.g. maximum password age, minimum password length, password
complexity, etc.). The various OVAL Items defined in the OVAL System
Characteristics may serve as a good starting for the types of
posture attribute data that needs to be collected from
endpoints.</t>
<t>OVAL platform extension models may be shared using the ATOM
Syndication Format.</t>
</section>
<section
title="Network Configuration Protocol and YANG Data Modeling Language"
anchor="NETCONF-BACKGROUND">
<!-- spell out -->
<t>The Network Configuration Protocol (NETCONF) <xref target="RFC6241"/>
defines a mechanism for managing and retrieving posture attribute
data from network infrastructure endpoints. The posture attribute
data that can be collected from a network infrastructure endpoint is
highly extensible and can defined using the YANG modeling language
<xref target="RFC6020"/>. Models exist for common datatypes,
interfaces, and routing subsystem information among other subjects.
The YANG modeling language may be useful in providing an extensible
framework for the SACM community to define one or more catalogs of
posture attribute data that can be collected from network
infrastructure endpoints.</t>
<t>Custom YANG modules may also be shared using the ATOM Syndication
Format.</t>
</section>
<section
title="Simple Network Management Protocol and Management Information Base Entry"
anchor="SNMP-BACKGROUND">
<t>The Simple Network Protocol (SNMP) <xref target="RFC3411"/> defines a
protocol for managing and retrieving posture attribute data from
endpoints on a network . The posture attribute data that can be
collected of an endpoint and retrieved by SNMP is defined by the
Management Information Base (MIB) <xref target="RFC3418"/> which is
hierarchical collection of information that is referenced using
Object Identifiers . Given this, MIBs may provide an extensible way
for the SACM community to define a catalog of posture attribute data
that can be collected off of endpoints using SNMP.</t>
<t>MIBs may be shared using the ATOM Syndication Format.</t>
</section>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-ACTUAL-VALUE" title="Actual Value Representation">
<t>Discuss instance concept.</t>
<t>The actual value of a posture attribute is collected or published from an
endpoint. The identifiers discussed previously provide names for the posture
attributes (i.e., software or configuration item) that can be the subject of an
assessment. The information items listed below are the actual values collected
during the assessment and are all associated with a specific endpoint.</t>
<section title="Software Inventory">
<t>A software inventory is a list of software identifiers (or content)
associated with a specific endpoint. Software inventories are maintained in
some organized fashion so that entities can interact with it. Just having
software publish identifiers onto an endpoint is not enough, there needs to
be an organized listing of all those identifiers associated with that
endpoint.</t>
<section title="Related Work" toc="exclude">
<section title="Asset Summary Reporting" anchor="ASR-BACKGROUND"
toc="exclude">
<t>The Asset Summary Reporting (ASR) specification <xref
target="NISTIR-7848"/> provides a format for capturing summary
information about one or more assets. Specifically, it provides the
ability to express a collection of records from some defined data
source and map them to some set of assets. As a result, this
specification may be useful for capturing the software installed on
an endpoint, its relevant attributes, and associating it with a
particular endpoint.</t>
</section>
<section title="Software Identification Tags">
<t>SWID tag were previously introduced in <xref target="SWID-BACKGROUND"
/>. As stated before, SWID tags are ideally deployed to an endpoint
during software installation. In the less ideal case, they may also
be generated based on information retrieved from a proprietary
software installation data store. At minimum, SWID tag must contain
an identifier for each unit of installed software. Given this, SWID
tags may be a viable way for SACM to express detailed information
about the software installed on an endpoint.</t>
</section>
</section>
</section>
<section title="Collected Platform Configuration Posture Attributes">
<t>Configurations associated with a software instance associated with an
endpoint</t>
<t>A list of the configuration posture attributes associated with the actual
values collected from the endpoint during the assessment as
required/expressed by any related guidance. Additionally, each configuration
posture attribute is associated with the installed software instance it
pertains to.</t>
<section title="Related Work" toc="exclude">
<section title="Open Vulnerability and Assessment Language">
<t>A general overview of OVAL was provided previously in <xref
target="IM-ELEMENTS-OVAL-BACKGROUND"/>. As mentioned earlier,
the OVAL System Characteristics platform extensions provide a
catalog of the posture attributes that can be collected and assessed
in the form of OVAL Items. These OVAL Items also serve as a model
for representing posture attribute data and associated values that
are collected off an endpoint. Furthermore, the OVAL System
Characteristics model provides a system_info construct that captures
information that identifies and characterizes the endpoint from
which the posture attribute data was collected. Specifically, it
includes operating system name, operating system version, endpoint
architecture, hostname, network interfaces, and an extensible
construct to support arbitrary additional information that may be
useful in identifying the endpoint in an enterprise such as
information capture in Asset Identification constructs. The OVAL
System Characteristics model could serve as a useful starting point
for representing posture attribute data collected from an endpoint
although it may need to undergo some changes to satisfy the needs of
the SACM community.</t>
</section>
<section title="NETCONF-Based Collection">
<t>Introduced earlier in <xref target="NETCONF-BACKGROUND"/>, NETCONF
defines a protocol for managing and retrieving posture attribute
data from network infrastructure endpoints. NETCONF provides the
<get-config> and <get> operations to retrieve the
configuration data, and configuration data and state data
respectively from a network infrastructure endpoint. Upon successful
completion of these operations, the current posture attribute data
of the network infrastructure endpoint will be made available.
NETCONF also provides a variety of filtering mechanisms (XPath,
subtree, content matching, etc.) to trim down the posture attribute
data that is collected from the endpoint. Given that NETCONF is
widely adopted by network infrastructure vendors, it may useful to
consider this protocol as a standardized mechanism for collecting
posture attribute data from network infrastructure endpoints.</t>
<t>As a side note, members of the OVAL Community have also developed a
proposal to extend the OVAL Language to support the assessment of
NETCONF configuration data <eref
target="https://github.com/OVALProject/Sandbox/blob/master/x-netconf-definitions-schema.xsd"
/>. The proposal leverages XPath to extract the posture attribute
data of interest from the XML data returned by NETCONF. The
collected posture attribute data can then be evaluated using OVAL
Definitions and the results of the evaluation can be expressed as
OVAL Results. While this proposal is not currently part of the OVAL
Language, it may be worth considering.</t>
</section>
<section title="SNMP-Based Collection">
<t>The SNMP, previously introduced in <xref target="SNMP-BACKGROUND"/>,
defines a protocol for managing and retrieving posture attribute
data from endpoints on a network <xref target="RFC3411"/>. SNMP
provides three protocol operations <xref target="RFC3416"/>
(GetRequest, GetNextRequest, and GetBulkRequest) for retrieving
posture attribute data defined by MIB objects. Upon successful
completion of these operations, the requested posture attribute data
of the endpoint will be made available to the requesting
application. Given that SNMP is widely adopted by vendors, and the
MIBs that define posture attribute data on an endpoint are highly
extensible, it may useful to consider this protocol as a
standardized mechanism for collecting posture attribute data from
endpoints in an enterprise.</t>
</section>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-EVALUATION-GUIDANCE" title="Evaluation Guidance">
<section title="Configuration Evaluation Guidance">
<t>The evaluation guidance is applied by evaluators during posture assessment of
an endpoint. This guidance must be able to reference or be associated with
the following previously defined information elements:<list style="symbols">
<t>configuration item identifiers,</t>
<t>platform configuration identifiers, and</t>
<t>collected Platform Configuration Posture Attributes.</t>
</list></t>
<section title="Related Work" toc="exclude">
<section title="Open Vulnerability and Assessment Language">
<t>A general overview of OVAL was provided previously in <xref
target="IM-ELEMENTS-OVAL-BACKGROUND"/>. The OVAL Definitions
model provides an extensible framework for making assertions about
the state of posture attribute data collected from an endpoint.
Guidance written against this model consists of one or more OVAL
Tests, which can be logically combined, where each OVAL Test defines
what posture attributes should be collected from an endpoint (as
OVAL Objects) and optionally defines the expected state of the
posture attributes (as OVAL States). While the OVAL Definitions
model may be a useful starting point for evaluation guidance, it
will likely require some changes to decouple collection and
evaluation concepts to satisfy the needs of the SACM community.</t>
</section>
<section title="XCCDF Rule" anchor="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF">
<t>A general description of XCCDF was provided in <xref
target="XCCDF-BACKGROUND"/>. As noted there, an XCCDF document
represents a checklist of items against which a given endpoint's
state is compared and evaluated. An XCCDF Rule represents one
assessed item in this checklist. A Rule contains both a prose
description of the assessed item (either for presentation to the
user in a tool's user interface, or for rendering into a prose
checklist for human consumption) and can also contain instructions
to support automated evaluation of the assessed item, if such
automated assessment is possible. Automated assessment instructions
can be provided either within the XCCDF Rule itself, or by providing
a reference to instructions expressed in other languages, such as
OVAL.</t>
<t>In order to support greater flexibility in XCCDF, checklists can be
tailored to meet certain needs. One way to do this is to enable or
disable certain rules that are appropriate or inappropriate to a
given endpoint, respectively. For example, a single XCCDF checklist
might contain check items to evaluate the configuration of an
endpoint's operating system. An endpoint deployed in an enterprise's
DMZ might need to be locked down more than a common internal
endpoint, due to the greater exposure to attack. In this case, some
operating system configuration requirements for the DMZ endpoint
might be unnecessary for the internal endpoint. Nonetheless, most
configuration requirements would probably remain applicable to both
environments (providing a common baseline for configuration of the
given operating system) and thus be common to the checking
instructions for both types of endpoints. XCCDF supports this by
allowing a single checklist to be defined, but then tailored to the
needs of the assessed endpoint. In the previous example, some Rules
that apply only to the DMZ endpoint would be disabled during the
assessment of an internal endpoint and would not be exercised during
the assessment or count towards the assessment results. To
accomplish this, XCCDF uses the CPE Applicability Language. By
enhancing this applicability language to support other aspects of
endpoint characterization (see <xref
target="CPE-APPLICABILITY-BACKGROUND"/>), XCCDF will also
benefit from these enhancements.</t>
<t>In addition, XCCDF Rules also support parameterization, allowing
customization of the expected value for a given check item. For
example, the DMZ endpoint might require a password of at least 12
characters, while an internal endpoint may only need 8 or more
characters in its password. By employing parameterization of the
XCCDF Rule, the same Rule can be used when assessing either type of
endpoint, and simply be provided with a different target parameter
each time to reflect the different role-based requirements. Sets of
customizations can be stored within the XCCDF document itself: XCCDF
Values store parameters values that can be used in tailoring, while
XCCDF Profiles store sets of tailoring instructions, including
selection of certain Values as parameters and the enabling and
disabling of certain Rules. The tailoring capabilities supported by
XCCDF allow a single XCCDF document to encapsulate configuration
evaluation guidance that applies to a broad range of endpoint
roles.</t>
</section>
</section>
</section>
</section>
<section anchor="IM-ELEMENTS-EVAL-REPORTING" title="Evaluation Result Reporting">
<section title="Configuration Evaluation Results">
<t>The evaluation guidance applied during posture assessment of an endpoint to
customize the behavior of evaluators. Guidance can be used to define
specific result output formats or to select the level-of-detail for the
generated results. This guidance must be able to reference or be associated
with the following previously defined information elements:<list
style="symbols">
<t>configuration item identifiers,</t>
<t>platform configuration identifiers, and</t>
<t>collected Platform Configuration Posture Attributes.</t>
</list></t>
<section title="Related Work" toc="exclude">
<section title="XCCDF TestResults" toc="exclude">
<t>A general description of the eXtensible Configuration Checklist
Description Format (XCCDF) was provided in section <xref
target="XCCDF-BACKGROUND"/>. The XCCDF TestResult structure
captures the outcome of assessing a single endpoint against the
assessed items (i.e., XCCDF Rules) contained in an XCCDF instance
document. XCCDF TestResults capture a number of important pieces of
information about the assessment including:<list style="symbols">
<t>The identity of the assessed endpoint. See <xref
target="IM-ELEMENTS-XCCDF-CHARACTERIZATION"/> for more
about XCCDF structures used for endpoint identification.</t>
<t>Any tailoring of the checklist that might have been employed.
See <xref target="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF"/> for
more on how XCCDF supports tailoring.</t>
<t>The individual results of the assessment of each enabled
XCCDF Rule in the checklist. See <xref
target="IM-ELEMENTS-EVAL-GUIDANCE-XCCDF"/> for more on
XCCDF Rules.</t>
</list></t>
<t>The individual results for a given XCCDF Rule capture only whether
the rule "passed", "failed", or experienced some exceptional
condition, such as if an error was encountered during assessment.
XCCDF 1.2 Rule results do not capture the actual state of the
endpoint. For example, an XCCDF Rule result might indicate that an
endpoint failed to pass requirement that passwords be of a length
greater than or equal to 8, but it would not capture that the
endpoint was, in fact, only requiring passwords of 4 or more
characters. It may, however, be possible for a user to discover this
information via other means. For example, if the XCCDF Rule uses an
OVAL Definition to effect the Rule's evaluation, then the actual
endpoint state may be captured in the corresponding OVAL System
Characteristics file.</t>
<t>The XCCDF TestResult structure does provide a useful structure for
understanding the overall assessment that was conducted and the
results thereof. The ability to quickly determine the Rules that are
not complied with on a given endpoint allow administrators to
quickly identify where remediation needs to occur.</t>
</section>
<section title="Open Vulnerability and Assessment Language" toc="exclude">
<t>A general overview of OVAL was provided previously in <xref
target="IM-ELEMENTS-OVAL-BACKGROUND"/>. OVAL Results provides a
model for expressing the results of the assessment of the actual
state of the posture attribute values collected of an endpoint
(represented as an OVAL System Characteristics document) against the
expected posture attribute values (defined in an OVAL Definitions
document. Using OVAL Directives, the granularity of OVAL Results can
also be specified. The OVAL Results model may be useful in providing
a format for capturing the results of an assessment.</t>
</section>
<section title="Asset Summary Reporting" toc="exclude">
<t>A general overview of ASR was provided previously in <xref
target="ASR-BACKGROUND"/>. As ASR provides a way to report
summary information about assets, it can be used within the SACM
Architecture to provide a way to aggregate asset information for
later use. It makes no assertions about the data formats used by the
assessment, but rather provides an XML, record-based way to collect
aggregated information about assets.</t>
<t>By using ASR to collect this summary information within the SACM
Architecture, one can provide a way to encode the details used by
various reporting requirements, including user-definable
reports.</t>
</section>
<section title="ARF" toc="exclude">
<t>A general overview of ARF was provided previously in <xref
target="ARF-BACKGROUND"/>. Because ARF is data model agnostic,
it can provide a flexible format for exchanging collection and
evaluation information from endpoints. It additionally provides a
way to encode relationships between guidance and assets, and as
such, can be used to associate assessment results with guidance.
This could be the guidance that directly triggered the assessment,
or for guidance that is run against collected posture attributes
located in a central repository.</t>
</section>
</section>
</section>
<section title="Software Inventory Evaluation Results">
<t>The results of an evaluation of an endpoint's software inventory against an
authorized software list. The authorized software list represents the policy
for what software units are allowed, prohibited, and mandatory for an
endpoint.</t>
</section>
</section>
</section>
</section>
<section title="Graph Model">
<t>TODO: Write text on how the information model above
can be realized in this kind of graph model.</t>
<t>The graph model describes how security information is structured,
related, and accessed. Control of operations to supply and/or access the data is
architecturally distinct from the structuring of the data in the information model.
Authorization may be applied by the Control Plane (as defined in the SACM
Architecture <xref target="I-D.ietf-sacm-architecture"/>) to requests for
information from a consumer or requests for publication from a provider, and may
also be applied by a provider to a direct request from a consumer.</t>
<t>This architecture addresses information structure independently of the access/transport of
that information. This separation enables scalability, customizability, and extensibility.
Access to provide or consume information is particularly suited to publish/subscribe/query
data transport and data access control models.</t>
<t>This graph model is a framework that:<list style="symbols">
<t>Facilitates the definition of extensible data types that support SACM's use
cases</t>
<t>Provides a structure for the defined data types to be exchanged via a variety
of data transport models</t>
<t>Describes components used in information exchange, and the objects exchanged</t>
<t>Captures and organizes evolving information and
information relationships for multiple data publishers</t>
<t>Provides access to the published information via publish, query, and subscribe
operations</t>
<t>Leverages the knowledge and experience gained from incorporating TNC IF-MAP
into many disparate products that have to integrate and share an information
model in a scalable, extensible manner</t>
</list></t>
<section title="Background: Graph Models">
<t>Knowledge is often represented with graph-based formalisms. A common
formalism defines a graph as follows:<list style="symbols">
<t>A set of *vertices*</t>
<t>A set of *edges*, each connecting two vertices (technically, an edge
is an ordered pair of vertices)</t>
<t>A set of zero or more *properties* attached to each vertices and
edges. Each property consists of a type and a optionally a value.
The type and the value are typically just strings</t>
</list></t>
<figure title="Knowledge represented by a graph"
anchor="figure-knownledge-graph">
<artwork><![CDATA[
+------------------+ +-----------------+
| Id: 1 | parent-of |Id: 2 |
| Given name: Sue | --------------> |Given name: Ann |
| Family name: Wong| |Family name: Wong|
+------------------+ +-----------------+
A VERTEX AN EDGE A VERTEX
]]></artwork>
</figure>
<t>A pair of vertices connected by an edge is commonly referred to as a triple
that comprises subject, predicate and object. For example, subject = Sue
Wong, predicate = is-parent-of, object = Ann Wong. A common language that
uses this representation is the Resource Description Framework (RDF) <xref
target="W3C.REC-rdf11-concepts-20140225"/>.</t>
</section>
<section title="Graph Model Overview">
<t>The proposed model, influenced by IF-MAP, is a labeled graph: each vertex has a label.</t>
<t>A table of synonyms follows.</t>
<texttable>
<ttcol>Graph Theory</ttcol>
<ttcol>Graph Databases</ttcol>
<ttcol>IF-MAP and This Internet Draft</ttcol>
<c>Vertex or Node</c>
<c>Node</c>
<c>-</c>
<c>Label</c>
<c>-</c>
<c>Identifier</c>
<c>Edge</c>
<c>Edge</c>
<c>Link</c>
<c>-</c>
<c>Property</c>
<c>Metadata Item</c>
</texttable>
<t>In this mode, identifiers and metadata have hierarchical structure.</t>
<t>The graphical aspect makes this model well suited to non-hierarchical
relationships, such as connectivity in a computer network.</t>
<t>Hierarchical properties allow this model to accommodate structures such as
YANG <xref target="RFC6020"/> data models.</t>
</section>
<section title="Identifiers">
<t>Each identifier is an XML element. For extensibility, schemas use
xsd:anyAttribute and such. </t>
<t>Alternately, this model could be changed to use another hierarchical
notation, such as JSON.</t>
<t>Identifiers are unique: two different vertices cannot have equivalent
identifiers.</t>
<t>An identifier has a type. There is a finite, but extensible, set of
identifier types. If the identifier is XML, the type is based on the XML
schema.</t>
<t>In IF-MAP, standard identifier types include IP address, MAC address,
identity, and overlay network. Additional identifier types will need to be
standardized for SACM use cases.</t>
<t>Any number of metadata items can be attached to an identifier.</t>
<t>Some identifiers, especially those relating to identity, address, and
location, require the ability to specify an administrative domain (such as
AD domain, L2 broadcast domain / L3 routing domain, or geographic domain) in
order to differentiate between instances with the same name occurring in
different realms.</t>
</section>
<section title="Links">
<t>A link can be thought of as an ordered pair of identifiers.</t>
<t>Any number of metadata items can be attached to a link.</t>
</section>
<section title="Metadata">
<t>A metadata item is the basic unit of information, and is attached to an
identifier or to a link.</t>
<t>A given metadata item is an XML document. In IF-MAP metadata items are generally small. However, larger ones, such as YANG data models, can also fit. For
extensibility, the XML schemas of metadata items use xsd:anyAttribute and such.</t>
<t>Alternately, this model could be changed to use another hierarchical
notation, such as JSON.</t>
<t>A metadata item has a type. There is a finite, but extensible, set of
metadata types. If the metadata item is XML, the type is based on the XML
schema. An example metadata type is
http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device-
characteristic.</t>
<t>TNC IF-MAP Metadata for Network Security <xref
target="TNC-IF-MAP-NETSEC-METADATA"/> and TNC IF-MAP Metadata for ICS
Security <xref target="TNC-IF-MAP-ICS-METADATA"/> define many pertinent
metadata types. More will need to be standardized for SACM use cases.</t>
</section>
<section title="Use for SACM">
<t>Many of the information elements
can be represented as vertices, and many of the
relationships can be represented as edges.</t>
<t>Identifiers are like database keys. For example, there would be identifiers for addresses, identities, unique endpoint identifiers, software component identifiers, and hardware component identifiers. The inventory of software instances and hardware instances within an endpoint might be expressed using a single YANG description, as a single metadata item in the graph. Where to put Endpoint Attribute Assertions, Evaluation Results, and the like is an open question.</t>
</section>
<section title="Provenance" anchor="sec-im-tnc-graph-provenance">
<t>Provenance helps to protect the SACM ecosystem against a misled or malicious
provider.</t>
<t>The provenance of a metadata item includes:<list style="symbols">
<t>The time when the item was produced</t>
<t>The component that produced the item, including its software and
version</t>
<t>The policies that governed the producing component, with versions</t>
<t>The method used to produce the information (e.g., vulnerability
scan)</t>
</list></t>
<t>How provenance should be expressed is an open question. For reference, in
IF-MAP provenance of a metadata item is expressed within the metadata item
<xref target="TNC-IF-MAP-NETSEC-METADATA"/>. For example, there is a
top-level XML attribute called "timestamp".</t>
<t>It is critical that provenance be secure from tampering. How to achieve that
security is out of scope of this document.</t>
</section>
<section title="Extensibility">
<t>Anyone can define an identifier type or a metadata type, by creating an XML
schema (or other specification). There is no need for a central authority.
Some deployments may exercise administrative control over the permitted
identifier types and metadata types; others may leave components free
rein.</t>
<t>A community of components can agree on and use new identifier and metadata
types, if the administrators allow it. This allows rapid innovation.
Intermediate software that conveys graph changes from one component to
another does not need changes. Components that do not understand the new
types do not need changes. Accordingly, a consumer normally ignores metadata
types and identifier types it does not understand.</t>
<t>As a proof point for this agility, the original use cases for TNC IF- MAP
Binding for SOAP <xref target="TNC-IF-MAP-SOAP-Binding"/> were addressed in
TNC IF-MAP Metadata for Network Security <xref
target="TNC-IF-MAP-NETSEC-METADATA"/>. Some years later an additional,
major set of use cases, TNC IF-MAP Metadata for ICS <xref
target="TNC-IF-MAP-ICS-METADATA"/>, were specified and implemented.</t>
</section>
</section>
<!-- Change Log
v00 2014-10-24 LLL Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:51 |