Draft: draft-ietf-sacm-information-model

Commentary: The I - D IM ( ) provides text that is useful for the SACM WG IM . We need to go through both documents and merge and consolidate the text that makes sense for the WG IM . 
 More information about the merger changes can be found here . 
 Addressed in -05 . 
 There is currently a section in the information model that describes various SACM Components . Can this information be removed from the information model and included in the architecture ? 
 The SACM Charter and corresponding milestone for the Information Model do not align . The charter says the document is " standards track " whereas the milestone says the document is " informational " . 
 This has been addressed .
This document defines the information model for SACM.
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 RFC3444.
These activities are aimed at the level of the technology that
performs operations to support the collection, communication, and
evaluation of endpoint information.
Review of the SACM Use Case 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.
These management process areas are a way to connect the SACM use
cases and building blocks RFC7632 to the organizational needs such
that the definition of information requirements has a clearly
understood context.  For more information, see mapping-to-sacm-use-
cases which maps the SACM information model to the SACM use cases.
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.
At the same time, a consumer *can* know these things, if necessary.
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.
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
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.
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.
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.
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.
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.
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.
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.
An endpoint identifier is generally subject to cloning, when a
system image is cloned.  Then, it is no longer unique.
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.
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.
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.
So the model must let SACM components and humans reason with
uncertainty.  There are no facts, only assertions.
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.
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.
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.
to ensure interoperability between SACM data models that are used
as transport encodings,
to enable secure information sharing in a scalable and extensible
fashion in order to support the tasks conducted by SACM
components.
A complete set of requirements imposed on the IM can be found in 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.
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.
These tasks are defined in I-D.ietf-sacm-terminology.
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 RFC7012 syntax used to model the different
information model concepts.
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 metadata.
Objects are the mechanism by which attributes (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 metadata.
Objects are complex Information Elements that can be created using
one of the following IPFIX constructs that are defined in Section 3.1
of RFC7012.
The notation used to define the SACM Information Elements (IEs) is
based on a customized version of the IPFIX information model syntax
RFC7012 which is described in attribute-syntax and subject-syntax.
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 information-model-
elements.  The examples are provided for demonstration purposes only.
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.
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.
Attributes: an instance of an attribute type is the simplest IE
structure comprised of a unique attribute name and an attribute
value.
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.
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.
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.
The SACM IM provides two 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 in order to be consumed by another SACM
component uses these top-level subjects.
The notation the SACM IM is defined in is based on the IP Information
Flow Export (IPFIX) Information Model syntax described in RFC7012.
The customized syntax used by the SACM IM is defined below in
attribute-syntax and subject-syntax.
The following is a modified version of the template for Information
Elements provided in Section 9.1 of RFC7013 that can be used to model
objects.
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.
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.
The following is a modified version of the template for Information
Elements provided in Section 9.1 of RFC7013 that can be used to model
subjects.
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.
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.
The reference is a subject that includes an appropriate number of
IEs in order to identify the referenced content-element by its
actual content.
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).
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.
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.
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.
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.
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.
An event is represented as a Posture Attribute Assertion whose time
interval has length zero.
Although SACM components are mainly covered by the SACM architecture,
we have some remarks.  TODO: Move them to the architecture document?
ISSUE (CEK): Why do we need information elements that model SACM
compoments?
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].