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]