Internet DRAFT - draft-combined-sacm-information-model
draft-combined-sacm-information-model
Internet Engineering Task Force D. Waltermire, Ed.
Internet-Draft NIST
Intended status: Informational K. Watson
Expires: March 11, 2015 DHS
C. Kahn
L. Lorenzin
Juniper Networks, Inc.
September 7, 2014
SACM Information Model
draft-combined-sacm-information-model-00
Abstract
TODO: reconcile
[TNC]This document proposes an information model for endpoint posture
assessment. It describes the information needed to perform certain
assessment activities and to communicate and respond to the
assessments.[/TNC]
[wandw]This document defines an information model for aggregated
configuration and operational data, so that the data can be evaluated
to determine an organization's security posture.[/wandw]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Waltermire, et al. Expires March 11, 2015 [Page 1]
Internet-Draft SACM Information Model September 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 6
3. Conventions used in this document . . . . . . . . . . . . . . 7
3.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
4. Elements of the SACM Information Model . . . . . . . . . . . 7
4.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Unique Endpoint Identifier . . . . . . . . . . . . . 9
4.1.2. Endpoint Credential . . . . . . . . . . . . . . . . . 9
4.1.3. Software Component . . . . . . . . . . . . . . . . . 10
4.1.3.1. Unique Software Identifier . . . . . . . . . . . 10
4.1.4. Software Instance . . . . . . . . . . . . . . . . . . 11
4.1.5. Hardware Component . . . . . . . . . . . . . . . . . 11
4.1.6. Hardware Instance . . . . . . . . . . . . . . . . . . 11
4.2. Internal Attribute Collector . . . . . . . . . . . . . . 11
4.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. User Credential . . . . . . . . . . . . . . . . . . . 12
4.4. Network Session . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Address . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2. Authorizations . . . . . . . . . . . . . . . . . . . 12
4.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. External Attribute Collector . . . . . . . . . . . . . . 13
4.7. Endpoint Attribute Assertion . . . . . . . . . . . . . . 14
4.7.1. Form and Precise Meaning . . . . . . . . . . . . . . 14
4.7.2. Source . . . . . . . . . . . . . . . . . . . . . . . 15
4.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
4.7.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 15
4.7.5. Posture Attribute . . . . . . . . . . . . . . . . . . 15
4.7.6. Event . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7.7. Difference between Attribute and Event . . . . . . . 16
4.8. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Evaluation Result . . . . . . . . . . . . . . . . . . . . 17
4.10. Report Generator . . . . . . . . . . . . . . . . . . . . 17
4.11. Report . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.12. Organization? . . . . . . . . . . . . . . . . . . . . . . 18
4.13. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 19
Waltermire, et al. Expires March 11, 2015 [Page 2]
Internet-Draft SACM Information Model September 2014
4.13.1. Internal Collection Guidance . . . . . . . . . . . . 19
4.13.2. External Collection Guidance . . . . . . . . . . . . 19
4.13.3. Evaluation Guidance . . . . . . . . . . . . . . . . 19
4.13.4. Retention Guidance . . . . . . . . . . . . . . . . . 19
4.13.5. Reporting Guidance . . . . . . . . . . . . . . . . . 19
4.14. Provenance of Information . . . . . . . . . . . . . . . . 20
5. Graph Model . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Background: Graph Models . . . . . . . . . . . . . . . . 21
5.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 21
5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 22
5.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 23
5.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 23
5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24
6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 24
6.1. Graph Model for Detection of Posture Deviation . . . . . 24
6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 25
6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 26
6.1.4. Relationships between Identifiers and Metadata . . . 26
6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 34
A.1. What is Trusted Network Connect? . . . . . . . . . . . . 34
A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 35
A.3. What is the TNC Information Model? . . . . . . . . . . . 35
Appendix B. Text for Possible Inclusion in the Terminology Draft 36
B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 36
B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 36
B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 37
Appendix C. Text for Possible Inclusion in the Architecture or
Use Cases . . . . . . . . . . . . . . . . . . . . . 37
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 37
C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 38
C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 39
Appendix D. Text for Possible Inclusion in the Requirements
Draft . . . . . . . . . . . . . . . . . . . . . . . 43
D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 43
D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 43
Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 44
E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 44
E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 44
Waltermire, et al. Expires March 11, 2015 [Page 3]
Internet-Draft SACM Information Model September 2014
E.2. From Information Needs to Information Elements . . . . . 45
E.3. Information Model Elements . . . . . . . . . . . . . . . 45
E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 47
E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 49
E.3.1.3. Software Identification . . . . . . . . . . . . . 50
E.3.1.4. Hardware Identification . . . . . . . . . . . . . 53
E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 53
E.3.2.1. Platform Configuration Item Identifier . . . . . 53
E.3.2.2. Configuration Item Identifier . . . . . . . . . . 59
E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 61
E.3.3. Endpoint characterization . . . . . . . . . . . . . . 61
E.3.4. Posture Attribute Expression . . . . . . . . . . . . 65
E.3.4.2. Platform Configuration Attributes . . . . . . . . 65
E.3.5. Actual Value Representation . . . . . . . . . . . . . 67
E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 67
E.3.5.2. Collected Platform Configuration Posture
Attributes . . . . . . . . . . . . . . . . . . . 68
E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 69
E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 69
E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 71
E.3.7.1. Configuration Evaluation Results . . . . . . . . 71
E.3.7.2. Software Inventory Evaluation Results . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction
TODO: reconcile
[TNC]This document proposes an information model to serve the
security automation use- cases outlined by the IETF SACM
workgroup.[/TNC]
[wandw]This draft was developed in response to the Call for
Contributions for the SACM Information Model sent to NIST
[IM-LIAISON-STATEMENT-NIST]. This draft proposes a notional
information model for endpoint posture assessment. It describes the
information needed to perform certain assessment activities and
relevant work that may be used as a basis for the development of
specific data models. The terms information model and data model
loosely align with the terms defined in RFC3444 [RFC3444].
The four primary activities to support this information model are:
1. Endpoint Identification
2. Endpoint Characterization
3. Endpoint Attribute Expression/Representation
Waltermire, et al. Expires March 11, 2015 [Page 4]
Internet-Draft SACM Information Model September 2014
4. Policy evaluation expression and results reporting
These activities are aimed at the level of the technology that
performs operations to support collection, evaluation, and reporting.
Review of the SACM Use Case [I-D.ietf-sacm-use-cases] 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.
For this information model we have chosen to focus on the following
business process areas:
o Endpoint Management
o Software Management
o Configuration Management
o Vulnerability Management
These management process areas are a way to connect the SACM use
cases and building blocks [I-D.ietf-sacm-use-cases] to the
organizational needs such that the definition of information
requirements has a clearly understood context.[/wandw]
[TNC]The proposed 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.
The structure of each unit of information is extensible. The
arrangement of information units into a graph is also extensible; new
arrangements can be defined for new use cases.[/TNC]
Waltermire, et al. Expires March 11, 2015 [Page 5]
Internet-Draft SACM Information Model September 2014
2. Problem Statement
TODO: revise
[wandw]SACM requires a large and broad set of mission and business
processes, and to make the most effective of 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 document, we have narrowed down the scope of this
model.[/wandw] [What does "narrowed down the scope of this model"
mean? - LL]
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 sharing information despite
platform differences.
A way is needed to exchange information that (a) has breadth, meaning
the pieces of the notation are useful about a variety of endpoints
and software components, 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 requirements
directly to 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.
2.1. Mapping to SACM Use Cases
TODO: revise
[wandw]This information model directly corresponds to all four use
cases defined in the SACM Use Cases draft [I-D.ietf-sacm-use-cases].
It uses these use cases in coordination to achieve a small set of
well-defined tasks.
Waltermire, et al. Expires March 11, 2015 [Page 6]
Internet-Draft SACM Information Model September 2014
Sections [removed] thru [removed] address each of the process areas.
For each process area, a "Process Area Description" sub-section
represent an end state that is consistent with all the General
Requirements and many of the Use Case Requirements identified in the
requirements draft [I-D.camwinget-sacm-requirements].
The management process areas and supporting operations defined in
this memo directly support REQ004 Endpoint Discovery; REQ005-006
Attribute and Information Based Queries, and REQ0007 Asynchronous
Publication.
In addition, the operations that defined for each business process in
this memo directly correlate with the typical workflow identified in
the SACM Use Case document.[/wandw]
3. Conventions used in this document
3.1. Requirements Language
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 RFC 2119 [RFC2119].
4. Elements of the SACM Information Model
The proposed SACM Information Model contains several elements of the
architecture, including:
o Collectors, which may be internal (performed within the endpoint
itself) or external (performed outside of the endpoint, such as by
a hypervisor or remote sensor)
o Posture, in the form of posture attributes and evaluation results
o Additional information about the endpoint, such as a
representation of a software component, endpoint identity, user
identity, address, location, and authorization constraining the
endpoint
o History, a compilation of previously collected information [cek:
We don't model history per se. We have reports, which could be a
compilation of present information and/or of historical
information. I think it's helpful that the past and present are
modeled the same. They won't be implemented the same, but this is
an information model. So, can we remove this bullet?]
Figure 1 depicts the elements of the information model. Each element
has a meaning -- a denotation.
Waltermire, et al. Expires March 11, 2015 [Page 7]
Internet-Draft SACM Information Model September 2014
+---------+ +---------+ +--------+____________________
|Hardware | |Software | __________|Location|*_______________ |
|Component| |Component| | *+--------+* | |
+---------+ +---------+ | | |
|1 |1 | +----------+ | |
|* |* | ______|Credential|____________ | |
+---------+ +--------+ | | *+----------+* |* |* |
|Hardware | |Software| | | +---------+ +----+ |
|Instance | |Instance| | | |Network |_________|User| |
+---------+ +--------+ | | |Session |* 0..1+----+ |
|* |* *| *| |- - - - -| *|
| |___1+-----------+1______*|Network |__________+-------+
|____________| Endpoint |_____ |Interface|* 1..*|Address|
1| |0..1 | +---------+ +-------+
+-----------+ | 1|
|0..1 1| |* | |_____+-------------+
v| | |______| *|Authorization|
| | part-of> +-------------+
.................. |* .... | ........................................
------------ +---------+ | ------------
|Collection|_>_|Attribute| | |Evaluation|__>__+----------+
|Guidance |1 *|Collector| |v |Guidance |1 *|Evaluator |
------------ +---------+ | ------------ +----------+
|1 | 1|
v| | |v
|* |* *|
===========_______________________============
+----------+ |Endpoint |1..* > *|Evaluation|
|Attribute/|________|Attribute|_____-----------_______|Result |
|Event |1..* 1|Assertion|* < *|Retention|* > *============
+----------+ =========== |Guidance |____ *|
*| -----------* | |
----------- +---------+ | ======== |v |
|Reporting| |Report | |___>___*|Report|*____| |
|Guidance |__>__|Generator|___________| |______________|
-----------1 *+---------+1 > *========* <
-------------------------------------------------------------
1 Multiplicity symbols > < Direction of causation. For
0..1 found in UML 2 v ^ example, collection guidance
* class diagrams affects a collector.
1..*
..... Above this line is the
monitorable world
-------------------------------------------------------------
Figure 1: Elements and Multiplicity
Waltermire, et al. Expires March 11, 2015 [Page 8]
Internet-Draft SACM Information Model September 2014
Note: UML 2 is specified by [UML].
The following subsections elaborate upon the elements found in the
two figures.
4.1. Endpoint
See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology].
In the model, an endpoint can be part of another endpoint. This
covers cases where multiple physical endpoints act as one endpoint.
The constituent endpoints may not be distinguishable by external
observation of network behavior.
For example, a hosting center may maintain a redundant set
(redundancy group) of multi-chassis setups to provide active
redundancy and load distribution on network paths to WAN gateways.
Multi-chassis link aggregation groups make the chassis appear as one
endpoint. Traditional security controls must be applied either to
physical endpoints or the redundancy groups they compose (and
occasionally both). Loss of redundancy is difficult to detect or
mitigate without specific posture information about the current state
of redundancy groups. Even if a physical endpoint (e.g. router) that
is part of a redundancy group is replaced, the redundancy group can
remain the same.
EDITOR'S NOTE: The endpoints to which an endpoint connects affects
its security posture. Should we add peer endpoints to the model?
4.1.1. Unique Endpoint Identifier
An organization needs to uniquely identify and label an endpoint,
whether the endpoint is enrolled or is discovered in the operational
environment. The identifier should be assigned by or used in the
enrollment process.
Here "unique" means one-to-one. In practice, uniqueness is not
always attainable. Even if an endpoint has a unique identifier, an
attribute collector may not always know it.
4.1.2. Endpoint Credential
An endpoint credential provides both identification and
authentication of the endpoint. For example, a credential may be an
X.509 certificate [RFC5280] and corresponding private key. [jmf-
this example should be formatted like the other examples in this
section]
Waltermire, et al. Expires March 11, 2015 [Page 9]
Internet-Draft SACM Information Model September 2014
Not all kinds of credentials are guaranteed to be unique.
4.1.3. Software Component
An endpoint contains and runs software components.
Some of the software components are assets. "Asset" is defined in
RFC4949 [RFC4949] as "a system resource that is (a) required to be
protected by an information system's security policy, (b) intended to
be protected by a countermeasure, or (c) required for a system's
mission."
An examination of software needs to consider both (a) software assets
and (b) software that may do harm. A posture attribute collector may
not know (a) from (b). It is useful to define Software Component as
the union of (a) and (b).
Examples of Software Assets:
o An application
o A patch
o The operating system kernel
o A boot loader
o Firmware that controls a disk drive
o A piece of JavaScript found in a web page the user visits
Examples of harmful software components:
o An entertainment app that contains malware
o A malicious executable
o A web page that contains malicious JavaScript
o A business application that shipped with a virus
4.1.3.1. Unique Software Identifier
Organizations need to be able to uniquely identify and label software
installed or run on an endpoint. Specifically, they need to know the
name, publisher, unique ID, and version; and any related patches. In
some cases the software's identity might be known a priori by the
organization; in other cases, a software identity might be first
Waltermire, et al. Expires March 11, 2015 [Page 10]
Internet-Draft SACM Information Model September 2014
detected by an organization when the software is first inventoried in
an operational environment. Due to this, it is important that an
organization have a stable and consistent means to identify software
found during collection.
A piece of software may have a unique identifier, such as a SWID tag
(ISO/IEC 19770).
4.1.4. Software Instance
Each copy of a piece of software is called a software instance. The
configuration of a software instance is regarded as part of the
software instance. Configuration can strongly affect security
posture.
4.1.5. Hardware Component
Hardware components may also be assets and or harmful. For example,
a USB port on a system may be disabled to prevent information flow
into our out of a particular system; this provides an additional
layer of protection that can complement software based protections.
Other such assets may include access to or modification of storage
media, hardware key stores, microphones and cameras. Like software
assets, we can consider these hardware components both from the
perspective of (a) an asset that needs protection and (b) an asset
that can be compromised in some way to do harm.
A hardware component is often designated by a manufacturer and a part
number.
4.1.6. Hardware Instance
A hardware instance is just an instance of a particular component. A
hardware instance often has a unique serial number.
Hardware instances may need to be modeled because (a) an endpoint may
have multiple instances of a hardware component, (b) a hardware
instance may be compromised, whereas other instances may remain
intact.
4.2. Internal Attribute Collector
An endpoint may also contain one or more internal collectors.
An internal attribute collector is an attribute collector that
collects posture attributes, values, or events from inside the
endpoint. In other words, the posture attributes and events are self
reported.
Waltermire, et al. Expires March 11, 2015 [Page 11]
Internet-Draft SACM Information Model September 2014
Example: a NEA posture collector. [RFC5209]
4.3. User
4.3.1. User Credential
An endpoint is often - but not always - associated with one or more
users.
A user's credential provides both identification and authentication
of the user.
4.4. Network Session
An endpoint generally has a connection to a network, referred to here
as a network session. A multi-homed endpoint may have more than one
network session.
4.4.1. Address
A network session generally is associated with addresses, such as MAC
and IP addresses.
These addresses are not necessarily globally unique. Therefore, an
address may be qualified with a scope. For example:
o A MAC address may be qualified with its layer-2 broadcast domain.
o An IP address may be qualified with its IP routing domain.
Other kinds of addresses may find application.
4.4.2. Authorizations
Authorizations determine what the endpoint can do with its network
session. Examples include:
o A RADIUS VLAN assignment [RFC3580]
o A router or firewall access control list (ACL)
o An IF-MAP access-request constellation
[TNC-IF-MAP-NETSEC-METADATA], which may determine how a firewall
treats the endpoint
Waltermire, et al. Expires March 11, 2015 [Page 12]
Internet-Draft SACM Information Model September 2014
4.5. Location
Location can be logical or physical, and may be pertinent to security
posture. For example, some endpoints may need to stay in protected
areas for their own protection.
Examples of location:
o The switch or access point to which the endpoint has authenticated
o The switch port where the endpoint is plugged in
o The location of the endpoint's IP address in the network topology
o The geographic location of the endpoint (typically self-reported)
o A user location (typically reported by a physical access control
system)
More than one of these may pertain to an endpoint. Endpoint has a
many-to-many relationship with Location.
A collector or other system may express location information as
posture attributes.
4.6. External Attribute Collector
An external collector is a collector that observes endpoints from
outside. [kkw-many of these [collectors] are actually configured and
operated to manage assets for reasons other than posture assessments.
it is critical to bring them into this, so i like it...but does it
matter if the [collector] isn't intended to support posture
assessment, but happens to have information that can be used by
posture assessment collection consumers? do we lump them together
with collectors that are intended to support posture assessment but
run external to the endpoint?] [jmf: ditto. The exampled below are
of things that would perform external collection].
[cek-to kkw's comment, I think the purpose here is to capture their
contribution to continuous monitoring. I don't see the need to
separate things whose primary job is monitoring from things whose
primary job is something else. Is there a need?]
[cek-to jmf's comment, that is what they are examples of; is a text
change needed?]
Examples:
Waltermire, et al. Expires March 11, 2015 [Page 13]
Internet-Draft SACM Information Model September 2014
o A RADIUS server whereby an endpoint has logged onto the network
o A network profiling system, which discovers and classifies network
nodes
o A Network Intrusion Detection System (NIDS) sensor
o A vulnerability scanner
o A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine
o A management system that configures and installs software on the
endpoint
4.7. Endpoint Attribute Assertion
4.7.1. Form and Precise Meaning
An endpoint attribute assertion contains:
o One or more attribute-value pairs
o Optionally, one or more events
o A time interval
o Endpoint uniquely identified? True or false
It means:
o Over the specified time interval, there was an endpoint for which
all of the listed attribute-value pairs were true.
o For that endpoint, each event happened sometime during the time
interval. (This is meant as a normative definition of the
semantics of an endpoint attribute assertion.)
o If the "Endpoint uniquely identified" is true, the set of
attributes-value pairs together make this assertion apply to only
one endpoint.
The attributes can include posture attributes and identification
attributes. The model does not make a rigid distinction between the
two uses of attributes.
Some of the attributes may be multi-valued.
Waltermire, et al. Expires March 11, 2015 [Page 14]
Internet-Draft SACM Information Model September 2014
An Endpoint Attribute Assertion may or may not include a unique
endpoint identifier. Not every endpoint will have one. If there is
one, the SACM component that produces the Endpoint Attribute
Assertion will not necessarily know what it is.
4.7.2. Source
An Endpoint Attribute Assertion is typically provided by an attribute
collector. However, we envision some SACM components that produce
Endpoint Attribute Assertions from out-of-band sources, such as a
physical inventory system. We also envision some deriving Endpoint
Attribute Assertions from other Endpoint Attribute Assertions.
4.7.3. Example
For example, an attribute assertion might have these attribute-value
pairs:
mac-address = 01:23:45:67:89:ab
os = OS X
os-version = 10.6.8
This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran
OS X 10.6.8 throughout the specified time interval. A profiler might
have provided this assertion.
4.7.4. A Use Case
For example, Endpoint Attribute Assertions should help SACM
components to track an endpoint as it roams or stays stationary.
They must track it to track the endpoint's posture over time.
Tracking of an endpoint can employ many clues, such as:
The endpoint's MAC address
The authenticated identity (even if it identifies a user)
The location of the endpoint and the user
4.7.5. Posture Attribute
See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology].
Examples:
Waltermire, et al. Expires March 11, 2015 [Page 15]
Internet-Draft SACM Information Model September 2014
o A NEA posture attribute (PA) [RFC5209]
o A YANG model [RFC6020]
o An IF-MAP device-characteristics metadata item
[TNC-IF-MAP-NETSEC-METADATA]
4.7.6. Event
Examples:
o A structured syslog message [RFC5424]
o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA]
o A NetFlow message [RFC3954]
4.7.7. Difference between Attribute and Event
"Attribute" and "event" are often used fairly interchangeably. A
clear distinction makes the words more useful.
An *attribute* tends to stay true until something causes a change.
In contrast, an *event* occurs at a moment in time.
For a nontechnical example, "closed" is an attribute of a door. A
closed door tends to stay closed until something opens it (a breeze,
a person, or a dog).
The door's opening or closing is an event.
Similarly, "Host firewall is enabled?" may be modeled as an endpoint
attribute. Enabling or disabling the host firewall may be modeled as
an event. An endpoint's crashing also may be modeled as an event.
4.8. Evaluator
An evaluator can consume endpoint attribute assertions, previous
evaluations of posture attributes, or previous reports of evaluation
results. [kkw-i don't think this conflicts with the definition in the
terminology doc re: that evaluation tasks evaluate posture
attributes.]
[cek-I like the change. I think it *does* require a change in the
terminology doc, though.]
Example: a NEA posture validator [RFC5209]
Waltermire, et al. Expires March 11, 2015 [Page 16]
Internet-Draft SACM Information Model September 2014
[jmf- a NEA posture validator is not an example of this definition.
A NEA posture assessment is, maybe?]
[cek-Why isn't a NEA posture validator an example?]
4.9. Evaluation Result
See the definition in the SACM Terminology for Security Assessment
[I-D.ietf-sacm-terminology].
Example: a NEA access recommendation [RFC5793]
As Figure 1 shows, an Evaluation Result derives from one or more
Posture Attributes and Events.
An evaluator may be able to evaluate better if history is available.
This is a use case for retaining Posture Attributes and Events for a
time.
An Evaluation Result may be retained longer than the Endpoint
Attribute Assertions from which it derives. (Figure 1 does not show
this.) In the limiting case, Endpoint Attribute Assertions are not
retained. When as an Endpoint Attribute Assertion arrives, an
evaluator produces an Evaluation Result.
4.10. Report Generator
A report generator makes reports based on:
o Endpoint Attribute Assertions,
o Evaluation Results, and/or
o Other Reports (a weekly report may be created from daily reports)
It may summarize data continually, as the data arrives. It also may
summarize data in response to an ad hoc query.
4.11. Report
A Report summarizes:
o Endpoint Attribute Assertions,
o [kkw-if we state that a software asset is a type of posture
attribute, then a software inventory is nothing more than a report
that summarizes all software assets for an endpoint. i think this
makes much more sense than adding an object that is the software
Waltermire, et al. Expires March 11, 2015 [Page 17]
Internet-Draft SACM Information Model September 2014
inventory. contingent on adding the fact that an evaluator can
operate on posture attributes, evaluation results, or reports.]
o [cek - I like the move of saying that an inventory is a type of
report. Let's.]
o [cek - I like the move of defining a posture attribute whose value
is the identifier of a software component.]
o [cek - I'm not sure I'd say that a software asset is a type of
posture attribute, though. There's description and there's
reality. I'd tend to say that a posture attribute (always) a
partial description of an endpoint, and is the output of a posture
attribute collector. Suppose there's a stealthy piece of malware
that hasn't been detected. It's a software component, but is it a
posture attribute? I'm not sure how to talk about this.]
o Events, and/or
o Evaluation Results
A Report may routine or ad hoc.
Some reports may be machine readable. Machine readable summaries may
be consumable by automatic response systems (not part of SACM).
4.12. Organization?
[kkw-from a reporting standpoint there needs to be some concept like
organization or system. without this, there is no way to produce
result reports that can be acted upon to provide the insight or
accountability that almost all continuous monitoring instances are
trying to achieve. from a scoring or grading standpoint, an endpoint
needs to be associated with exactly one organization or system. it
can have a many to many relationship with other types of results
reporting "bins". is this important to include here? we had
organization as a core asset type for this reason, so i think it is a
key information element. but i also know that i do not want to define
all the different reporting types, so i am unsure.]
[cek-I had not thought of this at all. Would it make sense to treat
the organization and the bins as part of the guidance for creating
reports? Maybe not. We should discuss.]
Waltermire, et al. Expires March 11, 2015 [Page 18]
Internet-Draft SACM Information Model September 2014
4.13. Guidance
[jmf- the guidance sections need more detail. . .]
[cek - What is missing? We would welcome a critique or text.]
Guidance is generally configurable by human administrators.
4.13.1. Internal Collection Guidance
An internal collector may need guidance to govern what it collects
and when.
4.13.2. External Collection Guidance
An external collector may need guidance to govern what it collects
and when.
4.13.3. Evaluation Guidance
An evaluator typically needs Evaluation Guidance to govern what it
considers to be a good or bad security posture.
4.13.4. Retention Guidance
A SACM deployment may retain posture attributes, events, or
evaluation results for some time. Retention supports ad hoc
reporting and other use cases.
If information is retained, retention guidance controls what is
retained and for how long.
If two or more pieces of retention guidance apply to a piece of
information, the guidance calling for the longest retention should
take precedence.
Retained information may be stored in a Configuration Management
Database (CMDB), for example.
4.13.5. Reporting Guidance
A Reporting Task typically needs Reporting Guidance to govern the
reports it generates.
Waltermire, et al. Expires March 11, 2015 [Page 19]
Internet-Draft SACM Information Model September 2014
4.14. Provenance of Information
Each Posture Attribute, Event, Evaluation Result, and Report needs to
be labeled with its provenance (see Section 5.7).
5. Graph Model
TODO: Write text on how the information model above can be realized
in this kind of graph model.
The graph model describes how security information is structured,
related, and accessed. Control of operations to supply and/or access
the data is architecturally distinct from the structuring of the data
in the information model. Authorization may be applied by the
Control Plane (as defined in the SACM Architecture
[I-D.camwinget-sacm-architecture]) to requests for information from a
consumer or requests for publication from a provider, and may also be
applied by a provider to a direct request from a consumer.
This architecture addresses information structure independently of
the access/transport of that information. This separation enables
scalability, customizability, and extensibility. Access to provide
or consume information is particularly suited to publish/subscribe/
query data transport and data access control models.
This graph model is a framework that:
o Facilitates the definition of extensible data types that support
SACM's use cases
o Provides a structure for the defined data types to be exchanged
via a variety of data transport models
o Describes components used in information exchange, and the objects
exchanged
o Captures and organizes evolving information and information
relationships for multiple data publishers
o Provides access to the published information via publish, query,
and subscribe operations
o Leverages the knowledge and experience gained from incorporating
TNC IF-MAP into many disparate products that have to integrate and
share an information model in a scalable, extensible manner
Waltermire, et al. Expires March 11, 2015 [Page 20]
Internet-Draft SACM Information Model September 2014
5.1. Background: Graph Models
Knowledge is often represented with graph-based formalisms. A common
formalism defines a graph as follows:
o A set of *vertices*
o A set of *edges*, each connecting two vertices (technically, an
edge is an ordered pair of vertices)
o A set of zero or more *properties* attached to each vertices and
edges. Each property consists of a type and a optionally a value.
The type and the value are typically just strings
+------------------+ +-----------------+
| Id: 1 | parent-of |Id: 2 |
| Given name: Sue | --------------> |Given name: Ann |
| Family name: Wong| |Family name: Wong|
+------------------+ +-----------------+
A VERTEX AN EDGE A VERTEX
Figure 2: Knowledge represented by a graph
A pair of vertices connected by an edge is commonly referred to as a
triple that comprises subject, predicate and object. For example,
subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A
common language that uses this representation is the Resource
Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225].
5.2. Graph Model Overview
The proposed model, influenced by IF-MAP, is a labeled graph: each
vertex has a label.
A table of synonyms follows.
+----------------+-----------------+--------------------------------+
| Graph Theory | Graph Databases | IF-MAP and This Internet Draft |
+----------------+-----------------+--------------------------------+
| Vertex or Node | Node | - |
| Label | - | Identifier |
| Edge | Edge | Link |
| - | Property | Metadata Item |
+----------------+-----------------+--------------------------------+
In this mode, identifiers and metadata have hierarchical structure.
Waltermire, et al. Expires March 11, 2015 [Page 21]
Internet-Draft SACM Information Model September 2014
The graphical aspect makes this model well suited to non-hierarchical
relationships, such as connectivity in a computer network.
Hierarchical properties allow this model to accommodate structures
such as YANG [RFC6020] data models.
5.3. Identifiers
Each identifier is an XML element. For extensibility, schemas use
xsd:anyAttribute and such.
Alternately, this model could be changed to use another hierarchical
notation, such as JSON.
Identifiers are unique: two different vertices cannot have equivalent
identifiers.
An identifier has a type. There is a finite, but extensible, set of
identifier types. If the identifier is XML, the type is based on the
XML schema.
In IF-MAP, standard identifier types include IP address, MAC address,
identity, and overlay network. Additional identifier types will need
to be standardized for SACM use cases.
Any number of metadata items can be attached to an identifier.
Some identifiers, especially those relating to identity, address, and
location, require the ability to specify an administrative domain
(such as AD domain, L2 broadcast domain / L3 routing domain, or
geographic domain) in order to differentiate between instances with
the same name occurring in different realms.
5.4. Links
A link can be thought of as an ordered pair of identifiers.
Any number of metadata items can be attached to a link.
5.5. Metadata
A metadata item is the basic unit of information, and is attached to
an identifier or to a link.
A given metadata item is an XML document. In IF-MAP metadata items
are generally small. However, larger ones, such as YANG data models,
can also fit. For extensibility, the XML schemas of metadata items
use xsd:anyAttribute and such.
Waltermire, et al. Expires March 11, 2015 [Page 22]
Internet-Draft SACM Information Model September 2014
Alternately, this model could be changed to use another hierarchical
notation, such as JSON.
A metadata item has a type. There is a finite, but extensible, set
of metadata types. If the metadata item is XML, the type is based on
the XML schema. An example metadata type is
http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device-
characteristic.
TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA]
define many pertinent metadata types. More will need to be
standardized for SACM use cases.
5.6. Use for SACM
Many of the information elements can be represented as vertices, and
many of the relationships can be represented as edges.
Identifiers are like database keys. For example, there would be
identifiers for addresses, identities, unique endpoint identifiers,
software component identifiers, and hardware component identifiers.
The inventory of software instances and hardware instances within an
endpoint might be expressed using a single YANG description, as a
single metadata item in the graph. Where to put Endpoint Attribute
Assertions, Evaluation Results, and the like is an open question.
5.7. Provenance
Provenance helps to protect the SACM ecosystem against a misled or
malicious provider.
The provenance of a metadata item includes:
o The time when the item was produced
o The component that produced the item, including its software and
version
o The policies that governed the producing component, with versions
o The method used to produce the information (e.g., vulnerability
scan)
How provenance should be expressed is an open question. For
reference, in IF-MAP provenance of a metadata item is expressed
within the metadata item [TNC-IF-MAP-NETSEC-METADATA]. For example,
there is a top-level XML attribute called "timestamp".
Waltermire, et al. Expires March 11, 2015 [Page 23]
Internet-Draft SACM Information Model September 2014
It is critical that provenance be secure from tampering. How to
achieve that security is out of scope of this document.
5.8. Extensibility
Anyone can define an identifier type or a metadata type, by creating
an XML schema (or other specification). There is no need for a
central authority. Some deployments may exercise administrative
control over the permitted identifier types and metadata types;
others may leave components free rein.
A community of components can agree on and use new identifier and
metadata types, if the administrators allow it. This allows rapid
innovation. Intermediate software that conveys graph changes from
one component to another does not need changes. Components that do
not understand the new types do not need changes. Accordingly, a
consumer normally ignores metadata types and identifier types it does
not understand.
As a proof point for this agility, the original use cases for TNC IF-
MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] were addressed in TNC
IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA].
Some years later an additional, major set of use cases, TNC IF-MAP
Metadata for ICS [TNC-IF-MAP-ICS-METADATA], were specified and
implemented.
6. SACM Usage Scenario Example
TODO: this section needs to refer out to wherever the operations /
generalized workflow content ends up
This section illustrates the proposed SACM Information Model as
applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations
[I-D.ietf-sacm-use-cases]. The following subsections describe the
elements (components and elements), graph model, and operations
(sample workflow) required to support the Detection of Posture
Deviations scenario.
The Detection of Posture Deviations scenario involves multiple
elements interacting to accomplish the goals of the scenario.
Figure 1 illustrates those elements along with their major
communication paths.
6.1. Graph Model for Detection of Posture Deviation
The following subsections contain examples of identifiers and
metadata which would enable detection of posture deviation. These
lists are by no means exhaustive - many other types of metadata would
Waltermire, et al. Expires March 11, 2015 [Page 24]
Internet-Draft SACM Information Model September 2014
be enumerated in a data model that fully addressed this usage
scenario.
6.1.1. Components
The proposed SACM Information Model contains three components, as
defined in the SACM Architecture [I-D.camwinget-sacm-architecture]:
Posture Attribute Information Provider, Posture Attribute Information
Consumer, and Control Plane.
In this example, the components are instantiated as follows:
o 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.
o 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.
o The Control Plane is a security automation broker which receives
subscription requests from the analytics engine and authorizes
access to appropriate information from the endpoint security
service.
6.1.2. Identifiers
To represent the elements listed above, the set of identifiers might
include (but is not limited to):
o Identity - a device itself, or a user operating a device,
categorized by type of credential (e.g. username or X.509
certificate [RFC5280])
o Software asset
o Network Session
o Address - categorized by type of address (e.g. MAC address, IP
address, Host Identity Protocol (HIP) Host Identity Tag (HIT)
[RFC5201], etc.)
o Task - categorized by type of task (e.g. internal collector,
external collector, evaluator, or reporting task)
o Result - categorized by type of result (e.g. evaluation result or
report)
Waltermire, et al. Expires March 11, 2015 [Page 25]
Internet-Draft SACM Information Model September 2014
o Guidance
6.1.3. Metadata
To characterize the elements listed above, the set of metadata types
might include (but is not limited to):
o 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.
o Location metadata attached to a link between a network session
identifier and an address identifier.
o 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.
o Posture attribute metadata attached to an identity identifier of
an endpoint. For example, when required security software is not
running, an internal collector associated with an endpoint
security service might publish posture attribute metadata attached
to the identity identifier of the endpoint, to notify consumers of
the current state of the endpoint.
6.1.4. Relationships between Identifiers and Metadata
Interaction between multiple sets of identifiers and metadata lead to
some fairly common patterns, or "constellations", of metadata. For
example, an authenticated-session metadata constellation might
include a central network session with authorizations and location
attached, and links to a user identity, an endpoint identity, a MAC
address, an IP address, and the identity of the policy server that
authorized the session, for the duration of the network session.
These constellations may be independent of each other, or one
constellation may be connected to another. For example, an
authenticated-session metadata constellation may be created when a
user connects an endpoint to the network; separately, an endpoint-
posture metadata constellation may be created when an endpoint
security system and other collectors gather and publish posture
information related to an endpoint. These two constellations are not
Waltermire, et al. Expires March 11, 2015 [Page 26]
Internet-Draft SACM Information Model September 2014
necessarily connected to each other, but may be joined if the
component publishing the authenticated-session metadata constellation
is able to link the network session identifier to the identity
identifier of the endpoint.
6.2. Workflow
The workflow for exchange of information supporting detection of
posture deviation, using a standard publish/subscribe/query transport
model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or
XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows:
1. The analytics engine (Posture Assessment Information Consumer)
establishes connectivity and authorization with the transport
fabric, and subscribes to updates on posture deviations.
2. The endpoint security service (Posture Assessment Information
Provider) requests connection to the transport fabric.
3. Transport fabric authenticates and establishes authorized
privileges (e.g. privilege to publish and/or subscribe to
security data) for the requesting components.
4. The endpoint security service evaluates the endpoint, detects
posture deviation, and publishes information on the posture
deviation.
5. The transport fabric notifies the analytics engine, based on its
subscription of the new posture deviation information.
Other components, such as access control policy servers or
remediation systems, may also consume the posture deviation
information provided by the endpoint security service.
7. Acknowledgements
Many of the specifications in this document have been developed in a
public-private partnership with vendors and end-users. The hard work
of the SCAP community is appreciated in advancing these efforts to
their current level of adoption.
Over the course of developing the initial draft, Henk Birkholz, Brant
Cheikes, Matt Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt,
and Steve Venema have contributed text to many sections of this
document.
Waltermire, et al. Expires March 11, 2015 [Page 27]
Internet-Draft SACM Information Model September 2014
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Posture Assessments need to be performed in a safe and secure manner.
In that regard, there are multiple aspects of security that apply to
the communications between components as well as the capabilities
themselves. Due to time constraints, this information model only
contains an initial listing of items that need to be considered with
respect to security. This list is not exhaustive, and will need to
be augmented as the model continues to be developed/refined.
Initial list of security considerations include:
Authentication: Every component and asset needs to be able to
identify itself and verify the identity of other components
and assets.
Confidentiality: Communications between components need to be
protected from eavesdropping or unauthorized collection.
Some communications between components and assets may need to
be protected as well.
Integrity: The information exchanged between components needs to be
protected from modification. some exchanges between assets
and components will also have this requirement.
Restricted Access: Access to the information collected, evaluated,
reported, and stored should only be viewable/consumable to
authenticated and authorized entities.
The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF-
MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]
document security considerations for sharing information via security
automation. Most, and possibly all, of these considerations also
apply to information shared via this proposed information model.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Waltermire, et al. Expires March 11, 2015 [Page 28]
Internet-Draft SACM Information Model September 2014
10.2. Informative References
[CCE] The National Institute of Standards and Technology,
"Common Configuration Enumeration", 2014,
<http://nvd.nist.gov/CCE/>.
[CCI] United States Department of Defense Defense Information
Systems Agency, "Control Correlation Identifier", 2014,
<http://iase.disa.mil/cci/>.
[CPE-WEBSITE]
The National Institute of Standards and Technology,
"Common Platform Enumeration", 2014,
<http://scap.nist.gov/specifications/cpe/>.
[CVE-WEBSITE]
The MITRE Corporation, "Common Vulnerabilities and
Exposures", 2014, <http://cve.mitre.org/about/>.
[I-D.camwinget-sacm-architecture]
Cam-Winget, N., Ford, B., llorenzin@juniper.net, l.,
McDonald, I., and l. loxx@cisco.com, "Secure Automation
and Continuous Monitoring (SACM) Architecture", draft-
camwinget-sacm-architecture-00 (work in progress), June
2014.
[I-D.camwinget-sacm-requirements]
Cam-Winget, N., "Secure Automation and Continuous
Monitoring (SACM) Requirements", draft-camwinget-sacm-
requirements-04 (work in progress), June 2014.
[I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf-
sacm-terminology-05 (work in progress), August 2014.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-07 (work in progress), April 2014.
[I-D.salowey-sacm-xmpp-grid]
Salowey, J., llorenzin@juniper.net, l., Kahn, C., Pope,
S., Appala, S., Woland, A., and N. Cam-Winget, "XMPP
Protocol Extensions for Use in SACM Information
Transport", draft-salowey-sacm-xmpp-grid-00 (work in
progress), July 2014.
Waltermire, et al. Expires March 11, 2015 [Page 29]
Internet-Draft SACM Information Model September 2014
[IM-LIAISON-STATEMENT-NIST]
Montville, A., "Liaison Statement: Call for Contributions
for the SACM Information Model to NIST", May 2014,
<http://datatracker.ietf.org/liaison/1329/>.
[ISO.18180]
"Information technology -- Specification for the
Extensible Configuration Checklist Description Format
(XCCDF) Version 1.2", ISO/IEC 18180, 2013,
<http://standards.iso.org/ittf/PubliclyAvailableStandards/
c061713_ISO_IEC_18180_2013.zip>.
[ISO.19770-2]
"Information technology -- Software asset management --
Part 2: Software identification tag", ISO/IEC 19770-2,
2009.
[NISTIR-7275]
Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring,
"Specification for the Extensible Configuration Checklist
Description Format (XCCDF) Version 1.2", NISTIR 7275r4,
March 2013, <http://csrc.nist.gov/publications/nistir/
ir7275-rev4/nistir-7275r4_updated-march-2012_clean.pdf>.
[NISTIR-7693]
Wunder, J., Halbardier, A., and D. Waltermire,
"Specification for Asset Identification 1.1", NISTIR 7693,
June 2011,
<http://csrc.nist.gov/publications/nistir/ir7693/
NISTIR-7693.pdf>.
[NISTIR-7694]
Halbardier, A., Waltermire, D., and M. Johnson,
"Specification for the Asset Reporting Format 1.1", NISTIR
7694, June 2011,
<http://csrc.nist.gov/publications/nistir/ir7694/
NISTIR-7694.pdf>.
[NISTIR-7695]
Cheikes, B., Waltermire, D., and K. Scarfone, "Common
Platform Enumeration: Naming Specification Version 2.3",
NISTIR 7695, August 2011,
<http://csrc.nist.gov/publications/nistir/ir7695/
NISTIR-7695-CPE-Naming.pdf>.
Waltermire, et al. Expires March 11, 2015 [Page 30]
Internet-Draft SACM Information Model September 2014
[NISTIR-7696]
Parmelee, M., Booth, H., Waltermire, D., and K. Scarfone,
"Common Platform Enumeration: Name Matching Specification
Version 2.3", NISTIR 7696, August 2011,
<http://csrc.nist.gov/publications/nistir/ir7696/
NISTIR-7696-CPE-Matching.pdf>.
[NISTIR-7697]
Cichonski, P., Waltermire, D., and K. Scarfone, "Common
Platform Enumeration: Dictionary Specification Version
2.3", NISTIR 7697, August 2011,
<http://csrc.nist.gov/publications/nistir/ir7697/
NISTIR-7697-CPE-Dictionary.pdf>.
[NISTIR-7698]
Waltermire, D., Cichonski, P., and K. Scarfone, "Common
Platform Enumeration: Applicability Language Specification
Version 2.3", NISTIR 7698, August 2011,
<http://csrc.nist.gov/publications/nistir/ir7698/
NISTIR-7698-CPE-Language.pdf>.
[NISTIR-7848]
Davidson, M., Halbardier, A., and D. Waltermire,
"Specification for the Asset Summary Reporting Format
1.0", NISTIR 7848, May 2012,
<http://csrc.nist.gov/publications/drafts/nistir-7848/
draft_nistir_7848.pdf>.
[OVAL-LANGUAGE]
Baker, J., Hansbury, M., and D. Haynes, "The OVAL Language
Specification version 5.10.1", January 2012,
<https://oval.mitre.org/language/version5.10.1/>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
Waltermire, et al. Expires March 11, 2015 [Page 31]
Internet-Draft SACM Information Model September 2014
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January
2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version
9", RFC 3954, October 2004.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect
(TNC)", RFC 5792, March 2010.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", RFC 5793, March 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
Waltermire, et al. Expires March 11, 2015 [Page 32]
Internet-Draft SACM Information Model September 2014
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, February
2013.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, May 2014.
[SP800-117]
Quinn, S., Scarfone, K., and D. Waltermire, "Guide to
Adopting and Using the Security Content Automation
Protocol (SCAP) Version 1.2", SP 800-117, January 2012,
<http://csrc.nist.gov/publications/drafts/800-117-R1/
Draft-SP800-117-r1.pdf>.
[SP800-126]
Waltermire, D., Quinn, S., Scarfone, K., and A.
Halbardier, "The Technical Specification for the Security
Content Automation Protocol (SCAP): SCAP Version 1.2", SP
800-126, September 2011,
<http://csrc.nist.gov/publications/nistpubs/800-126-rev2/
SP800-126r2.pdf>.
[TNC-Architecture]
Trusted Computing Group, ""TNC Architecture",
Specification Version 1.5", May 2012.
[TNC-IF-M-TLV-Binding]
Trusted Computing Group, ""TNC IF-M: TLV Binding",
Specification Version 1.0", May 2014.
[TNC-IF-MAP-ICS-METADATA]
Trusted Computing Group, ""TNC IF-MAP Metadata for ICS
Security", Specification Version 1.0", May 2014.
[TNC-IF-MAP-NETSEC-METADATA]
Trusted Computing Group, ""TNC IF-MAP Metadata for Network
Security", Specification Version 1.1", May 2012.
[TNC-IF-MAP-SOAP-Binding]
Trusted Computing Group, ""TNC IF-MAP Binding for SOAP",
Specification Version 2.2", March 2014.
[TNC-IF-T-TLS]
Trusted Computing Group, ""TNC IF-T: Binding to TLS",
Specification Version 2.0", February 2013.
Waltermire, et al. Expires March 11, 2015 [Page 33]
Internet-Draft SACM Information Model September 2014
[TNC-IF-T-Tunneled-EAP]
Trusted Computing Group, ""TNC IF-T: Protocol Bindings for
Tunneled EAP Methods", Specification Version 2.0", May
2014.
[TNC-IF-TNCCS-TLV-Binding]
Trusted Computing Group, ""TNC IF-TNCCS: TLV Binding",
Specification Version 2.0", May 2014.
[UML] Object Management Group, ""Unified Modeling Language TM
(UML (R))", Version 2.4.1", August 2011.
[W3C.REC-rdf11-concepts-20140225]
Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
Concepts and Abstract Syntax", World Wide Web Consortium
Recommendation REC-rdf11-concepts-20140225, February 2014,
<http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225>.
[W3C.REC-soap12-part1-20070427]
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.,
Nielsen, H., Karmarkar, A., and Y. Lafon, "SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)", World
Wide Web Consortium Recommendation REC-
soap12-part1-20070427, April 2007,
<http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
10.3. URIs
[1] https://github.com/OVALProject/Sandbox/blob/master/x-netconf-
definitions-schema.xsd
Appendix A. Security Automation with TNC IF-MAP
A.1. What is Trusted Network Connect?
Trusted Network Connect (TNC) is a vendor-neutral open architecture
[TNC-Architecture] and a set of open standards for network security
developed by the Trusted Computing Group (TCG). TNC standards
integrate security components across end user systems, servers, and
network infrastructure devices into an intelligent, responsive,
coordinated defense. TNC standards have been widely adopted by
vendors and customers; the TNC endpoint assessment protocols [TNC-IF-
M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-I
F-T-TLS] were used as the base for the IETF NEA RFCs
[RFC5792][RFC5793][RFC7171][RFC6876].
Traditional information security architectures have separate silos
for endpoint security, network security, server security, physical
Waltermire, et al. Expires March 11, 2015 [Page 34]
Internet-Draft SACM Information Model September 2014
security, etc. The TNC architecture enables the integration and
categorization of security telemetry sources via the information
model contained in its Interface for Metadata Access Points (IF-MAP)
[TNC-IF-MAP-SOAP-Binding]. IF-MAP provides a query-able repository
of security telemetry that may be used for storage or retrieval of
such data by multiple types of security systems and endpoints on a
vendor-neutral basis. The information model underlying the IF-MAP
repository covers, directly or indirectly, all of the security
information types required to serve SACM use-cases.
A.2. What is TNC IF-MAP?
IF-MAP provides a standard client-server protocol for MAP clients to
exchange security-relevant information via database server known as
the Metadata Access Point or MAP. The data (known as "metadata")
stored in the MAP is XML data. Each piece of metadata is tagged with
a metadata type that indicates the meaning of the metadata and
identifies an XML schema for it. Due to the XML language, the set of
metadata types is easily extensible.
The MAP is a graph database, not a relational database. Metadata can
be associated with an identifier (e.g. the email address
"user@example.com") or with a link between two identifiers (e.g. the
link between MAC address 00:11:22:33:44:55 and IPv4 address
192.0.2.1) where the link defines an association (for example: a
relation or state) between the identifiers. These links between
pairs of identifiers create an ad hoc graph of relationships between
identifiers. The emergent structure of this graph reflects a
continuously evolving knowledge base of security-related metadata
that is shared between various providers and consumers.
A.3. What is the TNC Information Model?
The TNC Information Model underlying IF-MAP relies on the graph
database architecture to enable a (potentially distributed) MAP
service to act as a shared clearinghouse for information that
infrastructure devices can act upon. The IF-MAP operations and
metadata schema specifications (TNC IF-MAP Binding for SOAP
[TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security
[TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS
Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of
identifiers and data types.
Each IF-MAP client may interact with the IF-MAP graph data store
through three fundamental types of operation requests:
o Publish, which may create, modify, or delete metadata associated
with one or more identifiers and/or links in the graph
Waltermire, et al. Expires March 11, 2015 [Page 35]
Internet-Draft SACM Information Model September 2014
o Search, which retrieves a selected sub-graph according to a set of
search criteria
o Subscribe, which allows a client to manage a set of search
commands which asynchronously return selected sub-graphs when
changes to that sub-graph are made by other IF-MAP clients
The reader is invited to review the existing IF-MAP specification
[TNC-IF-MAP-SOAP-Binding] for more details on the above graph data
store operation requests and their associated arguments.
The current IF-MAP specification provides a SOAP
[W3C.REC-soap12-part1-20070427] binding for the above operations, as
well as associated SOAP operations for managing sessions, error
handling, etc.
Appendix B. Text for Possible Inclusion in the Terminology Draft
B.1. Terms and Definitions
This section describes terms that have been defined by other RFCs and
Internet Drafts, as well as new terms introduced in this document.
B.1.1. Pre-defined and Modified Terms
This section contains pre-defined terms that are sourced from other
IETF RFCs and Internet Drafts. Descriptions of terms in this section
will reference the original source of the term and will provide
additional specific context for the use of each term in SACM. For
sake of brevity, terms from [I-D.ietf-sacm-terminology] are not
repeated here unless the original meaning has been changed in this
document.
Asset For this Information Model it is necessary to change the
scope of the definition of asset from the one provided in
[I-D.ietf-sacm-terminology]. Originally defined in [RFC4949]
and referenced in [I-D.ietf-sacm-terminology] as "a system
resource that is (a) required to be protected by an
information system's security policy, (b) intended to be
protected by a countermeasure, or (c) required for a system's
mission." This definition generally relates to an "IT
Asset", which in the context of this document is overly
limiting. For use in this document, a broader definition of
the term is needed to represent non-IT asset types as well.
In [NISTIR-7693] an asset is defined as "anything that has
value to an organization, including, but not limited to,
another organization, person, computing device, information
Waltermire, et al. Expires March 11, 2015 [Page 36]
Internet-Draft SACM Information Model September 2014
technology (IT) system, IT network, IT circuit, software
(both an installed instance and a physical instance), virtual
computing platform (common in cloud and virtualized
computing), and related hardware (e.g., locks, cabinets,
keyboards)." This definition aligns better with common
dictionary definitions of the term and better fits the needs
of this document.
B.1.2. New Terms
IT Asset Originally defined in [RFC4949] as "a system resource that
is (a) required to be protected by an information system's
security policy, (b) intended to be protected by a
countermeasure, or (c) required for a system's mission."
Security Content Automation Protocol (SCAP) According to SP800-126,
SCAP, pronounced "ess-cap", is "a suite of specifications
that standardize the format and nomenclature by which
software flaw and security configuration information is
communicated, both to machines and humans." SP800-117
revision 1 [SP800-117] provides a general overview of SCAP
1.2. The 11 specifications that comprise SCAP 1.2 are
synthesized by a master specification, SP800-126 revision 2
[SP800-126], that addresses integration of the specifications
into a coherent whole. The use of "protocol" in its name is
a misnomer, as SCAP defines only data models. SCAP has been
adopted by a number of operating system and security tool
vendors.
Appendix C. Text for Possible Inclusion in the Architecture or Use
Cases
C.1. Introduction
The posture of an endpoint is the status of the endpoint with respect
to the security policies and risk models of the organization.
A system administrator needs to be able to determine which elements
of an endpoint have a security problem and which do not conform the
organization's security policies. The CIO needs to be able to
determine whether endpoints have security postures that conform to
the organization's policies to ensure that the organization is
complying with its fiduciary and regulatory responsibilities. The
regulator or auditor needs to be able to assess the level of due
diligence being achieved by an organization to ensure that all
regulations and due diligence expectations are being met. The
Waltermire, et al. Expires March 11, 2015 [Page 37]
Internet-Draft SACM Information Model September 2014
operator needs to understand which assets have deviated from
organizational policies so that those assets can be remedied.
Operators will focus on which endpoints are composed of specific
assets with problems. CIO and auditors need a characterization of
how an organization is performing as a whole to manage the posture of
its endpoints. All of these actors need deployed capabilities that
implement security automation standards in the form of data formats,
interfaces, and protocols to be able to assess, in a timely and
secure fashion, all assets on all endpoints within their enterprise.
This information model provides a basis to identify the desirable
characteristics of data models to support these scenarios. Other
SACM specifications, such as the SACM Architecture, will describe the
potential components of an interoperable system solution based on the
SACM information model to address the requirements for scalability,
timeliness, and security.
C.2. Core Principles
This information model is built on the following core principles:
o Collection and Evaluation are separate tasks.
o Collection and Evaluation can be performed on the endpoint, at a
local server that communicates directly with the endpoint, or
based on data queried from a back end data store that does not
communicate directly with any endpoints.
o Every entity (human or machine) that notifies, queries, or
responds to any guidance, collection, or evaluator must have a way
of identifying itself and/or presenting credentials.
Authentication is a key step in all of the processes, and while
needed to support the business processes, information needs to
support authentication are not highlighted in this information
model. There is already a large amount of existing work that
defines information needs for authentication.
o Policies are reflected in guidance for collection, evaluation, and
reporting.
o Guidance will often be generated by humans or through the use of
transformations on existing automation data. In some cases,
guidance will be generated dynamically based on shared information
or current operational needs. As guidance is created it will be
published to an appropriate guidance data store allowing guidance
to be managed in and retrieved from convenient locations.
Waltermire, et al. Expires March 11, 2015 [Page 38]
Internet-Draft SACM Information Model September 2014
o Operators of a continuous monitoring or security automation system
will need to make decisions when defining policies about what
guidance to use or reference. The guidance used may be directly
associated with policy or may be queried dynamically based on
associated metadata.
o Guidance can be gathered from multiple data stores. It may be
retrieved at the point of use or may be packaged and forwarded for
later use. Guidance may be retrieved in event of a collection or
evaluation trigger or it may be gathered ahead of time and stored
locally for use/reference during collection and evaluation
activities.
C.3. Architecture Assumptions
This information model will focus on WHAT information needs to be
exchanged to support the business process areas. The architecture
document is the best place to represent the HOW and the WHERE this
information is used. In an effort to ensure that the data models
derived from this information model scale to the architecture, four
core architectural components need to be defined. They are
producers, consumers, capabilities, and repositories. These elements
are defined as follows:
o Producers (e.g., Evaluation Producer) collect, aggregate, and/or
derive information items and provide them to consumers. For this
model there are Collection, Evaluation, and Results Producers.
There may or may not be Guidance Producers.
o Consumers (e.g., Collection Consumer) request and/or receive
information items from producers for their own use. For this
model there are Collection, Evaluation, and Results Consumers.
There may or may not be Guidance Consumers.
o Capabilities (e.g., Posture Evaluation Capability) take the input
from one or more producers and perform some function on or with
that information. For this model there are Collection Guidance,
Collection, Evaluation Guidance, Evaluation, Reporting Guidance,
and Results Reporting Capabilities.
o Repositories (e.g., Enterprise Repository) store information items
that are input to or output from Capabilities, Producers, and
Consumers. For this model we refer to generic Enterprise and
Guidance Repositories.
Information that needs to be communicated by or made available to any
of these components will be specified in each of the business process
areas.
Waltermire, et al. Expires March 11, 2015 [Page 39]
Internet-Draft SACM Information Model September 2014
In the most trivial example, illustrated in Figure 3, Consumers
either request information from, or are notified by, Producers.
+----------+ Request +----------+
| <-----------------+ |
| Producer | | Consumer |
| +-----------------> |
+----------+ Response +----------+
+----------+ +----------+
| | Notify | |
| Producer +-----------------> Consumer |
| | | |
+----------+ +----------+
Figure 3: Example Producer/Consumer Interactions
As illustrated in Figure 4, writing and querying from data
repositories are a way in which this interaction can occur in an
asynchronous fashion.
+----------+ +----------+
| | | |
| Producer | | Consumer |
| | | |
+-----+----+ +----^-----+
| |
Write | +------------+ | Query
| | | |
+-----> Repository +-------+
| |
+------------+
Figure 4: Producer/Consumer Repository Interaction
To perform an assessment, these elements are chained together. The
diagram below is illustrative of this and process, and is meant to
demonstrate WHAT basic information exchanges need to occur, while
trying to maintain flexibility in HOW and WHERE they occur.
For example:
o the collection capability can reside on the endpoint or not.
o the collection producer can be part of the collection capability
or not.
Waltermire, et al. Expires March 11, 2015 [Page 40]
Internet-Draft SACM Information Model September 2014
o a repository can be directly associated with a producer and/or an
evaluator or stand on its own.
o there can be multiple "levels" of producers and consumers.
Waltermire, et al. Expires March 11, 2015 [Page 41]
Internet-Draft SACM Information Model September 2014
+-------------+
|Evaluation |
+-------------+ |Guidance +--+
|Endpoint | |Capability | |
+-------+ | +-------------+ |
| | | |
| +-------+-----+ +-----v-------+
| Collection | |Evaluation |
+-> Capability +--+--------+ |Capability |
| | |Collection | +-----------+ +----------+
| +------------+Producer | | |---| |
| | | |Collection | |Evaluation|
| | | |Consumer | |Producer |
| +----+------+ +----^------+ +---+------+
++---------+ | | |
|Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | |
|Capability| |Collection | |Producer | |
| | |Consumer |-----| | |
+----------+ +------------+ +------------+ |
| Collection | |
| Repository | |
+------------+ |
|
+--------------+ +---------------+ |
|Evaluation | |Evaluation | |
|Results | |Consumer <-----+
|Producer |-----------| |
+-----+--------+ +---------------+
| |Results Reporting|
| |Capability |
| +------------^----+
| |
+-----v--------+ +----+------+
|Evaluation | |Reporting |
|Results | |Guidance |
|Consumer | |Repository |
+---+----------+ +-----------+ +-------------+
| | Results |
+-----------------------------> Repository |
| |
+-------------+
Figure 5: Producer/Consumer Complex Example
This illustrative example in Figure 5 provides a set of information
exchanges that need to occur to perform a posture assessment. The
rest of this information model is using this set of exchanges based
Waltermire, et al. Expires March 11, 2015 [Page 42]
Internet-Draft SACM Information Model September 2014
on these core architectural components as the basis for determining
information elements.
Appendix D. Text for Possible Inclusion in the Requirements Draft
D.1. Problem Statement
Scalable and sustainable collection, expression, and evaluation of
endpoint information is foundational to SACM's objectives. To secure
and defend one's network one must reliably determine what devices are
on the network, how those devices are configured from a hardware
perspective, what software products are installed on those devices,
and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture
assessments.
D.2. Problem Scope
The goal of this iteration of the information model is to define the
information needs for an organization to effectively monitor the
endpoints operating on their network, the software installed on those
endpoints, and the configuration of that software. Once we have
those three business processes in place, we can identify vulnerable
endpoints in a very efficient manner.
The four business process areas represent a large set of tasks that
support endpoint posture assessment. In an effort to address the
most basic and foundational needs, we have also narrowed down the
scope inside of each of the business processes to a set of defined
tasks that strive to achieve specific results in the operational
environment and the organization. These tasks are:
1. Define the assets. This is what we want to know about an asset.
For instance, organizations will want to know what software is
installed and its many critical security attributes such as patch
level.
2. Resolve what assets compose an endpoint. This requires
populating the data elements and attributes needed to exchange
information pertaining to the assets composing an endpoint.
3. Express what expected values for the data elements and attributes
need to be evaluated against the actual collected instances of
asset data. This is how an organization can express its policy
for an acceptable data element or attribute value. A system
administrator can also identify specific data elements and
Waltermire, et al. Expires March 11, 2015 [Page 43]
Internet-Draft SACM Information Model September 2014
attributes that represent problems, such as vulnerabilities, that
need to be detected on an endpoint.
4. Evaluate the collected instances of the asset data against those
expressed in the policy.
5. Report the results of the evaluation.
Appendix E. Text With No Clear Home Yet
E.1. Operations
Operations that may be carried out the proposed SACM Information
Model are:
o Publish data: Security information is made available in the
information model when a component publishes data to it.
o Subscribe to data: A component seeking to consume an on-going
stream of security information "subscribes" to such data from the
information model.
o Query: This operation enables a component to request a specific
set of security data regarding a specific asset (such as a
specific user endpoint).
The subscribe capability will allow SACM components to monitor for
selected security-related changes in the graph data store without
incurring the performance penalties associated with polling for such
changes.
E.1.1. Generalized Workflow
The proposed SACM Information Model would be most commonly used with
a suitable transport protocol for collecting and distributing
security data across appropriate network platforms and endpoints.
The information model is transport agnostic and can be used with its
native transport provided by IF-MAP or by other data transport
protocols such as the recently proposed XMPP-Grid.
1. A Posture Assessment Information Consumer (Consumer) establishes
connectivity and authorization with the transport fabric.
2. A Posture Assessment Information Provider (Provider) with a
source of security data requests connection to the transport
fabric.
Waltermire, et al. Expires March 11, 2015 [Page 44]
Internet-Draft SACM Information Model September 2014
3. Transport fabric authenticates and establishes authorized
privileges (e.g. privilege to publish and/or subscribe to
security data) for the requesting components.
4. Components may either publish security data, subscribe to
security data, query for security data, or any combination of
these operations.
Any component sharing information - either as Provider or Consumer -
may do so on a one-to-one, one-to-many and/or many-to-many meshed
basis.
E.2. From Information Needs to Information Elements
The previous sections highlighted information needs for a set of
management process areas that use posture assessment to achieve
organizational security goals. A single information need may be made
up of multiple information elements. Some information elements may
be required for two different process areas, resulting in two
different requirements. In an effort to support the main idea of
collect once and reuse the data to support multiple processes, we try
to define a singular set of information elements that will support
all the associated information needs.
E.3. Information Model Elements
TODO: Kim to pull up relevant content into section 4 / Elements
Traditionally, one would use the SACM architecture to define
interfaces that required information exchanges. Identified
information elements would then be based on those exchanges. Because
the SACM architecture document is still in the personal draft stage,
this information model uses a different approach to the
identification of information elements. First it lists the four main
endpoint posture assessment activities. Then it identifies
management process areas that use endpoint posture assessment to
achieve organizational security objectives. These process areas were
then broken down into operations that mirrored the typical workflow
from the SACM Use Cases draft [I-D.ietf-sacm-use-cases]. These
operations identify architectural components and their information
needs. In this section, information elements derived from those
information needs are mapped back to the four main activities listed
above.
The original liaison statement [IM-LIAISON-STATEMENT-NIST] requested
contributions for the SACM information model in the four areas
described below. Based on the capabilities defined previously in
this document, the requested areas alone do not provide a sufficient
Waltermire, et al. Expires March 11, 2015 [Page 45]
Internet-Draft SACM Information Model September 2014
enough categorization of the necessary information model elements.
The following sub-sections directly address the requested areas as
follows:
1. Endpoint Identification
A. Appendix E.3.1 Asset Identifiers: Describes identification of
many different asset types including endpoints.
2. Endpoint Characterization
A. Appendix E.3.3 Endpoint characterization: This directly maps
to the requested area.
3. Endpoint Attribute Expression/Representation
A. Appendix E.3.4 Posture Attribute Expression: This corresponds
to the first part of "Endpoint Attribute Expression/
Representation."
B. Appendix E.3.5 Actual Value Representation: This corresponds
to the second part of "Endpoint Attribute Expression/
Representation."
4. Policy evaluation expression and results reporting
A. Appendix E.3.6 Evaluation Guidance: This corresponds to the
first part of "Policy evaluation expression and results
reporting."
B. Appendix E.3.7 Evaluation Result Reporting: corresponds to
the second part of "Policy evaluation expression and results
reporting."
Additionally, Appendix E.3.2 Other Identifiers: describes other
important identification concepts that were not directly requested by
the liaison statement.
Per the liaison statement, each subsection references related work
that provides a basis for potential data models. Some analysis is
also included for each area of related work on how directly
applicable the work is to the SACM efforts. In general, much of the
related work does not fully address the general or use case-based
requirements for SACM, but they do contain some parts that can be
used as the basis for data models that correspond to the information
model elements. In these cases additional work will be required by
the WG to adapt the specification. In some cases, existing work can
largely be used in an unmodified fashion. This is also indicated in
Waltermire, et al. Expires March 11, 2015 [Page 46]
Internet-Draft SACM Information Model September 2014
the analysis. Due to time constraints, the work in this section is
very biased to previous work supported by the authors and does not
reflect a comprehensive listing. An attempt has been made where
possible to reference existing IETF work. Additional research and
discussion is needed to include other related work in standards and
technology communities that could and should be listed here. The
authors intend to continue this work in subsequent revisions of this
draft.
Where possible when selecting and developing data models in support
of these information model elements, extension points and IANA
registries SHOULD be used to provide for extensibility which will
allow for future data models to be addressed.
E.3.1. Asset Identifiers
In this context an "asset" refers to "anything that has value to an
organization" (see [NISTIR-7693]). This use of the term "asset" is
broader than the current definition in [I-D.ietf-sacm-terminology].
To support SACM use cases, a number of different asset types will
need to addressed. For each type of asset, one or more type of asset
identifier will be needed for use in establishing contextual
relationships within the SACM information model. The following asset
types are referenced or implied by the SACM use cases:
Endpoint: Identifies an individual endpoint for which posture is
collected and evaluated.
Hardware: Identifies a given type of hardware that may be installed
within an endpoint.
Software: Identifies a given type of software that may be installed
within an endpoint.
Network: Identifies a network for which a given endpoint may be
connected or request a connection to.
Organization: Identifies an organizational unit.
Person: Identifies an individual, often within an organizational
context.
E.3.1.1. Related Work
Waltermire, et al. Expires March 11, 2015 [Page 47]
Internet-Draft SACM Information Model September 2014
E.3.1.1.1. Asset Identification
The Asset Identification specification [NISTIR-7693] is an XML-based
data model that "provides the necessary constructs to uniquely
identify assets based on known identifiers and/or known information
about the assets." Asset identification plays an important role in
an organization's ability to quickly correlate different sets of
information about assets. The Asset Identification specification
provides the necessary constructs to uniquely identify assets based
on known identifiers and/or known information about the assets.
Asset Identification provides a relatively flat and extensible model
for capturing the identifying information about a one or more assets,
and also provides a way to represent relationships between assets.
The model is organized using an inheritance hierarchy of specialized
asset types/classes (see Figure 6), providing for extension at any
level of abstraction. For a given asset type, a number of properties
are defined that provide for capturing identifying characteristics
and the referencing of namespace qualified asset identifiers, called
"synthetic IDs."
The following figure illustrates the class hierarchy defined by the
Asset Identification specification.
asset
+-it-asset
| +-circuit
| +-computing-device
| +-database
| +-network
| +-service
| +-software
| +-system
| +-website
+-data
+-organization
+-person
Figure 6: Asset Identification Class Hierarchy
Waltermire, et al. Expires March 11, 2015 [Page 48]
Internet-Draft SACM Information Model September 2014
This table presents a mapping of notional SACM asset types to those
asset types provided by the Asset Identification specification.
+--------------+------------------+---------------------------------+
| SACM Asset | Asset | Notes |
| Type | Identification | |
| | Type | |
+--------------+------------------+---------------------------------+
| Endpoint | computing-device | This is not a direct mapping |
| | | since a computing device is not |
| | | required to have network- |
| | | connectivity. Extension will be |
| | | needed to define a directly |
| | | aligned endpoint asset type. |
+--------------+------------------+---------------------------------+
| Hardware | Not Applicable | The concept of hardware is not |
| | | addressed by the asset |
| | | identification specification. |
| | | An extension can be created |
| | | based on the it-asset class to |
| | | address this concept. |
+--------------+------------------+---------------------------------+
| Software | software | Direct mapping. |
+--------------+------------------+---------------------------------+
| Network | network | Direct mapping. |
+--------------+------------------+---------------------------------+
| Organization | organization | Direct mapping. |
+--------------+------------------+---------------------------------+
| Person | person | Direct mapping. |
+--------------+------------------+---------------------------------+
Table 1: Mapping of SACM to Asset Identification Asset Types
This specification has been adopted by a number of SCAP validated
products. It can be used to address asset identification and
categorization needs within SACM with minor modification.
E.3.1.2. Endpoint Identification
An unique name for an endpoint. This is a foundational piece of
information that will enable collected posture attributes to be
related to the endpoint from which they were collected. It is
important that this name either be created from, provide, or be
associated with operational information (e.g., MAC address, hardware
certificate) that is discoverable from the endpoint or its
communications on the network. It is also important to have a method
of endpoint identification that can persist across network sessions
to allow for correlation of collected data over time.
Waltermire, et al. Expires March 11, 2015 [Page 49]
Internet-Draft SACM Information Model September 2014
E.3.1.2.1. Related Work
The previously introduced asset identification specification (see
Appendix E.3.1.1.1 provides a basis for endpoint identification using
the "computing-device" class. While the meaning of this class is
broader than the current definition of an endpoint in the SACM
terminology [I-D.ietf-sacm-terminology], either that class or an
appropriate sub-class extension can be used to capture identification
information for various endpoint types.
E.3.1.3. Software Identification
A unique name for a unit of installable software. Software names
should generally represent a unique release or installable version of
software. Identification approaches should allow for identification
of commercially available, open source, and organizationally
developed custom software. As new software releases are created, a
new software identifier should be created by the releasing party
(e.g., software creator, publisher, licensor). Such an identifier is
useful to:
o Relate metadata that describes the characteristics of the unit of
software, potentially stored in a repository of software
information. Typically, the software identifier would be used as
an index into such a repository.
o Indicate the presence of the software unit on a given endpoint.
o To determine what endpoints are the targets for an assessment
based on what software is installed on that endpoint.
o Define guidance related to a software unit that represents
collection, evaluation, or other automatable policies.
In general, an extensible method of software identification is needed
to provide for adequate coverage and to address legacy identification
approaches. Use of an IANA registry supporting multiple software
identification methods would be an ideal way forward.
E.3.1.3.1. Related Work
While we are not aware of a one-size-fits-all solution for software
identification, there are two existing specifications that should be
considered as part of the solution set. They are described in the
following subsections.
Waltermire, et al. Expires March 11, 2015 [Page 50]
Internet-Draft SACM Information Model September 2014
E.3.1.3.1.1. Common Platform Enumeration
E.3.1.3.1.1.1. Background
The Common Platform Enumeration (CPE) [CPE-WEBSITE] is composed of a
family of four specification that are layered to build on lower-level
functionality. The following describes each specification:
1. CPE Naming: A standard machine-readable format [NISTIR-7695] for
encoding names of IT products and platforms. This defines the
notation used to encode the vendor, software name, edition,
version and other related information for each platform or
product. With the 2.3 version of CPE, a second, more advanced
notation was added to the original colon-delimited notation for
CPE naming.
2. CPE Matching: A set of procedures [NISTIR-7696] for comparing
names. This describes how to compare two CPE names to one
another. It describes a logical method that ensures that
automated systems comparing two CPE names would arrive at the
same conclusion.
3. CPE Applicability Language: An XML-based language [NISTIR-7698]
for constructing "applicability statements" that combine CPE
names with simple logical operators.
4. CPE Dictionary: An XML-based catalog format [NISTIR-7697] that
enumerates CPE Names and associated metadata. It details how to
encode the information found in a CPE Dictionary, thereby
allowing multiple organizations to maintain compatible CPE
Dictionaries.
The primary use case of CPE is for exchanging software inventory
data, as it allows the usage of unique names to identify software
platforms and products present on an endpoint. The NIST currently
maintains and updates a dictionary of all agreed upon CPE names, and
is responsible for ongoing maintenance of the standard. Many of the
names in the CPE dictionary have been provided by vendors and other
3rd-parties.
While the effort has seen wide adoption, most notably within the US
Government, a number of critical flaws have been identified. The
most critical issues associated with the effort are:
o Because there is no requirement for vendors to publish their own,
official CPE names, CPE necessarily requires one or more
organizations for curation. This centralized curation requirement
ensures that the effort has difficulty scaling.
Waltermire, et al. Expires March 11, 2015 [Page 51]
Internet-Draft SACM Information Model September 2014
o Not enough primary source vendors provide platform and product
naming information. As a result, this pushes too much of the
effort out onto third-party groups and non-authoritative
organizations. This exacerbates the ambiguity in names used for
identical platforms and products and further reduces the utility
of the effort.
E.3.1.3.1.1.2. Applicability to Software Identification
The Common Platform Enumeration (CPE) Naming specification version
2.3 defines a scheme for human-readable standardized identifiers of
hardware and software products.
CPE names are the identifier format for software and hardware
products used in SCAP 1.2 and is currently adopted by a number of
SCAP product vendors.
CPE names can be directly referenced in the asset identification
software class (see Appendix E.3.1.1.1.)
Although relevant, CPE has an unsustainable maintenance "tail" due to
the need for centralized curation and naming-consistency enforcement.
Its mention in this document is to support the historic inclusion of
CPE as part of SCAP and implementation of this specification in a
number of security processes and products. Going forward, software
identification (SWID) tags are recommended as a replacement for CPE.
To this end, work has been started to align both efforts to provide
translation for software units identified using SWID tags to CPE
Names. This translation would allow tools that currently use CPE-
based identifiers to map to SWID identifiers during a transition
period.
E.3.1.3.1.2. Software Identification (SWID) Tags
The software identification tag specification [ISO.19770-2] is an
XML-based data model that is used to describe a unit of installable
software. A SWID tag contains data elements that:
o Identify a specific unit of installable software,
o Enable categorization of the software (e.g., edition, bundle),
o Identification and hashing of software artifacts (e.g.,
executables, shared libraries),
o References to related software and dependencies, and
o Inclusion of extensible metadata.
Waltermire, et al. Expires March 11, 2015 [Page 52]
Internet-Draft SACM Information Model September 2014
SWID tags can be associated with software installation media,
installed software, software updates (e.g., service packs, patches,
hotfixes), and redistributable components. SWID tags also provide
for a mechanism to relate these concepts to each other. For example,
installed software can be related back to the original installation
media, patches can be related to the software that they patch, and
software dependencies can be described for required redistributable
components. SWID tags are ideally created at build-time by the
software creator, publisher or licensor; are bundled with software
installers; and are deployed to an endpoint during software
installation.
SWID tags should be considered for two primary uses:
1. As the data format for exchanging descriptive information about
software products, and
2. As the source of unique identifiers for installed software.
In addition to usage for software identification, a SWID tag can
provide the necessary data needed to target guidance based on
included metadata, and to support verification of installed software
and software media using cryptographic hashes. This added
information increases the value of using SWID tags as part of the
larger security automation and continuous monitoring solution space.
E.3.1.4. Hardware Identification
Due to the time constraints, research into information elements and
related work for identifying hardware is not included in this
revision of the information model.
E.3.2. Other Identifiers
In addition to identifying core asset types, it is also necessary to
have stable, globally unique identifiers to represent other core
concepts pertaining to posture attribute collection and evaluation.
The concept of "global uniqueness" ensures that identifiers provided
by multiple organization do not collide. This may be handled by a
number of different mechanisms (e.g., use of namespaces).
E.3.2.1. Platform Configuration Item Identifier
A name for a low-level, platform-dependent configuration mechanism as
determined by the authoritative primary source vendor. New
identifiers will be created when the source vendor makes changes to
the underlying platform capabilities (e.g., adding new settings,
replacing old settings with new settings). When created each
Waltermire, et al. Expires March 11, 2015 [Page 53]
Internet-Draft SACM Information Model September 2014
identifier should remain consistent with regards to what it
represents. Generally, a change in meaning would constitute the
creation of a new identifier.
For example, if the configuration item is for "automatic execution of
code", then the platform vendor would name the low-level mechanism
for their platform (e.g., autorun for mounted media).
E.3.2.1.1. Related Work
E.3.2.1.1.1. Common Configuration Enumeration
The Common Configuration Enumeration (CCE) [CCE] is an effort managed
by NIST. CCE provides a unique identifier for platform-specific
configuration items that facilitates fast and accurate correlation of
configuration items across multiple information sources and tools.
CCE does this by providing an identifier, a human readable
description of the configuration control, parameters needed to
implement the configuration control, various technical mechanisms
that can be used to implement the configuration control, and
references to documentation that describe the configuration control
in more detail.
By vendor request, NIST issues new blocks of CCE identifiers.
Vendors then populate the required fields and provided the details
back to NIST for publication in the "CCE List", a consolidated
listing of assigned CCE identifiers and associated data. Many
vendors also include references to these identifiers in web pages,
SCAP content, and prose configuration guides they produce.
CCE the identifier format for platform specific configuration items
in SCAP and is currently adopted by a number of SCAP product vendors.
While CCE is largely supported as a crowd-sourced effort, it does
rely on a central point of coordination for assignment of new CCE
identifiers. This approach to assignment requires a single
organization, currently NIST, to manage allocations of CCE
identifiers which doesn't scale well and introduces sustainability
challenges for large volumes of identifier assignment. If this
approach is used going forward by SACM, a namespaced approach is
recommended for identifier assignment that allows vendors to manage
their own namespace of CCE identifiers. This change would require
additional work to specify and implement.
Waltermire, et al. Expires March 11, 2015 [Page 54]
Internet-Draft SACM Information Model September 2014
E.3.2.1.1.2. Open Vulnerability and Assessment Language
E.3.2.1.1.2.1. Background
The Open Vulnerability and Assessment Language (OVAL(R)) is an XML
schema-based data model developed as part of a public-private
information security community effort to standardize how to assess
and report upon the security posture of endpoints. OVAL provides an
established framework for making assertions about an endpoint's
posture by standardizing the three main steps of the assessment
process:
1. representing the current endpoint posture;
2. analyzing the endpoint for the presence of the specified posture;
and
3. representing the results of the assessment.
OVAL facilitates collaboration and information sharing among the
information security community and interoperability among tools.
OVAL is used internationally and has been implemented by a number of
operating system and security tools vendors.
Waltermire, et al. Expires March 11, 2015 [Page 55]
Internet-Draft SACM Information Model September 2014
The following figure illustrates the OVAL data model.
+------------+
+-----------------+ | Variables |
| Common <---+ |
+--------> | +------------+
| | | +------------+
| | <---+ Directives |
| +--------^----^---+ | |
| | | +--------+---+
| | +-----+ |
| | | |
| +--------+--------+ | |
| | System | | |
| | Characteristics | | |
+------+------+ | | | +--------v---+
| Definitions | | | | | Results |
| | +--------^--------+ +-+ |
| | | | |
| | +------------+ |
+------^------+ +-------+----+
| |
+--------------------------------------+
Note: The direction of the arrows indicate a model dependency
Figure 7: The OVAL Data Model
The OVAL data model [OVAL-LANGUAGE], visualized in Figure 7, is
composed of a number of different components. The components are:
o Common: Constructs, enumerations, and identifier formats that are
used throughout the other model components.
o Definitions: Constructs that describe assertions about system
state. This component also includes constructs for internal
variable creation and manipulation through a variety of functions.
The core elements are:
* Definition: A collection of logical statements that are
combined to form an assertion based on endpoint state.
* Test(platform specific): A generalized construct that is
extended in platform schema to describe the evaluation of
expected against actual state.
Waltermire, et al. Expires March 11, 2015 [Page 56]
Internet-Draft SACM Information Model September 2014
* Object(platform specific): A generalized construct that is
extended in platform schema to describe a collectable aspect of
endpoint posture.
* State(platform specific): A generalized construct that is
extended in platform schema to describe a set of criteria for
evaluating posture attributes.
o Variables: Constructs that allow for the parameterization of the
elements used in the Definitions component based on externally
provided values.
o System Characteristics: Constructs that represent collected
posture from one or more endpoints. This element may be embedded
with the Results component, or may be exchanged separately to
allow for separate collection and evaluation. The core elements
of this component are:
* CollectedObject: Provides a mapping of collected Items to
elements defined in the Definitions component.
* Item(platform specific): A generalized construct that is
extended in platform schema to describe specific posture
attributes pertaining to an aspect of endpoint state.
o Results: Constructs that represent the result of evaluating
expected state (state elements) against actual state (item
elements). It includes the true/false evaluation result for each
evaluated Definition and Test. Systems characteristics are
embedded as well to provide low-level posture details.
o Directives: Constructs that enable result reporting detail to be
declared, allowing for result production to customized.
End-user organizations and vendors create assessment guidance using
OVAL by creating XML instances based on the XML schema implementation
of the OVAL Definitions model. The OVAL Definitions model defines a
structured identifier format for each of the Definition, Test,
Object, State, and Item elements. Each instantiation of these
elements in OVAL XML instances are assigned a unique identifier based
on the specific elements identifier syntax. These XML instances are
used by tools that support OVAL to drive collection and evaluation of
endpoint posture. When posture collection is performed, an OVAL
Systems Characteristics XML instance is generated based on the
collected posture attributes. When this collected posture is
evaluated, an OVAL Result XML instance is generated that contains the
results of the evaluation. In most implementations, the collection
and evaluation is performed at the same time.
Waltermire, et al. Expires March 11, 2015 [Page 57]
Internet-Draft SACM Information Model September 2014
Many of the elements in the OVAL model (i.e., Test, Object, State,
Item) are abstract, requiring a platform-specific schema
implementation, called a "Component Model" in OVAL. These platform
schema implementations are where platform specific posture attributes
are defined. For each aspect of platform posture a specialized OVAL
Object, which appears in the OVAL Definitions model, provides a
format for expressing what posture attribute data to collect from an
endpoint through the specification of a datatype, operation, and
value(s) on entities that uniquely identify a platform configuration
item. For example, a hive, key, and name is used to identify a
registry key on a Windows endpoint. Each specialized OVAL Object has
a corresponding specialized State, which represents the posture
attributes that can be evaluated, and an Item which represents the
specific posture attributes that can be collected. Additionally, a
specialized Test exists that allows collected Items corresponding to
a CollectedObject to be evaluated against one or more specialized
States of the same posture type.
The OVAL language provides a generalized approach suitable for
posture collection and evaluation. While this approach does provide
for a degree of extensibility, there are some concerns that should be
addressed in order to make OVAL a viable basis for SACM's use. These
concerns include:
o Platform Schema Creation and Maintenance: In OVAL platform schema,
the OVAL data model maintains a tight binding between the Test,
Object, State, and Item elements used to assess an aspect of
endpoint posture. Creating a new platform schema or adding a new
posture aspect to an existing platform schema can be a very labor
intensive process. Doing so often involves researching and
understanding system APIs and can be prone to issues with
inconsistency within and between platforms. To simplify platform
schema creation and maintenance, the model needs to be evolved to
generalize the Test, Object, and State elements, requiring only
the definition of an Item representation.
o Given an XML instance based on the Definitions model, it is not
clear in the specification how incremental collection and
evaluation can occur. Because of this, typically, OVAL
assessments are performed on a periodic basis. The OVAL
specification needs to be enhanced to include specifications for
performing event-based and incremental assessment in addition to
full periodic collection.
o Defining new functions for manipulating variable values is current
handled in the Definitions schema. This requires revision to the
core language to add new functions. The OVAL specification needs
Waltermire, et al. Expires March 11, 2015 [Page 58]
Internet-Draft SACM Information Model September 2014
to be evolved to provide for greater extensibility in this area,
allowing extension schema to define new functions.
o The current process for releasing a new version of OVAL, bundle
releases of the core language with release of community recognized
platform schema. The revision processes for the core and platform
schema need to be decoupled. Each platform schema should use some
mechanism to declare which core language version it relies on.
If adopted by SCAM, these issues will need to be addressed as part of
the SCAM engineering work to make OVAL more broadly adoptable as a
general purpose data model for posture collection and evaluation.
E.3.2.1.1.2.2. Applicability to Platform Configuration Item
Identification
Each OVAL Object is identified by a globally unique identifier. This
globally unique identifier could be used by the SACM community to
identify platform-specific configuration items and at the same time
serve as collection guidance. If used in this manner, OVAL Objects
would likely need to undergo changes in order to decouple it from
evaluation guidance and to provide more robust collection
capabilities to support the needs of the SACM community.
E.3.2.2. Configuration Item Identifier
An identifier for a high-level, platform-independent configuration
control. This identification concept is necessary to allow similar
configuration item concepts to be comparable across platforms. For
example, a configuration item might be created for the minimum
password length configuration control, which may then have a number
of different platform-specific configuration settings. Without this
type of identification, it will be difficult to perform evaluation of
expected versus actual state in a platform-neutral way.
High-level configuration items tend to change much less frequently
than the platform-specific configuration items (see Appendix E.3.2.1)
that might be associated with them. To provide for the greatest
amount of sustainability, collections of configuration item
identifiers are best defined by specific communities of interest,
while platform-specific identifiers are best defined by the source
vendor of the platform. Under this model, the primary source vendors
would map their platform-specific configuration controls to the
appropriate platform-independent item allowing end-user organizations
to make use of these relationships.
To support different communities of interest, it may be necessary to
support multiple methods for identification of configuration items
Waltermire, et al. Expires March 11, 2015 [Page 59]
Internet-Draft SACM Information Model September 2014
and for associating related metadata. Use of an IANA registry
supporting multiple configuration item identification methods would
be an ideal way forward. To the extent possible, a few number of
configuration item identification approaches is desirable, to
maximize the update by vendors who would be maintain mapping of
platform-specific configuration identifiers to the more general
platform-neutral configuration identifiers.
E.3.2.2.1. Related Work
E.3.2.2.1.1. Control Correlation Identifier
The Control Correlation Identifier (CCI) [CCI] is developed and
managed by the United States Department of Defense (US-DoD) Defense
Information Systems Agency (DISA). According to their website, CCI
"provides a standard identifier and description for each of the
singular, actionable statements that comprise an information
assurance (IA) control or IA best practice. CCI bridges the gap
between high-level policy expressions and low-level technical
implementations. CCI allows a security requirement that is expressed
in a high-level policy framework to be decomposed and explicitly
associated with the low-level security setting(s) that must be
assessed to determine compliance with the objectives of that specific
security control. This ability to trace security requirements from
their origin (e.g., regulations, IA frameworks) to their low-level
implementation allows organizations to readily demonstrate compliance
to multiple IA compliance frameworks. CCI also provides a means to
objectively roll-up and compare related compliance assessment results
across disparate technologies."
It is recommended that this approach be analysed as a potential
candidate for use as a configuration item identifier method.
Note: This reference to CCI is for informational purposes. Since the
editors do not represent DISA's interests, its inclusion in this
document does not indicate the presence or lack of desire to
contribute aspects of this effort to SACM.
E.3.2.2.1.2. A Potential Alternate Approach
There will likely be a desire by different communities to create
different collections of configuration item identifiers. This
fracturing may be caused by:
o Different requirements for levels of abstraction,
o Varying needs for timely maintenance of the collection, and
Waltermire, et al. Expires March 11, 2015 [Page 60]
Internet-Draft SACM Information Model September 2014
o Differing scopes of technological needs.
Due to these and other potential needs, it will be difficult to
standardize around a single collection of configuration identifiers.
A workable solution will be one that is scalable and usable for a
broad population of end-user organizations. An alternate approach
that should be considered is the definition of data model that
contains a common set of metadata attributes, perhaps supported by an
extensible taxonomy, that can be assigned to platform-specific
configuration items. If defined at a necessary level of granularity,
it may be possible to query collections of platform-specific
configuration items provided by vendors to create groupings at
various levels of abstractions. By utilizing data provided by
vendors, technological needs and the timeliness of information can be
addressed based on customer requirements.
SACM should consider this and other approaches to satisfy the need
for configuration item roll-up in a way that provides the broadest
benefit, while achieving a sensible degree of scalability and
sustainability.
E.3.2.3. Vulnerability Identifier
An unique name for a known software flaw that exists in specific
versions of one or more units of software. One use of a
vulnerability identifier in the SACM context is to associate a given
flaw with the vulnerable software using software identifiers. For
this reason at minimum, software identifiers should identify a
software product to the patch or version level, and not just to the
level that the product is licensed.
E.3.2.3.1. Related Work
E.3.2.3.1.1. Common Vulnerabilities and Exposures
Common Vulnerabilities and Exposures (CVE) [CVE-WEBSITE] is a MITRE
led effort to assign common identifiers to publicly known security
vulnerabilities in software to facilitate the sharing of information
related to the vulnerabilities. CVE is the industry standard by
which software vendors, tools, and security professionals identify
vulnerabilities and could be used to address SACM's need for a
vulnerability identifier.
E.3.3. Endpoint characterization
Target when policies (collection, evaluated, guidance) apply
Collection can be used to further characterize
Waltermire, et al. Expires March 11, 2015 [Page 61]
Internet-Draft SACM Information Model September 2014
Also human input
Information required to characterize an endpoint is used to determine
what endpoints are the target of a posture assessment. It is also
used to determine the collection, evaluation, and/or reporting
policies and the associated guidance that apply to the assessment.
Endpoint characterization information may be populated by:
o A manual input process and entered into records associated with
the endpoint, or
o Using information collected and evaluated by an assessment.
Regardless of the method of collection, it will be necessary to query
and exchange endpoint characterization information as part of the
assessment planning workflow.
E.3.3.1. Related Work
E.3.3.1.1. Extensible Configuration Checklist Description Format
E.3.3.1.1.1. Background
The Extensible Configuration Checklist Description Format (XCCDF) is
a specification that provides an XML-based format for expressing
security checklists. The XCCDF 1.2 specification is published by
International Organization for Standardization (ISO) [ISO.18180].
XCCDF contains multiple components and capabilities, and various
components align with different elements of this information model.
This specification was originally published by NIST [NISTIR-7275].
When contributed to ISO Joint Technical Committee 1 (JTC 1), a
comment was introduced indicating an interest in the IETF becoming
the maintenance organization for this standard. If the SACM working
group is interested in taking on engineering work pertaining to
XCCDF, a contribution through a national body can be made to create a
ballot resolution for transition of this standard to the IETF for
maintenance.
E.3.3.1.1.2. Applicability to Endpoint characterization
The target component of XCCDF provides a mechanism for capturing
characteristics about an endpoint including the fully qualified
domain name, network address, references to external identification
information (e.g. Asset Identification), and is extensible to
support other useful information (e.g. MAC address, globally unique
identifier, certificate, etc.). XCCDF may serve as a good starting
Waltermire, et al. Expires March 11, 2015 [Page 62]
Internet-Draft SACM Information Model September 2014
point for understanding the types of information that should be used
to identify an endpoint.
E.3.3.1.2. Asset Reporting Format
E.3.3.1.2.1. Background
The Asset Reporting Format (ARF) [NISTIR-7694] is a data model to
express information about assets, and the relationships between
assets and reports. It facilitates the reporting, correlating, and
fusing of asset information within and between organizations. ARF is
vendor and technology neutral, flexible, and suited for a wide
variety of reporting applications.
There are four major sub-components of ARF:
o Asset: The asset component element includes asset identification
information for one or more assets. It simply houses assets
independent of their relationships to reports. The relationship
section can then link the report section to specific assets.
o Report: The report component element contains one or more asset
reports. An asset report is composed of content (or a link to
content) about one or more assets.
o Report-Request: The report-request component element contains the
asset report requests, which can give context to asset reports
captured in the report section. The report-request section simply
houses asset report requests independent of the report which was
subsequently generated.
o Relationship: The relationship component element links assets,
reports, and report requests together with well-defined
relationships. Each relationship is defined as {subject}
{predicate} {object}, where {subject} is the asset, report
request, or report of interest, {predicate} is the relationship
type being established, and {object} is one or more assets, report
requests, or reports.
E.3.3.1.2.2. Relationship to Endpoint Characterization
For Endpoint Characterization, ARF can be used in multiple ways due
to its flexibility. ARF supports the use of the Asset Identification
specification (more in Appendix E.3.3.1.2.3) to embed the
representation of one or more assets as well as relationships between
those assets. It also allows the inclusion of report-requests, which
can provide details on what data was required for an assessment.
Waltermire, et al. Expires March 11, 2015 [Page 63]
Internet-Draft SACM Information Model September 2014
ARF is agnostic to the data formats of the collected posture
attributes and therefore can be used within the SACM Architecture to
provide Endpoint Characterization without dictating data formats for
the encoding of posture attributes. The embedded Asset
Identification data model (see Appendix E.3.1.1.1) can be used to
characterize one or more endpoints to allow targeting for collection,
evaluation, etc. Additionally, the report-request model can dictate
the type of reporting that has been requested, thereby providing
context as to which endpoints the guidance applies.
E.3.3.1.2.3. Asset Identification
Described earlier
In the context of Endpoint Characterization, the Asset Identification
data model could be used to encode information that identifies
specific endpoints and/or classes of endpoints to which a particular
assessment is relevant. The flexibility in the Asset Identification
specification allows usage of various endpoint identifiers as defined
by the SACM engineering work.
As stated in Appendix E.3.3.1.2.3, the Asset Identification
specification is included within the Asset Reporting Framework (ARF)
and therefore can be used in concert with that specification as well.
E.3.3.1.3. The CPE Applicability Language
CPE described earlier
Applicability in CPE is defined as an XML language [NISTIR-7698] for
using CPE names to create applicability statements using logical
expressions. These expressions can be used to applicability
statements that can drive decisions about assets, whether or not to
do things like collect data, report data, and execute policy
compliance checks.
It is recommended that SACM evolve the CPE Applicability Language
through engineering work to allow it to better fit into the security
automation vision laid out by the Use Cases and Architecture for
SACM. This should include de-coupling the identification part of the
language from the logical expressions, making it such that the
language is agnostic to the method by which assets are identified.
This will allow use of SWID, CPE Names, or other identifiers to be
used, perhaps supported by an IANA registry of identifier types.
The other key aspect that should be evolved is the ability to make
use of the Applicability Language against a centralized repository of
collected posture attributes. The language should be able to make
Waltermire, et al. Expires March 11, 2015 [Page 64]
Internet-Draft SACM Information Model September 2014
applicability statements against previously collected posture
attributes, such that an enterprise can quickly query the correct set
of applicable endpoints in an automated and scalable manner.
E.3.4. Posture Attribute Expression
Discuss the catalog concept. Listing of things that can be chosen
from. Things we can know about. Vendors define catalogs. Ways for
users to get vendor-provided catalogs.
To support the collection of posture attributes, there needs to be a
way for operators to identify and select from a set of platform-
specific attribute(s) to collect. The same identified attributes
will also need to be identified post-collection to associate the
actual value of that attribute pertaining to an endpoint as it was
configured at the time of the collection. To provide for
extensibility, the need exists to support a variety of possible
identification approaches. It is also necessary to enable vendors of
software to provide a listing, or catalog, of the available posture
attributes to operators that can be collected. Ideally, a federated
approach will be used to allow organizations to identify the location
for a repository containing catalogs of posture attributes provided
by authoritative primary source vendors. By querying these
repositories, operators will be able to acquire the appropriate
listings of available posture attributes for their deployed assets.
One or more posture attribute expressions are needed to support these
exchanges.
E.3.4.1. Related Work
The ATOM Syndication Format [RFC4287] provides an extensible,
flexible XML-based expression for organizing a collection of data
feeds consisting of entries. This standard can be used to express
one or more catalogs of posture attributes represented as data feeds.
Groupings of posture attributes would be represented as entries.
These entries could be defined using the data models described in the
"Related Work" sections below. Additionally, this approach can also
be used more generally for guidance repositories allowing other forms
of security automation guidance to be exchanged using the same
format.
E.3.4.2. Platform Configuration Attributes
A low-level, platform-dependent posture attribute as determined by
the authoritative primary source vendor. Collection guidance will be
derived from catalogs of platform specific posture attributes.
Waltermire, et al. Expires March 11, 2015 [Page 65]
Internet-Draft SACM Information Model September 2014
For example, a primary source vendor would create a platform-specific
posture attribute that best models the posture attribute data for
their platform.
E.3.4.2.1. Related Work
E.3.4.2.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. The OVAL System Characteristics platform
extension models provide a catalog of the posture attributes that can
be collected from an endpoint. In OVAL these posture attributes are
further grouped into logical constructs called OVAL Items. For
example, the passwordpolicy_item that is part of the Windows platform
extension groups together all the posture attributes related to
passwords for an endpoint running Windows (e.g. maximum password age,
minimum password length, password complexity, etc.). The various
OVAL Items defined in the OVAL System Characteristics may serve as a
good starting for the types of posture attribute data that needs to
be collected from endpoints.
OVAL platform extension models may be shared using the ATOM
Syndication Format.
E.3.4.2.1.2. Network Configuration Protocol and YANG Data Modeling
Language
The Network Configuration Protocol (NETCONF) [RFC6241] defines a
mechanism for managing and retrieving posture attribute data from
network infrastructure endpoints. The posture attribute data that
can be collected from a network infrastructure endpoint is highly
extensible and can defined using the YANG modeling language
[RFC6020]. Models exist for common datatypes, interfaces, and
routing subsystem information among other subjects. The YANG
modeling language may be useful in providing an extensible framework
for the SACM community to define one or more catalogs of posture
attribute data that can be collected from network infrastructure
endpoints.
Custom YANG modules may also be shared using the ATOM Syndication
Format.
E.3.4.2.1.3. Simple Network Management Protocol and Management
Information Base Entry
The Simple Network Protocol (SNMP) [RFC3411] defines a protocol for
managing and retrieving posture attribute data from endpoints on a
network . The posture attribute data that can be collected of an
Waltermire, et al. Expires March 11, 2015 [Page 66]
Internet-Draft SACM Information Model September 2014
endpoint and retrieved by SNMP is defined by the Management
Information Base (MIB) [RFC3418] which is hierarchical collection of
information that is referenced using Object Identifiers . Given this,
MIBs may provide an extensible way for the SACM community to define a
catalog of posture attribute data that can be collected off of
endpoints using SNMP.
MIBs may be shared using the ATOM Syndication Format.
E.3.5. Actual Value Representation
Discuss instance concept.
The actual value of a posture attribute is collected or published
from an endpoint. The identifiers discussed previously provide names
for the posture attributes (i.e., software or configuration item)
that can be the subject of an assessment. The information items
listed below are the actual values collected during the assessment
and are all associated with a specific endpoint.
E.3.5.1. Software Inventory
A software inventory is a list of software identifiers (or content)
associated with a specific endpoint. Software inventories are
maintained in some organized fashion so that entities can interact
with it. Just having software publish identifiers onto an endpoint
is not enough, there needs to be an organized listing of all those
identifiers associated with that endpoint.
E.3.5.1.1. Related Work
E.3.5.1.1.1. Asset Summary Reporting
The Asset Summary Reporting (ASR) specification [NISTIR-7848]
provides a format for capturing summary information about one or more
assets. Specifically, it provides the ability to express a
collection of records from some defined data source and map them to
some set of assets. As a result, this specification may be useful
for capturing the software installed on an endpoint, its relevant
attributes, and associating it with a particular endpoint.
E.3.5.1.1.2. Software Identification Tags
SWID tag were previously introduced in Appendix E.3.1.3.1.2. As
stated before, SWID tags are ideally deployed to an endpoint during
software installation. In the less ideal case, they may also be
generated based on information retrieved from a proprietary software
installation data store. At minimum, SWID tag must contain an
Waltermire, et al. Expires March 11, 2015 [Page 67]
Internet-Draft SACM Information Model September 2014
identifier for each unit of installed software. Given this, SWID
tags may be a viable way for SACM to express detailed information
about the software installed on an endpoint.
E.3.5.2. Collected Platform Configuration Posture Attributes
Configurations associated with a software instance associated with an
endpoint
A list of the configuration posture attributes associated with the
actual values collected from the endpoint during the assessment as
required/expressed by any related guidance. Additionally, each
configuration posture attribute is associated with the installed
software instance it pertains to.
E.3.5.2.1. Related Work
E.3.5.2.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. As mentioned earlier, the OVAL System
Characteristics platform extensions provide a catalog of the posture
attributes that can be collected and assessed in the form of OVAL
Items. These OVAL Items also serve as a model for representing
posture attribute data and associated values that are collected off
an endpoint. Furthermore, the OVAL System Characteristics model
provides a system_info construct that captures information that
identifies and characterizes the endpoint from which the posture
attribute data was collected. Specifically, it includes operating
system name, operating system version, endpoint architecture,
hostname, network interfaces, and an extensible construct to support
arbitrary additional information that may be useful in identifying
the endpoint in an enterprise such as information capture in Asset
Identification constructs. The OVAL System Characteristics model
could serve as a useful starting point for representing posture
attribute data collected from an endpoint although it may need to
undergo some changes to satisfy the needs of the SACM community.
E.3.5.2.1.2. NETCONF-Based Collection
Introduced earlier in Appendix E.3.4.2.1.2, NETCONF defines a
protocol for managing and retrieving posture attribute data from
network infrastructure endpoints. NETCONF provides the <get-config>
and <get> operations to retrieve the configuration data, and
configuration data and state data respectively from a network
infrastructure endpoint. Upon successful completion of these
operations, the current posture attribute data of the network
infrastructure endpoint will be made available. NETCONF also
Waltermire, et al. Expires March 11, 2015 [Page 68]
Internet-Draft SACM Information Model September 2014
provides a variety of filtering mechanisms (XPath, subtree, content
matching, etc.) to trim down the posture attribute data that is
collected from the endpoint. Given that NETCONF is widely adopted by
network infrastructure vendors, it may useful to consider this
protocol as a standardized mechanism for collecting posture attribute
data from network infrastructure endpoints.
As a side note, members of the OVAL Community have also developed a
proposal to extend the OVAL Language to support the assessment of
NETCONF configuration data [1]. The proposal leverages XPath to
extract the posture attribute data of interest from the XML data
returned by NETCONF. The collected posture attribute data can then
be evaluated using OVAL Definitions and the results of the evaluation
can be expressed as OVAL Results. While this proposal is not
currently part of the OVAL Language, it may be worth considering.
E.3.5.2.1.3. SNMP-Based Collection
The SNMP, previously introduced in Appendix E.3.4.2.1.3, defines a
protocol for managing and retrieving posture attribute data from
endpoints on a network [RFC3411]. SNMP provides three protocol
operations [RFC3416] (GetRequest, GetNextRequest, and GetBulkRequest)
for retrieving posture attribute data defined by MIB objects. Upon
successful completion of these operations, the requested posture
attribute data of the endpoint will be made available to the
requesting application. Given that SNMP is widely adopted by
vendors, and the MIBs that define posture attribute data on an
endpoint are highly extensible, it may useful to consider this
protocol as a standardized mechanism for collecting posture attribute
data from endpoints in an enterprise.
E.3.6. Evaluation Guidance
E.3.6.1. Configuration Evaluation Guidance
The evaluation guidance is applied by evaluators during posture
assessment of an endpoint. This guidance must be able to reference
or be associated with the following previously defined information
elements:
o configuration item identifiers,
o platform configuration identifiers, and
o collected Platform Configuration Posture Attributes.
Waltermire, et al. Expires March 11, 2015 [Page 69]
Internet-Draft SACM Information Model September 2014
E.3.6.1.1. Related Work
E.3.6.1.1.1. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. The OVAL Definitions model provides an
extensible framework for making assertions about the state of posture
attribute data collected from an endpoint. Guidance written against
this model consists of one or more OVAL Tests, that can be logically
combined, where each OVAL Test defines what posture attributes should
be collected from an endpoint (as OVAL Objects) and optionally
defines the expected state of the posture attributes (as OVAL
States). While the OVAL Definitions model may be a useful starting
point for evaluation guidance, it will likely require some changes to
decouple collection and evaluation concepts to satisfy the needs of
the SACM community.
E.3.6.1.1.2. XCCDF Rule
A general description of XCCDF was provided in Appendix E.3.3.1.1.1.
As noted there, an XCCDF document represents a checklist of items
against which a given endpoint's state is compared and evaluated. An
XCCDF Rule represents one assessed item in this checklist. A Rule
contains both a prose description of the assessed item (either for
presentation to the user in a tool's user interface, or for rendering
into a prose checklist for human consumption) and can also contain
instructions to support automated evaluation of the assessed item, if
such automated assessment is possible. Automated assessment
instructions can be provided either within the XCCDF Rule itself, or
by providing a reference to instructions expressed in other
languages, such as OVAL.
In order to support greater flexibility in XCCDF, checklists can be
tailored to meet certain needs. One way to do this is to enable or
disable certain rules that are appropriate or inappropriate to a
given endpoint, respectively. For example, a single XCCDF checklist
might contain check items to evaluate the configuration of an
endpoint's operating system. An endpoint deployed in an enterprise's
DMZ might need to be locked down more than a common internal
endpoint, due to the greater exposure to attack. In this case, some
operating system configuration requirements for the DMZ endpoint
might be unnecessary for the internal endpoint. Nonetheless, most
configuration requirements would probably remain applicable to both
environments (providing a common baseline for configuration of the
given operating system) and thus be common to the checking
instructions for both types of endpoints. XCCDF supports this by
allowing a single checklist to be defined, but then tailored to the
needs of the assessed endpoint. In the previous example, some Rules
Waltermire, et al. Expires March 11, 2015 [Page 70]
Internet-Draft SACM Information Model September 2014
that apply only to the DMZ endpoint would be disabled during the
assessment of an internal endpoint and would not be exercised during
the assessment or count towards the assessment results. To
accomplish this, XCCDF uses the CPE Applicability Language. By
enhancing this applicability language to support other aspects of
endpoint characterization (see Appendix E.3.3.1.3), XCCDF will also
benefit from these enhancements.
In addition, XCCDF Rules also support parameterization, allowing
customization of the expected value for a given check item. For
example, the DMZ endpoint might require a password of at least 12
characters, while an internal endpoint may only need 8 or more
characters in its password. By employing parameterization of the
XCCDF Rule, the same Rule can be used when assessing either type of
endpoint, and simply be provided with a different target parameter
each time to reflect the different role-based requirements. Sets of
customizations can be stored within the XCCDF document itself: XCCDF
Values store parameters values that can be used in tailoring, while
XCCDF Profiles store sets of tailoring instructions, including
selection of certain Values as parameters and the enabling and
disabling of certain Rules. The tailoring capabilities supported by
XCCDF allow a single XCCDF document to encapsulate configuration
evaluation guidance that applies to a broad range of endpoint roles.
E.3.7. Evaluation Result Reporting
E.3.7.1. Configuration Evaluation Results
The evaluation guidance applied during posture assessment of an
endpoint to customize the behavior of evaluators. Guidance can be
used to define specific result output formats or to select the level-
of-detail for the generated results. This guidance must be able to
reference or be associated with the following previously defined
information elements:
o configuration item identifiers,
o platform configuration identifiers, and
o collected Platform Configuration Posture Attributes.
E.3.7.1.1. Related Work
E.3.7.1.1.1. XCCDF TestResults
A general description of the eXtensible Configuration Checklist
Description Format (XCCDF) was provided in section
Appendix E.3.3.1.1.1. The XCCDF TestResult structure captures the
Waltermire, et al. Expires March 11, 2015 [Page 71]
Internet-Draft SACM Information Model September 2014
outcome of assessing a single endpoint against the assessed items
(i.e., XCCDF Rules) contained in an XCCDF instance document. XCCDF
TestResults capture a number of important pieces of information about
the assessment including:
o The identity of the assessed endpoint. See Appendix E.3.3.1.1.2
for more about XCCDF structures used for endpoint identification.
o Any tailoring of the checklist that might have been employed. See
Appendix E.3.6.1.1.2 for more on how XCCDF supports tailoring.
o The individual results of the assessment of each enabled XCCDF
Rule in the checklist. See Appendix E.3.6.1.1.2 for more on XCCDF
Rules.
The individual results for a given XCCDF Rule capture only whether
the rule "passed", "failed", or experienced some exceptional
condition, such as if an error was encountered during assessment.
XCCDF 1.2 Rule results do not capture the actual state of the
endpoint. For example, an XCCDF Rule result might indicate that an
endpoint failed to pass requirement that passwords be of a length
greater than or equal to 8, but it would not capture that the
endpoint was, in fact, only requiring passwords of 4 or more
characters. It may, however, be possible for a user to discover this
information via other means. For example, if the XCCDF Rule uses an
OVAL Definition to effect the Rule's evaluation, then the actual
endpoint state may be captured in the corresponding OVAL System
Characteristics file.
The XCCDF TestResult structure does provide a useful structure for
understanding the overall assessment that was conducted and the
results thereof. The ability to quickly determine the Rules that are
not complied with on a given endpoint allow administrators to quickly
identify where remediation needs to occur.
E.3.7.1.1.2. Open Vulnerability and Assessment Language
A general overview of OVAL was provided previously in
Appendix E.3.2.1.1.2.1. OVAL Results provides a model for expressing
the results of the assessment of the actual state of the posture
attribute values collected of an endpoint (represented as an OVAL
System Characteristics document) against the expected posture
attribute values (defined in an OVAL Definitions document. Using
OVAL Directives, the granularity of OVAL Results can also be
specified. The OVAL Results model may be useful in providing a
format for capturing the results of an assessment.
Waltermire, et al. Expires March 11, 2015 [Page 72]
Internet-Draft SACM Information Model September 2014
E.3.7.1.1.3. Asset Summary Reporting
A general overview of ASR was provided previously in
Appendix E.3.5.1.1.1. As ASR provides a way to report summary
information about assets, it can be used within the SACM Architecture
to provide a way to aggregate asset information for later use. It
makes no assertions about the data formats used by the assessment,
but rather provides an XML, record-based way to collect aggregated
information about assets.
By using ASR to collect this summary information within the SACM
Architecture, one can provide a way to encode the details used by
various reporting requirements, including user-definable reports.
E.3.7.1.1.4. ARF
A general overview of ARF was provided previously in
Appendix E.3.3.1.2.1. Because ARF is data model agnostic, it can
provide a flexible format for exchanging collection and evaluation
information from endpoints. It additionally provides a way to encode
relationships between guidance and assets, and as such, can be used
to associate assessment results with guidance. This could be the
guidance that directly triggered the assessment, or for guidance that
is run against collected posture attributes located in a central
repository.
E.3.7.2. Software Inventory Evaluation Results
The results of an evaluation of an endpoint's software inventory
against an authorized software list. The authorized software list
represents the policy for what software units are allowed,
prohibited, and mandatory for an endpoint.
Authors' Addresses
David Waltermire (editor)
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland 20877
USA
Email: david.waltermire@nist.gov
Waltermire, et al. Expires March 11, 2015 [Page 73]
Internet-Draft SACM Information Model September 2014
Kim Watson
United States Department of Homeland Security
DHS/CS&C/FNR
245 Murray Ln. SW, Bldg 410
MS0613
Washington, DC 20528
USA
Email: kimberly.watson@hq.dhs.gov
Clifford Kahn
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
USA
Email: cliffordk@juniper.net
Lisa Lorenzin
Juniper Networks, Inc.
3614 Laurel Creek Way
Durham, NC 27712
USA
Email: llorenzin@juniper.net
Waltermire, et al. Expires March 11, 2015 [Page 74]