Internet DRAFT - draft-lorenzin-sacm-tnc-information-model
draft-lorenzin-sacm-tnc-information-model
SACM L. Lorenzin, Ed.
Internet Draft C. Kahn
Intended status: Informational Juniper Networks
Expires: January 2015 S. Venema
The Boeing Company
S. Pope
Cisco Systems
H. Birkholz
Fraunhofer SIT
July 3, 2014
SACM Information Model Based On TNC
draft-lorenzin-sacm-tnc-information-model-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Lorenzin, et al. Expires January 3, 2015 [Page 1]
Internet-Draft SACM Information Model Based On TNC July 2014
Abstract
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.
Table of Contents
1. Introduction...................................................3
2. Security Automation with TNC IF-MAP............................4
2.1. What is Trusted Network Connect?..........................4
2.2. What is TNC IF-MAP?.......................................4
2.3. What is the TNC Information Model?........................5
3. SACM Information Model Derived from TNC........................5
3.1. Graph Model Based on IF-MAP...............................6
3.1.1. Background: Graph Models.............................6
3.1.2. Graph Model Overview.................................7
3.1.3. Identifiers..........................................7
3.1.4. Links................................................8
3.1.5. Metadata.............................................8
3.1.6. Provenance...........................................8
3.1.7. Extensibility........................................9
3.2. Elements of the SACM Information Model....................9
3.2.1. Components..........................................10
3.2.2. Objects.............................................10
3.3. Operations...............................................10
3.3.1. Generalized Workflow................................11
4. SACM Usage Scenario Example...................................11
4.1. Elements of the Posture Deviation Detection Scenario.....11
4.1.1. Components..........................................11
4.1.2. Objects.............................................12
4.1.2.1. Endpoint.......................................14
4.1.2.1.1. Endpoint Credential.......................14
4.1.2.1.2. Software Asset............................15
4.1.2.1.3. Non-Software Asset........................16
4.1.2.2. Internal Collection Task.......................16
4.1.2.3. User...........................................16
4.1.2.3.1. User Credential...........................16
4.1.2.4. Network Session................................16
4.1.2.4.1. Address...................................16
4.1.2.4.2. Authorizations............................17
4.1.2.5. Location.......................................17
4.1.2.6. External Collection Task.......................18
4.1.2.7. Posture Attribute or Event.....................18
4.1.2.7.1. Posture Attribute.........................19
4.1.2.7.2. Event.....................................19
Lorenzin, et al. Expires January 3, 2015 [Page 2]
Internet-Draft SACM Information Model Based On TNC July 2014
4.1.2.7.3. Difference between Attribute and Event....19
4.1.2.8. Evaluation Task................................19
4.1.2.9. Evaluation Result..............................20
4.1.2.10. Reporting Task................................20
4.1.2.11. Report........................................20
4.1.2.12. Policies......................................21
4.1.2.12.1. Internal Collection Policy...............21
4.1.2.12.2. External Collection Policy...............21
4.1.2.12.3. Evaluation Policy........................21
4.1.2.12.4. Retention Policy.........................21
4.1.2.12.5. Reporting Policy.........................21
4.1.2.13. Provenance of Information.....................22
4.2. Graph Model for Detection of Posture Deviation...........22
4.2.1. Identifiers.........................................22
4.2.2. Metadata............................................22
4.2.3. Relationships between Identifiers and Metadata......23
4.3. Workflow.................................................23
5. Security Considerations.......................................24
6. IANA Considerations...........................................24
7. Conclusion....................................................24
8. References....................................................24
8.1. Informative References...................................24
9. Acknowledgments...............................................27
Appendix A. Examples of TNC IF-MAP in Security Deployments.......28
1. Introduction
This document describes the Trusted Network Connect (TNC) Information
Model and proposes a SACM Information Model that builds on the TNC
standardized information model to serve the security automation use-
cases outlined by the IETF SACM workgroup.
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.
Lorenzin, et al. Expires January 3, 2015 [Page 3]
Internet-Draft SACM Information Model Based On TNC July 2014
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.
2. Security Automation with TNC IF-MAP
2.1. What is Trusted Network Connect?
Trusted Network Connect (TNC) is a vendor-neutral open architecture
[1] 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 [2][3][4][5] were
used as the base for the IETF NEA RFCs [6][7][8][9].
Traditional information security architectures have separate silos
for endpoint security, network security, server security, physical
security, etc. The TNC architecture enables the integration and
categorization of security telemetry sources via the information
model contained in its Interface for Metadata Access Points (IF-MAP)
[10]. 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.
2.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
Lorenzin, et al. Expires January 3, 2015 [Page 4]
Internet-Draft SACM Information Model Based On TNC July 2014
continuously evolving knowledge base of security-related metadata
that is shared between various providers and consumers.
2.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 [10], TNC
IF-MAP Metadata for Network Security [11], and TNC IF-MAP Metadata
for ICS Security [12]) 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
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
[10] for more details on the above graph data store operation
requests and their associated arguments.
The current IF-MAP specification provides a SOAP [13] binding for the
above operations, as well as associated SOAP operations for managing
sessions, error handling, etc.
3. SACM Information Model Derived from TNC
The SACM Information Model based on TNC describes how security data
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
[16]) 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.
Lorenzin, et al. Expires January 3, 2015 [Page 5]
Internet-Draft SACM Information Model Based On TNC July 2014
This architecture addresses data structure independently of the
access/transport of that data. This separation enables scalability,
customizability, and extensibility. Access to provide or consume
data is particularly suited to publish/subscribe/query data transport
and data access control models.
The primary function of this "SACM Information Model based on TNC"
proposal is to provide 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 data exchange, and the objects
exchanged
o Provides a graph database model that captures and organizes
evolving data and data relationships for multiple data publishers
o Provides access to the published data 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
3.1. Graph Model Based on IF-MAP
3.1.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
Lorenzin, et al. Expires January 3, 2015 [Page 6]
Internet-Draft SACM Information Model Based On TNC July 2014
+------------------+ +-----------------+
| 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 1 - 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) [14].
3.1.2. Graph Model Overview
The proposed model 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 I-D, identifiers and metadata have hierarchical structure.
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 [15] data models.
3.1.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.
Lorenzin, et al. Expires January 3, 2015 [Page 7]
Internet-Draft SACM Information Model Based On TNC July 2014
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.
3.1.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.
3.1.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; it is generally quite
small. For extensibility, schemas use xsd:anyAttribute and such.
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 [11] and TNC IF-MAP Metadata
for ICS Security [12] define many pertinent metadata types. More
will need to be standardized for SACM use cases.
3.1.6. Provenance
Provenance helps to protect the SACM ecosystem against a misled or
malicious provider.
Lorenzin, et al. Expires January 3, 2015 [Page 8]
Internet-Draft SACM Information Model Based On TNC July 2014
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 [11]. For example, there is a top-level XML
attribute called "timestamp".
It is critical that provenance be secure from tampering. How to
achieve that security is out of scope of this document.
3.1.7. 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 [10] were addressed in TNC IF-MAP Metadata for
Network Security [11]. Some years later an additional, major set of
use cases, TNC IF-MAP Metadata for ICS [12], were specified and
implemented.
3.2. Elements of the SACM Information Model
Two categories of elements appear in the SACM Information Model:
components (actors) and objects (what is acted upon).
Lorenzin, et al. Expires January 3, 2015 [Page 9]
Internet-Draft SACM Information Model Based On TNC July 2014
3.2.1. Components
The proposed SACM Information Model contains three components, as
defined in the SACM Architecture [16]: Posture Attribute Information
Provider, Posture Attribute Information Consumer, and Control Plane.
3.2.2. Objects
The proposed SACM Information Model contains several elements that
are objects of the architecture, including:
o Collection tasks, 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 asset, endpoint identity, user
identity, address, location, and authorization constraining the
endpoint
o History, a compilation of previously collected information
3.3. 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.
Lorenzin, et al. Expires January 3, 2015 [Page 10]
Internet-Draft SACM Information Model Based On TNC July 2014
3.3.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.
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.
4. SACM Usage Scenario Example
The following section illustrates the proposed SACM Information Model
as applied to SACM Usage Scenario 2.2.3, Detection of Posture
Deviations [17]. The following subsections describe the elements
(components and objects), graph model, and operations (sample
workflow) required to support the Detection of Posture Deviations
scenario.
4.1. Elements of the Posture Deviation Detection Scenario
4.1.1. Components
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.
Lorenzin, et al. Expires January 3, 2015 [Page 11]
Internet-Draft SACM Information Model Based On TNC July 2014
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.
4.1.2. Objects
The Detection of Posture Deviations scenario involves multiple
objects interacting to accomplish the goals of the scenario. The
following figure illustrates those objects along with their major
communication paths.
................ ................ .................
: ENDPOINT : : NETWORK : : USER : +--------+
: : : SESSION : : : +--------+|
: +----------+: : +-------+ : : +----------+ : |Location|+
: +----------+|: : +-------+| : : +----------+| : +--------+
: |Credential|+: : |Address|+ : : |Credential|+ :
: +----------+ : : +-------+ : : +----------+ :
: : : : :...............:
: +--------+ : : +----------+ :
: +--------+| : : | AuthZ's | :
: |Software|| : : +----------+ :
: |Asset |+ : :..............:
: +--------+ : V
: : V
: +---------+ : +----------------+
: +---------+| : +----------------+|
: |Internal || : |External Collec-||
: |Collec- || : |tion Task (P) |+
: |tion || : +----------------+
: |Task (P) |+ : V
: +---------+ : V
:......V.......: V
V V
V V<<<<<<<<
V V +---------+
V V +---------+|
V +----------+ +--------+ +--------+ |Posture ||
V +----------+| +--------+| +--------+| |Assess- ||
Lorenzin, et al. Expires January 3, 2015 [Page 12]
Internet-Draft SACM Information Model Based On TNC July 2014
V |Posture ||>>| Eval ||>>| Eval ||>>|ment ||
V |Attribute || |Task (P)|+ |Result |+ |Infor- ||
>>>|/Event |+ +--------+ +--------+ |mation ||
+----------+ V |Requestor|+
V ___V__ +---------+
V / \ ^
V |\.____./| ^
>>>>>>>>>>>>>>>>>>>>>>>>|History |>>>>>>
|(P) |
\.____./
>>> A main information flow
(P) Policy is applied
Figure 2 - Objects and Information Flow
Figure 3 is a more detailed version of Figure 2. Many of the objects
in this figure could be represented as identifiers, and many of the
relationships could be represented as links.
+--------+_______________
____________|Location|*__________ |
| *+--------+* | |
| +----------+ | |
| _______|Credential|_______ | |
| | *+----------+* | | |
|* |* |* |* |
+--------+ +----------+ +---------+_______+----+ |
|Software|____| Endpoint |____| Network |* 0..1|User| |
|Asset |* 1| |1 *| Session | +----+ |
+--------+ | | | | |*
| | | |_________+-------+
| | | | 1..*|Address|
+----------+ +---------+ +-------+
|1 |1 |* 1|____+-------------+
V| | V| *|Authorization|
|* | |* +-------------+
+----------+ | +----------+
____|Internal | | |External |____ +----------+____
|> *|Collection| | |Collection|* <| |Evaluation|* <|
| |Task | | |Task | | |Task (P) | |
|1 +----------+ | +----------+ 1| +----------+ 1|
------------ |0..1 | 0..1| ------------ |1 ------------
|Internal | | | | |External | | |Evaluation|
|Collection| | | | |Collection| | |Policy |
Lorenzin, et al. Expires January 3, 2015 [Page 13]
Internet-Draft SACM Information Model Based On TNC July 2014
|Policy | V| | V| |Policy | V| ------------
------------ | | | ------------ |
| |* *| |*
| ===========_________________============
|______|Posture |1..* > *|Evaluation|
*|Attribute|______ ______|Result |
|/Event |* < | | > *============
=========== *| |* |*
*| ----------- |
| |Retention| |V
V| |Policy | |
| ----------- |*
|______________________+-------------+
_____*|Reporting |
| > *|Task |
|1 +-------------+
--------------- ^|1
|Reporting | |
|Policy | V|*
--------------- =========
|Report |
=========
----------------------------------------------------------
1 Multiplicity symbols > Direction of causation. For
0..1 found in UML 2 [18] < example, a collection policy
* class diagrams V affects a collection task.
1..* ^
*
----------------------------------------------------------
Figure 3 - Objects and Multiplicity
The following subsections elaborate upon the objects found in the two
figures.
4.1.2.1. Endpoint
See the definition in the SACM Terminology for Security Assessment
[19].
4.1.2.1.1. Endpoint Credential
An endpoint credential provides both identification and
authentication of the endpoint. For example, a credential may be an
X.509 certificate [20] and corresponding private key.
Lorenzin, et al. Expires January 3, 2015 [Page 14]
Internet-Draft SACM Information Model Based On TNC July 2014
Not all kinds of credentials are guaranteed to be unique.
4.1.2.1.2. Software Asset
An endpoint generally contains software assets.
"Asset" is defined in RFC4949 [21] 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."
A software asset is an asset in the form of software.
We extend the definition to include any software that may affect an
endpoint's posture. An examination of software assets needs to
consider both (a) software to be protected and (b) software that may
do harm. An inventory system may not know (a) from (b). It is
useful to define Software Asset as the union of (a) and (b).
General 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 Assets:
o An entertainment app that contains malware
o A web page that contains malicious JavaScript
o A business application that shipped with a virus
A software asset may have a unique identifier, such as a SWID tag
(ISO/IEC 19770).
The configuration of a piece of software is regarded as part of the
Software Asset.
Lorenzin, et al. Expires January 3, 2015 [Page 15]
Internet-Draft SACM Information Model Based On TNC July 2014
4.1.2.1.3. Non-Software Asset
Hardware components in a system may also be considered as resources
that must be protected according to security policies. 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 non-software assets 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.
4.1.2.2. Internal Collection Task
An endpoint may also contain one or more internal collection tasks.
An internal collection task is a collection task, as defined in the
SACM Terminology for Security Assessment [19], which collects posture
attributes, values, or events from inside the endpoint. In other
words, the posture attributes and events are self reported. They may
be subject to the lying endpoint problem.
Example: a NEA posture collector. [22]
4.1.2.3. User
4.1.2.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.1.2.4. Network Session
An endpoint connected to a particular network has a network session,
and may have multiple network sessions connecting it to multiple
networks.
4.1.2.4.1. Address
A network session generally has one or more addresses. For example,
it may have a MAC address and an IP address.
Lorenzin, et al. Expires January 3, 2015 [Page 16]
Internet-Draft SACM Information Model Based On TNC July 2014
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.1.2.4.2. Authorizations
Authorizations determine what the endpoint can do with its network
session. Examples include:
o A RADIUS VLAN assignment [23]
o A router or firewall access control list (ACL)
o An IF-MAP access-request constellation [11], which may determine
how a firewall treats the endpoint
4.1.2.5. Location
This is a logical or physical location. Location can be pertinent to
security posture. For example, some endpoints may need to stay in
protected areas to protect them.
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, as 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 collection task or other system may express location information as
posture attributes.
Lorenzin, et al. Expires January 3, 2015 [Page 17]
Internet-Draft SACM Information Model Based On TNC July 2014
4.1.2.6. External Collection Task
An external collection task is a collection task, as defined in the
SACM Terminology for Security Assessment [19], which observes
endpoints from outside.
Examples:
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.1.2.7. Posture Attribute or Event
A Posture Attribute or Event is provided by an internal or external
collection task.
Although Figure 2 depicts a Posture Attribute or an Event as related
to a single Endpoint, the truth is more complex. It would be
convenient if every endpoint had a single unforgeable, visible
identifier, and every Posture Attribute could refer to that
identifier. In fact, a Posture Attribute refers to the endpoint by
some identifying attributes. Different Posture Attributes might
mention different identifying attributes.
For example, one Endpoint can sign on at different times with
different credentials; Posture Attributes may mention the credentials
in use at the time.
In short, an endpoint has many guises. There is a need to see
through the guises, to decide whether two Posture Attributes or
Events refer to the same endpoint. Perhaps Attribute Evaluation
tasks can address this need.
Lorenzin, et al. Expires January 3, 2015 [Page 18]
Internet-Draft SACM Information Model Based On TNC July 2014
4.1.2.7.1. Posture Attribute
See the definition in the SACM Terminology for Security Assessment
[19].
Examples:
o A NEA posture attribute (PA) [22]
o A YANG model [15]
o An IF-MAP device-characteristics metadata item [11]
4.1.2.7.2. Event
An event is also an output of an internal or external collection
task. Examples:
o A structured syslog message [24]
o IF-MAP event metadata [11]
o A NetFlow message [25]
4.1.2.7.3. 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.1.2.8. Evaluation Task
See the definition in the SACM Terminology for Security Assessment
[19].
Lorenzin, et al. Expires January 3, 2015 [Page 19]
Internet-Draft SACM Information Model Based On TNC July 2014
Example: a NEA posture validator [22]
4.1.2.9. Evaluation Result
See the definition in the SACM Terminology for Security Assessment
[19].
Example: a NEA access recommendation [7]
As Figure 2 shows, an Evaluation Result derives from one or more
Posture Attributes and Events.
An Evaluation Task 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 Posture
Attributes and Events from which it derives. (Figure 2 does not show
this.) In the limiting case, Posture Attributes and Events are not
retained. As soon as a Posture Attribute or an Event arrives, an
Evaluation Task produces an Evaluation Result.
4.1.2.10. Reporting Task
A reporting task makes reports based on:
o Posture Attributes,
o Events,
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.1.2.11. Report
A Report summarizes:
o Posture Attributes,
o Events, and/or
o Evaluation Results
Lorenzin, et al. Expires January 3, 2015 [Page 20]
Internet-Draft SACM Information Model Based On TNC July 2014
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.1.2.12. Policies
Policies are generally configurable by human administrators.
4.1.2.12.1. Internal Collection Policy
An internal collection task may need a policy to govern what it
collects and when.
4.1.2.12.2. External Collection Policy
An external collection task may need a policy to govern what it
collects and when.
4.1.2.12.3. Evaluation Policy
An Evaluation Task typically needs an Evaluation Policy to govern
what it considers to be a good or bad security posture.
4.1.2.12.4. Retention Policy
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 policies control what is
retained and for how long.
If two or more retention policies apply to a piece of information,
the policy calling for the longest retention should take precedence.
Retained information may be stored in a Configuration Management
Database (CMDB), for example.
4.1.2.12.5. Reporting Policy
A Reporting Task typically needs a Reporting Policy to govern the
reports it generates.
Lorenzin, et al. Expires January 3, 2015 [Page 21]
Internet-Draft SACM Information Model Based On TNC July 2014
4.1.2.13. Provenance of Information
Each Posture Attribute, Event, Evaluation Result, and Report needs to
be labeled with its provenance (see section 3.1.6).
4.2. Graph Model for Detection of Posture Deviation
The following subsections contain examples of identifiers and
metadata which would enable detection of posture deviation. These
lists are by no means exhaustive - many other types of metadata would
be enumerated in a data model that fully addressed this usage
scenario.
4.2.1. Identifiers
To represent the objects 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 [20])
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)
[26], etc.)
o Task - categorized by type of task (e.g. internal collection task,
external collection task, evaluation task, or reporting task)
o Result - categorized by type of result (e.g. evaluation result or
report)
o Policy
4.2.2. Metadata
To characterize the objects 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.
Lorenzin, et al. Expires January 3, 2015 [Page 22]
Internet-Draft SACM Information Model Based On TNC July 2014
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, an internal collection task associated
with an endpoint security service might publish policy violation
event metadata attached to the identity identifier of an endpoint
when a user disables required security software to notify
consumers of the change in endpoint state.
o Posture attribute metadata attached to an identity identifier of
an endpoint. For example, an internal collection task associated
with an endpoint security service might publish posture attribute
metadata attached to the identity identifier of an endpoint when
required security software is not running to notify consumers of
the current state of the endpoint.
4.2.3. 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 collection tasks gather and publish posture
information related to an endpoint. These two constellations are not
necessarily connected to each other, but may be joined if the
component publishing the authenticated-session metadata constellation
is able to link the network session identifier to the identity
identifier of the endpoint.
4.3. 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 [10] or XMPP-Grid [27], is as
follows:
Lorenzin, et al. Expires January 3, 2015 [Page 23]
Internet-Draft SACM Information Model Based On TNC July 2014
5. The analytics engine (Posture Assessment Information Consumer)
establishes connectivity and authorization with the transport
fabric, and subscribes to updates on posture deviations.
6. The endpoint security service (Posture Assessment Information
Provider) requests connection to the transport fabric.
7. Transport fabric authenticates and establishes authorized
privileges (e.g. privilege to publish and/or subscribe to security
data) for the requesting components.
8. The endpoint security service evaluates the endpoint, detects
posture deviation, and publishes information on the posture
deviation.
9. 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.
5. Security Considerations
The TNC IF-MAP Binding for SOAP [10] and TNC IF-MAP Metadata for
Network Security [11] 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.
6. IANA Considerations
This memo includes no requests to IANA.
7. Conclusion
The proposed SACM Information Model is designed to ensure
adaptability for changing networking environments, as well as
interoperability with a variety of transport protocols.
8. References
8.1. Informative References
[1] Trusted Computing Group, "TNC Architecture", Specification
Version 1.5, May 2012.
Lorenzin, et al. Expires January 3, 2015 [Page 24]
Internet-Draft SACM Information Model Based On TNC July 2014
[2] Trusted Computing Group, "TNC IF-M: TLV Binding", Specification
Version 1.0, May 2014.
[3] Trusted Computing Group, "TNC IF-TNCCS: TLV Binding",
Specification Version 2.0, May 2014.
[4] Trusted Computing Group, "TNC IF-T: Protocol Bindings for
Tunneled EAP Methods", Specification Version 2.0, May 2014.
[5] Trusted Computing Group, "TNC IF-T: Binding to TLS",
Specification Version 2.0, February 2013.
[6] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
Protocol (PA) Compatible with TNC", RFC 5792, March 2010.
[7] Sahita, R., Hanna, S., Hurst, R., and K. Narayanan, "PB-TNC: A
Posture Broker (PB) Protocol Compatible with Trusted Network
Connect (TNC)", RFC 5793, March 2010.
[8] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT)
Protocol For Extensible Authentication Protocol (EAP) Tunnel
Methods", RFC 7171, April 2014.
[9] Sangster, P., Cam-Winget, N., and J. Salowey, "PT-TLS: A TCP-
based Posture Transport (PT) Protocol", RFC 6876, February
2013.
[10] Trusted Computing Group, "TNC IF-MAP Binding for SOAP",
Specification Version 2.2, March 2014.
[11] Trusted Computing Group, "TNC IF-MAP Metadata for Network
Security", Specification Version 1.1, May 2012.
[12] Trusted Computing Group, "TNC IF-MAP Metadata for ICS
Security", Specification Version 1.0, May 2014.
[13] W3C, "SOAP Version 1.2" Part 1: Messaging Framework (Second
Edition), April 2007.
[14] W3C, "RDF W3C, "RDF 1.1 Concepts and Abstract Syntax", version
1.1, February 2014.
[15] Bjorklund, M. (Editor), "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
Lorenzin, et al. Expires January 3, 2015 [Page 25]
Internet-Draft SACM Information Model Based On TNC July 2014
[16] Cam-Winget, N., Ford, B., Lorenzin, L., McDonald, I., and A.
Woland, "Secure Automation and Continuous Monitoring (SACM)
Architecture", draft-camwinget-sacm-architecture-00 (work in
progress), June 2014.
[17] Waltermire, D., and D. Harrington, "Endpoint Security Posture
Assessment - Enterprise Use Cases", draft-ietf-sacm-use-cases-
07 (work in progress), April 2014.
[18] Object Management Group, "Unified Modeling Language TM (UML
(R))", Version 2.4.1, August 2011.
[19] Waltermire, D., Montville, A., Harrington, D., and N. Cam-
Winget, "Terminology for Security Assessment", draft-ietf-sacm-
terminology-04 (work in progress), May 2014.
[20] 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.
[21] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949,
August 2007.
[22] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[23] 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.
[24] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[25] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
RFC 3954, October 2004.
[26] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[27] Salowey, J. (Ed.), Lorenzin, L., Kahn, C., Pope, S., Appala,
S., and N. Cam-Winget, "XMPP Protocol Extensions for Use in
SACM Information Transport", draft-salowey-sacm-xmpp-grid-00
(work in progress), July 2014.
Lorenzin, et al. Expires January 3, 2015 [Page 26]
Internet-Draft SACM Information Model Based On TNC July 2014
9. Acknowledgments
The authors would like to acknowledge the contributions, authoring,
and/or editing of the following people: Syam Appala, Nancy Cam-
Winget, Jessica Fitzgerald-McKay, Steve Hanna, and Aaron Woland.
This document was prepared using 2-Word-v2.0.template.dot.
Lorenzin, et al. Expires January 3, 2015 [Page 27]
Internet-Draft SACM Information Model Based On TNC July 2014
Appendix A. Examples of TNC IF-MAP in Security Deployments
IF-MAP has been continually enhanced by the Trusted Computing Group,
culminating in the most recent version, IF-MAP 2.2, published in
March 2014. Vendors have been shipping IF-MAP enabled products since
2008 to provide an ecosystem that supports standardized, dynamic
security data interexchange among a wide variety of networking and
security components. IF-MAP has focused on providing a standardized
information model that can be utilized for data interoperability
between vendors.
IF-MAP has been deployed most commonly for:
o Seamless remote and local access control, providing single sign-on
for either initial access to a network, or remote access to a
network, coordinated with access control enforcement deeper in the
network
o Integration of physical and logical access control, so user
location obtained from a badge access system can be used as input
into a network access policy decision
o Usage of IF-MAP as a point of coordination for industrial control
system security, for policy enforcement and certificate lifecycle
management
o Leveraging IP address mappings to MAC addresses from DHCP servers
to enable network-based enforcement for MAC authenticated devices
o Integration of detailed behavioral information from threat sensors
-- such as IPS, endpoint profiling / behavior monitoring, and
network leak detection systems -- into network access control
policy decisions
Additional use cases explored include:
o A content management database (CMDB) receives notification of a
new device on the network -- perhaps via notification that a DHCP
server has assigned an IP address to a new MAC address -- and
scans the new endpoint, then updates its data store.
o A security administrator modifies an existing security policy, or
adds a new policy, and various policy servers / sensors are
notified, triggering a re-evaluation of the network's endpoints.
Lorenzin, et al. Expires January 3, 2015 [Page 28]
Internet-Draft SACM Information Model Based On TNC July 2014
o An application server publishes a request for bandwidth for a
particular user based on the service the user is accessing;
network infrastructure components change QoS settings for those
traffic flows based on that request.
o An analysis system determines that there's an attack underway; in
addition to triggering a response, it notifies security
administrators of the attack taking place, populating a dashboard
with information to create a "heat map" of the attack.
Lorenzin, et al. Expires January 3, 2015 [Page 29]
Internet-Draft SACM Information Model Based On TNC July 2014
Authors' Addresses
Cliff 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
Steven Venema
The Boeing Company
PO Box 3707, MC 4C-77
Seattle, WA 98124-2207
Email: steven.c.venema@boeing.com
Scott Pope
Cisco Systems
5400 Meadows Road
Suite 300
Lake Oswego, OR 97035
USA
Email: scottp@cisco.com
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Lorenzin, et al. Expires January 3, 2015 [Page 30]
