One document matched: draft-ietf-sacm-information-model-06.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 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 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 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="std" docName="draft-ietf-sacm-information-model-06" 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 Elements that are transported between SACM
components and their interconnected relationships. The primary purpose of the
Secure Automation and Continuous Monitoring (SACM) Information Model is to ensure
the interoperability of corresponding SACM data models and addresses the use cases
defined by SACM. The Information Elements and corresponding types are maintained
as the IANA "SACM Information Elements" registry.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="INTRO">
<t>The SACM Information Model (IM) serves multiple purposes:
<list style="symbols">
<t>to ensure interoperability between SACM data models that are used as transport
encodings,</t>
<t>to provide a standardized set of Information Elements - the SACM Vocabulary -
to enable the exchange of content vital to automated security posture assessment,
and</t>
<t>to enable secure information sharing in a scalable and extensible fashion in
order to support the tasks conducted by SACM components.</t>
</list>
</t>
<t>A complete set of requirements imposed on the IM can be
found in <xref target="I-D.ietf-sacm-requirements"/>. The
SACM IM is intended to be used for standardized data exchange between SACM components
(data in motion). Nevertheless, the Information Elements (IE) and their relationships
defined in this document can be leveraged to create and align corresponding data models
for data at rest.</t>
<t>The information model expresses, for example, target
endpoint (TE) attributes, guidance,
and evaluation results. The corresponding Information Elements are consumed and
produced by SACM components as they carry out tasks.</t>
<t>The primary tasks that this information model supports (on data, control, and management
plane) are:
<list style="symbols">
<t>TE Discovery</t>
<t>TE Characterization</t>
<t>TE Classification</t>
<t>Collection</t>
<t>Evaluation</t>
<t>Information Sharing</t>
<t>SACM Component Discovery</t>
<t>SACM Component Authentication</t>
<t>SACM Component Authorization</t>
<t>SACM Component Registration</t>
</list>
</t>
<t>These tasks are defined in <xref target="I-D.ietf-sacm-terminology"/>.</t>
</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 title="Information Element Examples">
<t>The notation used to define the SACM Information
Elements (IEs) is based on a customized version of
the IPFIX information model syntax <xref
target="RFC7012"/> which is described in <xref target="information-element-specification-template"/>.
However, there are several examples presented throughout the document that use a simplified
pseudo-code to illustrate the basic structure. It should be noted that while
they include actual names of subjects and attributes as well as values, they
are not intended to influence how corresponding SACM IEs should be defined
in <xref target="information-model-elements"/>. The examples are provided for
demonstration purposes only.</t>
</section>
</section>
<section title="Information Elements">
<t>The IEs defined in this document comprise the building blocks by which all SACM
content is composed. They are consumed and provided by SACM components on the data
plane. Every Information Element has a unique label: its name. Every type of IE
defined by the SACM IM is registered as a type at the IANA registry. The Integer
Index of the IANA SMI number tables can be used by SACM data models.</t>
<section title="Context of Information Elements" anchor="context-of-information-elements">
<t>The IEs in this information model represent information related to assets in the following
areas (based on the use cases described in <xref
target="RFC7632"/>):
<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>
</section>
<section title="Extensibility of Information Elements">
<t>A SACM data model based on this information model MAY include additional information
elements that are not defined here. The labels of additional Information Elements
included in different SACM data models MUST NOT conflict with the labels of the
Information Elements defined by this information model, and the names of additional
Information Elements MUST NOT conflict with each other or across multiple data models.
In order to avoid naming conflicts, the labels of additional IEs SHOULD be prefixed
to avoid collisions across extensions. The prefix MUST include an organizational
identifier and therefore, for example, MAY be an IANA enterprise number, a (partial)
name space URI, or an organization name abbreviation.
</t>
</section>
</section>
<section title="Structure of Information Elements" anchor="structure-of-information-elements">
<t>There are two basic types of IEs:
<list style="symbols">
<t>Attributes: an instance of an attribute type is the simplest IE structure comprised
of a unique attribute name and an attribute value.</t>
<t>Subjects: a subject is a richer structure that has a unique subject name and one
or more attributes or subjects. In essence, instances of a subject type are defined
(and differentiated) by the attribute values and subjects associated with it.</t>
</list>
</t>
<figure title="Example instance of an attribute and subject."
anchor="attribute-subject-example">
<artwork>
hostname = "arbutus"
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
</artwork>
</figure>
<t>In general, every piece of information that enables security posture assessment or
further enriches the quality of the assessment process can be associated with metadata.
In the SACM IM, metadata is represented by specific subjects and is bundled with other
attributes or subjects to provide additional information about them. The IM explicitly
defines two kinds of metadata:
<list style="symbols">
<t>Metadata focusing on the data origin (the SACM component that provides the
information to the SACM domain)</t>
<t>Metadata focusing on the data source (the target endpoint that is assessed)</t>
</list>
Metadata can also include relationships that refer to other associated IEs (or SACM
content in general) by using referencing labels that have to be included in the metadata
of the associated IE.</t>
<t>Subjects can be nested and the SACM IM allows for circular or recursive nesting. The
association of IEs via nesting results in a tree-like structure wherein subjects compose
the root and intermediary nodes and attributes the leaves of the tree. This semantic
structure does not impose a specific structure on SACM data models regarding data in
motion or data repository schemata for data at rest.</t>
<t>The SACM IM provides two conceptual top-level subjects that
are used to ensure a homogeneous structure for SACM content
and its associated metadata: SACM statements and SACM content-elements. Every set of IEs that is provided by a SACM component
must provide the information contained in these two subjects although
it is up to the implementer whether or not the subjects are explicitly
defined in a data model.</t>
<t>The notation the SACM IM is defined in is based on a modified
version of the IP Information Flow Export (IPFIX) Information
Model syntax described in Section 2.1 of <xref target="RFC7012"/>.
The customized syntax used by the SACM IM is defined below in
<xref target="information-element-specification-template"/>.</t>
<figure
title="Information Element Specification Template"
anchor="information-element-specification-template">
<artwork>
elementId (required): The numeric identifier of the
Information Element. It is used
for the compact identification
of an Information Element. If
this identifier is used without
an enterpriseID, then the
elementId must be unique, and
the description of allowed values
is administrated by IANA. The
value "TBD" may be used during
development of the information
model until an elementId is
assigned by IANA and filled
in at publication time.
enterpriseId (optional): Enterprises may wish to define
Information Elements without
registering them with IANA, for
example, for enterprise-internal
purposes. For such Information
Elements, the elementId is
not sufficient when used
outside the enterprise. If
specifications of enterprise-
specific Information Elements
are made public and/or if
enterprise-specific identifiers
are used by SACM components
outside the enterprise, then the
enterprise-specific identifier
MUST be made globally unique by
combining it with an enterprise
identifier. Valid values for the
enterpriseId are defined by IANA
as Structure of Management
Information (SMI) network management
private enterprise numbers.
name (required): A unique and meaningful name for
the Information Element.
dataType (required): There are two kinds of datatypes:
simple and structured. Attributes are
defined using simple datatypes
and subjects are defined using
structured datatypes. The contents of
the datatype field will be either
a reference to one of the simple
datatypes listed in Section
5.1, or the specification of
structured datatype as defined in
Section 5.2.
status (required): The status of the specification
of the Information Element.
Allowed values are "current" and
"deprecated". All newly defined
Information Elements have "current"
status. The process for moving
Information Elements to the
"deprecated" status is TBD.
description (required): Describes the meaning of the
Information Element, how it is
derived, conditions for its use,
etc.
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 |
+-------+-----------------------+
| | |
+-------+-----------------------+
references (optional): Identifies other RFCs or documents
outside the IETF which provide
additional information or context
about the Information Element.
</artwork>
</figure>
<section title="SACM Content Elements"
anchor="sacm-content-elements">
<t>Every piece of information that is provided by a SACM component is always associated
with a set of metadata, for example, the timestamp at which this set of information
was produced (e.g. by a collection task) or what target endpoint this set of
information is about (e.g. the data-source or a target endpoint identifier, respectively).
The subject that associates content IE with content-metadata IE is called a
content-element. Content metadata can also include relationships that express associations
with other content-elements.</t>
<figure title="Example set of IEs associated with a timestamp and a
target endpoint label." anchor="sacm-content-element-example">
<artwork>
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus",
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
)
</artwork>
</figure>
</section>
<section title="SACM Statements"
anchor="sacm-statements">
<t>One or more SACM content elements are bundled in a SACM statement. In contrast to
content-metadata, statement-metatdata focuses on the providing SACM component instead of the
target endpoint that the content is about. The only content-specific metadata included in
the SACM statement is the content-type IE. Therefore, multiple content-elements that share
the same statement metadata and are of the same content-type can be included in a single
SACM statement. A SACM statement functions similar to an envelope or a header. Its purpose
is to enable the tracking of the origin of data inside a SACM domain and more importantly
to enable the mitigation of conflicting information that my originate from different SACM
components. How a consuming SACM component actually deals with conflicting information is
out-of-scope of the SACM IM. Semantically, the term statement implies that the SACM content
provided by a SACM component might not be correct in every context, but rather is the result
of an best-effort to produce correct information.</t>
<figure title="Example of a simple SACM statement including a single content-element." anchor="sacm-statement-example-1">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
hostname = "arbutus"
)
)
</artwork>
</figure>
<figure title="Example of conflicting information originating from different SACM components." anchor="sacm-statement-example-2">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N27.99619,
longitude = E86.92761
)
)
)
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934744,
data-origin = e42885a1-0270-44e9-bb5c-865cf6bd4800,
content-type = observation
),
content-element = (
content-metadata = (
collection-timestamp = 146193821,
te-label = fb02e551-7101-4e68-8dec-1fde6bd10981
),
coordinates = (
latitude = N16.67622,
longitude = E141.55321
)
)
)
</artwork>
</figure>
</section>
<section title="Relationships">
<t>An IE can be associated with another IE, e.g. a user-name attribute
can be associated with a content-authorization subject. These
references are expressed via the relationships subject, which can be
included in a corresponding content-metadata subject. The
relationships subject includes a list of one or more references. The
SACM IM does not enforce a SACM domain to use unique identifiers as
references. Therefore, there are at least two ways to reference another
content-element:
<list style="symbols">
<t>The value of a reference represents a specific content-label that
is unique in a SACM domain (and has to be included in the
corresponding content-element metadata in order to be referenced),
or</t>
<t>The reference is a subject that includes an appropriate number
of IEs in order to identify the referenced content-element by its
actual content.</t>
</list>
</t>
<t>It is recommended to provide unique identifiers in a SACM domain and
the SACM IM provides a corresponding naming-convention as a reference
in section FIXME. The alternative highlighted above summarizes a valid
approach that does not require unique identifiers and is similar to the
approach of referencing target endpoints via identifying attributes
included in a characterization record (FIXME REF arch).</t>
<figure title="Example instance of a content-element subject associated with
another subject via its content metadata." anchor="sacm-relationship-example">
<artwork>
content-element = (
content-metadata = (
collection-timestamp = 1461934031,
te-label =
fb02e551-7101-4e68-8dec-1fde6bd10981
relationships = (
associated-with-user-account =
f3d70ef4-7e18-42af-a894-8955ba87c95d
)
),
hostname = "arbutus"
)
content-element = (
content-metadata = (
content-label = f3d70ef4-7e18-42af-a894-8955ba87c95d
),
user-account = (
username = romeo
authentication = local
)
)
</artwork>
</figure>
</section>
<section title="Event" anchor="event">
<t>Event subjects provide a structure to represent the change
of IE values that was detected by a collection task at a
specific point of time. It is mandatory to include the new
values and the collection timestamp in an event subject and it is recommended to include
the past values and a collection timestamp that were replaced by the new IE values.
Every event can also be associated with a subject-specific
event-timestamp and a lastseen-timestamp that might differ
from the corresponding collection-timestamps. If these are
omitted the collection-timestamp that is included in the
content-metadata subject is used instead.
</t>
<figure title="Example of a SACM statement containing an event." anchor="sacm-event-example">
<artwork>
sacm-statement = (
statement-metadata = (
publish-timestamp = 1461934031,
data-origin = 24e67957-3d31-4878-8892-da2b35e121c2,
content-type = event
),
event = (
event-attributes = (
event-name = "host-name change",
content-element = (
content-metadata = (
collection-timestamp = 146193322,
data-source =
fb02e551-7101-4e68-8dec-1fde6bd10981,
event-component = past-state
),
hostname = "arbutus"
),
content-element = (
content-metadata = (
collection-timestamp = 146195723,
data-source =
fb02e551-7101-4e68-8dec-1fde6bd10981,
event-component = current-state
),
hostname = "lilac"
)
)
)
</artwork>
</figure>
</section>
<section title="Categories" anchor="categories">
<t>Categories are special IEs that enable to refer to multiple
types of IE via just one name. Therefore, they are similar
to a type-choice. A prominent example of a category is
network-address. Network-address is a category that every
kind of network address is associated with, e.g. mac-address,
ipv4-address, ipv6-address, or typed-network-address. If a
subject includes network-address as one of its components,
any of the category members are valid to be used in its place.
</t>
<t>Another prominent example is EndpointIdentifier. Some IEs
can be used to identify (and over time re-recognize) target
endpoints - those are associated with the category endpoint-identifier.
</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.
Also, consider inserting table that discusses the various properties of designation attributes and include it in this
section to help others determine whether or not a new Information Element should be considered a designation attribute.
Lastly, explain how designation attributes can be used. For example, letting a consumer identify an endpoint, for two purposes:
<list style="symbols">
<t>To tell whether two endpoint
attribute assertions concern the same endpoint</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>
</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>
<section title="Abstract Data Types" anchor="abstract-data-types">
<t>This section describes the set of valid abstract data types that
can be used for the specification of the SACM
Information Elements in <xref target="information-model-elements"/>.
SACM currently supports two classes of datatypes that can be used to
define Information Elements.
<list style="symbols">
<t>Simple: Datatypes that are atomic and are used to define the type of data represented by an attribute Information Element.</t>
<t>Structured: Datatypes that can be used to define the type of data represented by a subject Information Element.</t>
</list>
</t>
<t>Note that further abstract data types may be specified by future extensions of the SACM information model.</t>
<section title="Simple Datatypes" anchor="simple-datatypes">
<section title="IPFIX Datatypes" anchor="ipfix-datatypes">
<t>To facilitate the use of existing work, SACM supports the following
abstract data types defined in Section 3 of <xref target="RFC7012"/>.
<list style="symbols">
<t>unsigned8, unsigned16, unsigned32, unsigned64</t>
<t>signed8, signed16, signed32, signed64</t>
<t>float32, float64</t>
<t>boolean</t>
<t>macAddress</t>
<t>octetArray</t>
<t>string</t>
<t>dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, dateTimeNanoSeconds</t>
<t>ipv4Address, ipv6Address</t>
</list>
</t>
</section>
<section title="ciscoTrainSoftwareVersion">
<t>The type "ciscoTrainSoftwareVersion" represents
a software version that conforms to the Cisco
IOS Train string format.</t>
</section>
<section title="rpmSoftwareVersion">
<t>The type "rpmSoftwareVersion" represents a
software version that conforms to the
EPOCH:VERSION-RELEASE format.</t>
</section>
<section title="simpleSoftwareVersion">
<t>The type "simpleSoftwareVersion" represents
a software version that is a hierarchical
list of non-negative integers separated by
a single character delimiter.</t>
</section>
</section>
<section title="Structured Datatypes" anchor="structured-datatypes">
<section title="List Datatypes" anchor="list-datatypes">
<t>SACM defines the following abstract list data types that are used to
represent the structured data associated with subjects.
<list style="symbols">
<t>list: indicates that the Information Element order is not significant but
MAY be preserved.</t>
<t>orderedList: indicates that Information Element order is significant and
MUST be preserved.</t>
</list>
</t>
<t>The notation for defining a SACM structured datatype is based on regular
expressions, which are composed of the keywords "list" or "orderedList"
and an Information Element expression. IE expressions use some of the regular
expression syntax and operators, but the terms in the expression are
the names of defined Information Elements instead of character classes. The
syntax for defining list and orderedList datatypes is described below, using
BNF:</t>
<figure title="Syntax for Defining List Datatypes" anchor="list-datatype-bnf">
<artwork>
<list-def> -> ("list"|"orderedList") "(" <ie-expression> ")"
<ie-expression> -> <ie-name> <cardinality>?
( ("," | "|") <ie-name> <cardinality>?)*
<cardinality> -> "*" | "+" | "?" |
( "(" <non-neg-int> ("," <non-neg-int>)? ")" )
</artwork>
</figure>
<t>As seen above, multiple occurences of an Information Element may be
present in a structured datatype. The cardinality of an Information Element
within a structured Information Element definition is defined by the following
operators:</t>
<figure title="Specifying Cardinality for Structured Datatypes"
anchor="specifying-cardinality-for-structured-datatypes">
<artwork>
* - zero or more occurrences
+ - one or more occurrences
? - zero or one occurrence
(m,n) - between m and n occurrences
</artwork>
</figure>
<t>The absence of a cardinality operator implies one mandatory occurrence of the
Information Element.</t>
<t>Below is an example of a structured Information Element definition.</t>
<figure title="Example of Defining a Structured Datatype" anchor="example-of-defining-a-structured-datatype">
<artwork>
personInfo = list(firstName, middleNames?, lastName)
firstName = string
middleNames = orderedList(middleName+)
middleName = string
lastName = string
As an example, consider the name "John Ronald Reuel Tolkien".
Below are instances of this name, structured according to the
personInfo definition.
personInfo = (firstName="John", middleNames(middleName="Ronald",
middleName="Reuel"), lastName="Tolkien")
personInfo = (middleNames(middleName="Ronald", middleName=" Reuel"),
lastName="Tolkien", firstName="John")
The instance below is not legal with respect to the definition
of personInfo because the order in middleNames is not preserved.
personInfo = (firstName="John", middleNames(middleName=" Reuel",
middleName="Ronald"), lastName="Tolkien")
</artwork>
</figure>
</section>
</section>
</section>
<section title="Information Model Assets" anchor="information-model-assets">
<t>In order to represent the Information Elements related to the areas listed
in <xref target="context-of-information-elements"/>, the information model
defines the information needs (or metadata about those information needs)
related to following types of assets which arse defined in
<xref target="I-D.ietf-sacm-terminology"/> (and included below
for convenience) which are of interest to SACM.
Specifically:<list style="symbols">
<t>Endpoint</t>
<t>Software Component</t>
<t>Hardware Component</t>
<t>Identity</t>
<t>Guidance</t>
<t>Evaluation Results</t>
</list>
</t>
<t>The following figure shows the make up of an Endpoint asset which contains
zero or more hardware components and zero or more software components each of
which may have zero or more instances running an endpoint at any given time as
well as zero or more identities that act on behalf of the endpoint when interfacing
with other endpoints, tools, or services. An endpoint may also contain other
endpoints in the case of a virtualized environment.</t>
<figure title="Model of an Endpoint"
anchor="figure-model-of-an-endpoint">
<artwork>
<![CDATA[
+---------+*______in>_______*+-----+
|Hardware | |! !|
|Component| +---------+ |! !|
+---------+ |Software |in> |! !|
|Component|____|! !|
+---------+* *|! !|
1| |! !|
*| | | +----------+
+---------+ |End- |*_____*| Identity |
|Software |in> |point| acts +----------+
|Instance |____| | for>
+---------+* 1|! !|
|! !|
|! !|
|! !|
|! !|____
|! !|0..1|
+-----+ |
|* |
|_______|
in>
]]>
</artwork>
</figure>
<section title="Asset">
<t>As defined in <xref target="RFC4949"/>, an asset is 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>In the scope of SACM, an asset can be composed of other assets. Examples of
Assets include: Endpoints, Software, Guidance, or Identity. Furthermore, an
asset is not necessarily owned by an organization.</t>
</section>
<section title="Endpoint">
<t>From <xref target="RFC5209"/>, an endpoint is any computing device that can
be connected to a network. Such devices normally are associated with a
particular link layer address before joining the network and potentially
an IP address once on the network. This includes: laptops, desktops,
servers, cell phones, or any device that may have an IP address.</t>
<t>To further clarify, an endpoint is any physical or virtual device that
may have a network address. Note that, network infrastructure devices
(e.g. switches, routers, firewalls), which fit the definition, are also
considered to be endpoints within this document.</t>
<t>Physical endpoints are always composites that are composed of hardware
components and software components. Virtual endpoints are composed entirely
of software components and rely on software components that provide
functions equivalent to hardware components.</t>
<t>The SACM architecture differentiates two essential categories of endpoints:
Endpoints whose security posture is intended to be assessed (target endpoints)
and endpoints that are specifically excluded from endpoint posture
assessment (excluded endpoints).</t>
</section>
<section title="Hardware Component">
<t>Hardware components are the distinguishable physical components that compose an
endpoint. The composition of an endpoint can be changed over time by adding
or removing hardware components. In essence, every physical endpoint is
potentially a composite of multiple hardware components, typically resulting
in a hierarchical composition of hardware components. The composition of hardware
components is based on interconnects provided by specific hardware types (e.g.
mainboard is a hardware type that provides local busses as an interconnect). In
general, a hardware component can be distinguished by its serial number.</t>
<t>Examples of a hardware components include: motherboards, network interfaces, graphics
cards, hard drives, etc.</t>
</section>
<section title="Software Component">
<t>A software package installed on an endpoint (including the operating system) as
well as a unique serial number if present (e.g. a text editor associated with
a unique license key).</t>
<t>It should be noted that this includes both benign and harmful software packages. Examples
of benign software components include: applications, patches, operating system kernel, boot
loader, firmware, code embedded on a webpage, etc. Examples of malicious software components
include: malware, trojans, viruses, etc.</t>
<section title="Software Instance">
<t>A running instance of the software component (e.g. on a multi-user system, one logged-in
user has one instance of a text editor running and another logged-in user has another
instance of the same text editor running, or on a single-user system, a user could have
multiple independent instances of the same text editor running).</t>
</section>
</section>
<section title="Identity">
<t>TODO: Define an Asset Identity asset. 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>
<t>Examples of an identity include: username, user and device certificates, etc.</t>
</section>
<section title="Guidance">
<t>TODO: Need to resolve the forms of Guidance in the terminology and those listed as sub-sections below.</t>
<t>Guidance is input instructions to processes and tasks, such as collection or evaluation. Guidance influences
the behavior of a SACM component and is considered content of the management plane. Guidance can be manually
or automatically generated or provided. Typically, the tasks that provide guidance to SACM components have
a low-frequency and tend to be be sporadic. A prominent example of guidance are target endpoint profiles,
but guidance can have many forms, including:
<list style="symbol">
<t>Configuration, e.g. a SACM component's name, or a CMDB's IPv6 address.</t>
<t>Profiles, e.g. a set of expected states for network behavior associated with target endpoints employed by specific users.</t>
<t>Policies, e.g. an interval to refresh the registration of a SACM component, or a list of required capabilities for SACM components in a specific location.</t>
</list>
</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="Evaluation Results">
<t>Evaluation results are the resulting values from having evaluated a set of posture attributes.</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-an-endpoint"/> does not show this). In the limiting case, Endpoint Attribute
Assertions are not retained. When 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>
<section title="Information Model Elements" anchor="information-model-elements">
<t>TODO: Define specific subjects, 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>
<section title="hardwareSerialNumber">
<figure>
<artwork>
elementId: TBD
name: hardwareSerialNumber
dataType: string
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
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
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
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
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
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: orderedList(interfaceName, interfaceIndex, macAddress,
ifType, flags)
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>
</section>
<section title="softwareIdentifier">
<figure>
<artwork>
elementId: TBD
name: softwareIdentifier
dataType: string
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
status: current
description: The title of the software application.
</artwork>
</figure>
</section>
<section title="softwareCreator">
<figure>
<artwork>
elementId: TBD
name: softwareCreator
dataType: string
status: current
description: The software developer (e.g., vendor or author).
</artwork>
</figure>
</section>
<section title="simpleSoftwareVersion">
<figure>
<artwork>
elementId: TBD
name: simpleSoftwareVersion
dataType: simpleVersion
status: current
description: The version string for a software application that
follows the simple versioning scheme.
</artwork>
</figure>
</section>
<section title="rpmSoftwareVersion">
<figure>
<artwork>
elementId: TBD
name: rpmSoftwareVersion
dataType: rpmVersion
status: current
description: The version string for a software application that
follows the RPM versioning scheme.
</artwork>
</figure>
</section>
<section title="ciscoTrainSoftwareVersion">
<figure>
<artwork>
elementId: TBD
name: ciscoTrainSoftwareVersion
dataType: ciscoTrainVersion
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: list(simpleSoftwareVersion | rpmSoftwareVersion |
ciscoTrainSoftwareVersion)
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.
</artwork>
</figure>
</section>
<section title="lastUpdated">
<figure>
<artwork>
elementId: TBD
name: lastUpdated
dataType: dateTimeSeconds
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: orderedList(softwareIdentifier, title, creator,
softwareVersion, lastUpdated)
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.
</artwork>
</figure>
</section>
<section title="globallyUniqueIdentifier">
<figure>
<artwork>
elementId: TBD
name: globallyUniqueIdentifier
dataType: unsigned8
status: current
metadata: true
description: TODO.
</artwork>
</figure>
</section>
<section title="dataOrigin">
<figure>
<artwork>
elementId: TBD
name: dataOrigin
dataType: string
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
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
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
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
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
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
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
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
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
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
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
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
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
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
status: current
description: IPv4 source address prefix.</artwork>
</figure>
</section>
<section title="destinationIPv4Prefix">
<figure>
<artwork>
elementId: TBD
name: destinationIPv4Prefix
dataType: ipv4Address
status: current
description: IPv4 destination address prefix.</artwork>
</figure>
</section>
<section title="sourceMacAddress">
<figure>
<artwork>
elementId: TBD
name: sourceMacAddress
dataType: macAddress
status: current
description: The IEEE 802 source MAC address field.</artwork>
</figure>
</section>
<section title="ipVersion">
<figure>
<artwork>
elementId: TBD
name: ipVersion
dataType: unsigned8
status: current
description: The IP version field in the IP packet header.</artwork>
</figure>
</section>
<section title="interfaceDescription">
<figure>
<artwork>
elementId: TBD
name: interfaceDescription
dataType: string
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
status: current
description: Specifies the description of an application.</artwork>
</figure>
</section>
<section title="applicationId">
<figure>
<artwork>
elementId: TBD
name: applicationId
dataType: octetArray
status: current
description: Specifies an Application ID per [RFC6759].</artwork>
</figure>
</section>
<section title="applicationName">
<figure>
<artwork>
elementId: TBD
name: applicationName
dataType: string
status: current
description: Specifies the name of an application.</artwork>
</figure>
</section>
<section title="exporterIPv4Address">
<figure>
<artwork>
elementId: TBD
name: exporterIPv4Address
dataType: ipv4Address
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
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
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
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
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
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
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="informationElementId">
<figure>
<artwork>
elementId: TBD
name: informationElementId
dataType: unsigned16
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
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
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
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
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
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
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
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
status: current
description: User name associated with the flow.</artwork>
</figure>
</section>
<section title="applicationCategoryName">
<figure>
<artwork>
elementId: TBD
name: applicationCategoryName
dataType: string
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
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
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
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
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
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
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
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
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
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: orderedList
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: orderedList
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
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
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
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
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
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
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
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
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
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
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-an-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"?-->
&RFC2119; &RFC5280;</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3580; &RFC4949; &RFC5201; &RFC5209;
&RFC5793; &RFC7012; &RFC7632;
&I-D.ietf-sacm-requirements; &I-D.ietf-sacm-terminology;
&I-D.ietf-sacm-architecture;
&I-D.salowey-sacm-xmpp-grid;
<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>
</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 Section Identifying Attributes.</t>
<t>Split the figure into Figure Model of Endpoint and Figure Information Elements.</t>
<t>Added 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 Mapping to SACM Use Cases into the Appendix. Added a reference to it in <xref target="INTRO"/></t>
<t>Added the <xref target="structure-of-information-elements"/> 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="structure-of-information-elements"/>.</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="structure-of-information-elements"/>
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 title="Changes in Revision 05">
<t>Merged proposed changes from the I-D IM into
the WG IM (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/41).</t>
<t>Fixed some formatting warnings.</t>
<t>Removed a duplicate IE and added a few IE datatypes
that were missing.</t>
</section>
<section title="Changes in Revision 06">
<t>Clarified that the SACM statement and content-element subjects are conceptual
and that they do not need to be explicitly defined in a data model as long as
the necessary information is provided.</t>
<t>Updated the IPFIX syntax used to define Information Elements. There are still
a couple of open issues that need to be resolved.</t>
<t>Updated some of the Information Elements contained in Section 7 to use the revised
IPFIX syntax. The rest of the Information Elements will be converted in a later
revision.</t>
<t>Performed various clean-up and refactoring in Sections 6 and 7. Still need to
go through Section 8.</t>
<t>Removed appendices that were not referenced in the body of the draft. The text
from them is still available in previous revisions of this document if needed.</t>
</section>
</section>
<!-- Change Log
v00 2014-10-24 LLL Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:53 |