idnits 2.17.1 draft-lorenzin-sacm-tnc-information-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-07 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-04 -- Obsolete informational reference (is this intentional?): RFC 5201 (ref. '26') (Obsoleted by RFC 7401) == Outdated reference: A later version (-02) exists of draft-salowey-sacm-xmpp-grid-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SACM L. Lorenzin, Ed. 2 Internet Draft C. Kahn 3 Intended status: Informational Juniper Networks 4 Expires: January 2015 S. Venema 5 The Boeing Company 6 S. Pope 7 Cisco Systems 8 H. Birkholz 9 Fraunhofer SIT 10 July 3, 2014 12 SACM Information Model Based On TNC 13 draft-lorenzin-sacm-tnc-information-model-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 3, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 This document defines an information model for aggregated 53 configuration and operational data, so that the data can be evaluated 54 to determine an organization's security posture. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Security Automation with TNC IF-MAP............................4 60 2.1. What is Trusted Network Connect?..........................4 61 2.2. What is TNC IF-MAP?.......................................4 62 2.3. What is the TNC Information Model?........................5 63 3. SACM Information Model Derived from TNC........................5 64 3.1. Graph Model Based on IF-MAP...............................6 65 3.1.1. Background: Graph Models.............................6 66 3.1.2. Graph Model Overview.................................7 67 3.1.3. Identifiers..........................................7 68 3.1.4. Links................................................8 69 3.1.5. Metadata.............................................8 70 3.1.6. Provenance...........................................8 71 3.1.7. Extensibility........................................9 72 3.2. Elements of the SACM Information Model....................9 73 3.2.1. Components..........................................10 74 3.2.2. Objects.............................................10 75 3.3. Operations...............................................10 76 3.3.1. Generalized Workflow................................11 77 4. SACM Usage Scenario Example...................................11 78 4.1. Elements of the Posture Deviation Detection Scenario.....11 79 4.1.1. Components..........................................11 80 4.1.2. Objects.............................................12 81 4.1.2.1. Endpoint.......................................14 82 4.1.2.1.1. Endpoint Credential.......................14 83 4.1.2.1.2. Software Asset............................15 84 4.1.2.1.3. Non-Software Asset........................16 85 4.1.2.2. Internal Collection Task.......................16 86 4.1.2.3. User...........................................16 87 4.1.2.3.1. User Credential...........................16 88 4.1.2.4. Network Session................................16 89 4.1.2.4.1. Address...................................16 90 4.1.2.4.2. Authorizations............................17 91 4.1.2.5. Location.......................................17 92 4.1.2.6. External Collection Task.......................18 93 4.1.2.7. Posture Attribute or Event.....................18 94 4.1.2.7.1. Posture Attribute.........................19 95 4.1.2.7.2. Event.....................................19 96 4.1.2.7.3. Difference between Attribute and Event....19 97 4.1.2.8. Evaluation Task................................19 98 4.1.2.9. Evaluation Result..............................20 99 4.1.2.10. Reporting Task................................20 100 4.1.2.11. Report........................................20 101 4.1.2.12. Policies......................................21 102 4.1.2.12.1. Internal Collection Policy...............21 103 4.1.2.12.2. External Collection Policy...............21 104 4.1.2.12.3. Evaluation Policy........................21 105 4.1.2.12.4. Retention Policy.........................21 106 4.1.2.12.5. Reporting Policy.........................21 107 4.1.2.13. Provenance of Information.....................22 108 4.2. Graph Model for Detection of Posture Deviation...........22 109 4.2.1. Identifiers.........................................22 110 4.2.2. Metadata............................................22 111 4.2.3. Relationships between Identifiers and Metadata......23 112 4.3. Workflow.................................................23 113 5. Security Considerations.......................................24 114 6. IANA Considerations...........................................24 115 7. Conclusion....................................................24 116 8. References....................................................24 117 8.1. Informative References...................................24 118 9. Acknowledgments...............................................27 119 Appendix A. Examples of TNC IF-MAP in Security Deployments.......28 121 1. Introduction 123 This document describes the Trusted Network Connect (TNC) Information 124 Model and proposes a SACM Information Model that builds on the TNC 125 standardized information model to serve the security automation use- 126 cases outlined by the IETF SACM workgroup. 128 The proposed SACM information model offers a loose coupling between 129 providers and consumers of security information. A provider can 130 relay what it observes or infers, without knowing which consumers 131 will use the information, or how they will use it. A consumer need 132 not know exactly which provider generated a piece of information, or 133 by what method. 135 At the same time, a consumer *can* know these things, if necessary. 137 As things evolve, a provider can relay supplemental information. 138 Some consumers will understand and benefit from the supplemental 139 information; other consumers will not understand and will disregard 140 it. 142 The structure of each unit of information is extensible. The 143 arrangement of information units into a graph is also extensible; new 144 arrangements can be defined for new use cases. 146 2. Security Automation with TNC IF-MAP 148 2.1. What is Trusted Network Connect? 150 Trusted Network Connect (TNC) is a vendor-neutral open architecture 151 [1] and a set of open standards for network security developed by the 152 Trusted Computing Group (TCG). TNC standards integrate security 153 components across end user systems, servers, and network 154 infrastructure devices into an intelligent, responsive, coordinated 155 defense. TNC standards have been widely adopted by vendors and 156 customers; the TNC endpoint assessment protocols [2][3][4][5] were 157 used as the base for the IETF NEA RFCs [6][7][8][9]. 159 Traditional information security architectures have separate silos 160 for endpoint security, network security, server security, physical 161 security, etc. The TNC architecture enables the integration and 162 categorization of security telemetry sources via the information 163 model contained in its Interface for Metadata Access Points (IF-MAP) 164 [10]. IF-MAP provides a query-able repository of security telemetry 165 that may be used for storage or retrieval of such data by multiple 166 types of security systems and endpoints on a vendor-neutral basis. 167 The information model underlying the IF-MAP repository covers, 168 directly or indirectly, all of the security information types 169 required to serve SACM use-cases. 171 2.2. What is TNC IF-MAP? 173 IF-MAP provides a standard client-server protocol for MAP clients to 174 exchange security-relevant information via database server known as 175 the Metadata Access Point or MAP. The data (known as "metadata") 176 stored in the MAP is XML data. Each piece of metadata is tagged with 177 a metadata type that indicates the meaning of the metadata and 178 identifies an XML schema for it. Due to the XML language, the set of 179 metadata types is easily extensible. 181 The MAP is a graph database, not a relational database. Metadata can 182 be associated with an identifier (e.g. the email address 183 "user@example.com") or with a link between two identifiers (e.g. the 184 link between MAC address 00:11:22:33:44:55 and IPv4 address 185 192.0.2.1) where the link defines an association (for example: a 186 relation or state) between the identifiers. These links between 187 pairs of identifiers create an ad hoc graph of relationships between 188 identifiers. The emergent structure of this graph reflects a 189 continuously evolving knowledge base of security-related metadata 190 that is shared between various providers and consumers. 192 2.3. What is the TNC Information Model? 194 The TNC Information Model underlying IF-MAP relies on the graph 195 database architecture to enable a (potentially distributed) MAP 196 service to act as a shared clearinghouse for information that 197 infrastructure devices can act upon. The IF-MAP operations and 198 metadata schema specifications (TNC IF-MAP Binding for SOAP [10], TNC 199 IF-MAP Metadata for Network Security [11], and TNC IF-MAP Metadata 200 for ICS Security [12]) define an extensible set of identifiers and 201 data types. 203 Each IF-MAP client may interact with the IF-MAP graph data store 204 through three fundamental types of operation requests: 206 o Publish, which may create, modify, or delete metadata associated 207 with one or more identifiers and/or links in the graph 209 o Search, which retrieves a selected sub-graph according to a set of 210 search criteria 212 o Subscribe, which allows a client to manage a set of search 213 commands which asynchronously return selected sub-graphs when 214 changes to that sub-graph are made by other IF-MAP clients 216 The reader is invited to review the existing IF-MAP specification 217 [10] for more details on the above graph data store operation 218 requests and their associated arguments. 220 The current IF-MAP specification provides a SOAP [13] binding for the 221 above operations, as well as associated SOAP operations for managing 222 sessions, error handling, etc. 224 3. SACM Information Model Derived from TNC 226 The SACM Information Model based on TNC describes how security data 227 is structured, related, and accessed. Control of operations to 228 supply and/or access the data is architecturally distinct from the 229 structuring of the data in the information model. Authorization may 230 be applied by the Control Plane (as defined in the SACM Architecture 231 [16]) to requests for information from a consumer or requests for 232 publication from a provider, and may also be applied by a provider to 233 a direct request from a consumer. 235 This architecture addresses data structure independently of the 236 access/transport of that data. This separation enables scalability, 237 customizability, and extensibility. Access to provide or consume 238 data is particularly suited to publish/subscribe/query data transport 239 and data access control models. 241 The primary function of this "SACM Information Model based on TNC" 242 proposal is to provide a framework that: 244 o Facilitates the definition of extensible data types that support 245 SACM's use cases 247 o Provides a structure for the defined data types to be exchanged 248 via a variety of data transport models 250 o Describes components used in data exchange, and the objects 251 exchanged 253 o Provides a graph database model that captures and organizes 254 evolving data and data relationships for multiple data publishers 256 o Provides access to the published data via publish, query, and 257 subscribe operations 259 o Leverages the knowledge and experience gained from incorporating 260 TNC IF-MAP into many disparate products that have to integrate and 261 share an information model in a scalable, extensible manner 263 3.1. Graph Model Based on IF-MAP 265 3.1.1. Background: Graph Models 267 Knowledge is often represented with graph-based formalisms. A common 268 formalism defines a graph as follows: 270 o A set of *vertices* 272 o A set of *edges*, each connecting two vertices (technically, an 273 edge is an ordered pair of vertices) 275 o A set of zero or more *properties* attached to each vertices and 276 edges; each property consists of a type and a optionally a value; 277 the type and the value are typically just strings 279 +------------------+ +-----------------+ 280 | Id: 1 | parent-of |Id: 2 | 281 | Given name: Sue | --------------> |Given name: Ann | 282 | Family name: Wong| |Family name: Wong| 283 +------------------+ +-----------------+ 285 A VERTEX AN EDGE A VERTEX 287 Figure 1 - Knowledge represented by a graph 289 A pair of vertices connected by an edge is commonly referred to as a 290 triple that comprises subject, predicate and object. For example, 291 subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A 292 common language that uses this representation is the Resource 293 Description Framework (RDF) [14]. 295 3.1.2. Graph Model Overview 297 The proposed model is a labeled graph: each vertex has a label. 299 A table of synonyms follows. 301 Graph Theory | Graph Databases | IF-MAP and This Internet Draft 302 ---------------+-----------------+-------------------------------- 303 Vertex or Node | Node | - 304 Label | - | Identifier 305 Edge | Edge | Link 306 - | Property | Metadata Item 308 In this I-D, identifiers and metadata have hierarchical structure. 310 The graphical aspect makes this model well suited to non-hierarchical 311 relationships, such as connectivity in a computer network. 313 Hierarchical properties allow this model to accommodate structures 314 such as YANG [15] data models. 316 3.1.3. Identifiers 318 Each identifier is an XML element. For extensibility, schemas use 319 xsd:anyAttribute and such. 321 Alternately, this model could be changed to use another hierarchical 322 notation, such as JSON. 324 Identifiers are unique: two different vertices cannot have equivalent 325 identifiers. 327 An identifier has a type. There is a finite, but extensible, set of 328 identifier types. If the identifier is XML, the type is based on the 329 XML schema. 331 In IF-MAP, standard identifier types include IP address, MAC address, 332 identity, and overlay network. Additional identifier types will need 333 to be standardized for SACM use cases. 335 Any number of metadata items can be attached to an identifier. 337 Some identifiers, especially those relating to identity, address, and 338 location, require the ability to specify an administrative domain 339 (such as AD domain, L2 broadcast domain / L3 routing domain, or 340 geographic domain) in order to differentiate between instances with 341 the same name occurring in different realms. 343 3.1.4. Links 345 A link can be thought of as an ordered pair of identifiers. 347 Any number of metadata items can be attached to a link. 349 3.1.5. Metadata 351 A metadata item is the basic unit of information, and is attached to 352 an identifier or to a link. 354 A given metadata item is an XML document; it is generally quite 355 small. For extensibility, schemas use xsd:anyAttribute and such. 357 Alternately, this model could be changed to use another hierarchical 358 notation, such as JSON. 360 A metadata item has a type. There is a finite, but extensible, set 361 of metadata types. If the metadata item is XML, the type is based on 362 the XML schema. An example metadata type is 363 http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device- 364 characteristic. 366 TNC IF-MAP Metadata for Network Security [11] and TNC IF-MAP Metadata 367 for ICS Security [12] define many pertinent metadata types. More 368 will need to be standardized for SACM use cases. 370 3.1.6. Provenance 372 Provenance helps to protect the SACM ecosystem against a misled or 373 malicious provider. 375 The provenance of a metadata item includes: 377 o The time when the item was produced 379 o The component that produced the item, including its software and 380 version 382 o The policies that governed the producing component, with versions 384 o The method used to produce the information (e.g., vulnerability 385 scan) 387 How provenance should be expressed is an open question. For 388 reference, in IF-MAP provenance of a metadata item is expressed 389 within the metadata item [11]. For example, there is a top-level XML 390 attribute called "timestamp". 392 It is critical that provenance be secure from tampering. How to 393 achieve that security is out of scope of this document. 395 3.1.7. Extensibility 397 Anyone can define an identifier type or a metadata type, by creating 398 an XML schema (or other specification). There is no need for a 399 central authority. Some deployments may exercise administrative 400 control over the permitted identifier types and metadata types; 401 others may leave components free rein. 403 A community of components can agree on and use new identifier and 404 metadata types, if the administrators allow it. This allows rapid 405 innovation. Intermediate software that conveys graph changes from 406 one component to another does not need changes. Components that do 407 not understand the new types do not need changes. Accordingly, a 408 consumer normally ignores metadata types and identifier types it does 409 not understand. 411 As a proof point for this agility, the original use cases for TNC IF- 412 MAP Binding for SOAP [10] were addressed in TNC IF-MAP Metadata for 413 Network Security [11]. Some years later an additional, major set of 414 use cases, TNC IF-MAP Metadata for ICS [12], were specified and 415 implemented. 417 3.2. Elements of the SACM Information Model 419 Two categories of elements appear in the SACM Information Model: 420 components (actors) and objects (what is acted upon). 422 3.2.1. Components 424 The proposed SACM Information Model contains three components, as 425 defined in the SACM Architecture [16]: Posture Attribute Information 426 Provider, Posture Attribute Information Consumer, and Control Plane. 428 3.2.2. Objects 430 The proposed SACM Information Model contains several elements that 431 are objects of the architecture, including: 433 o Collection tasks, which may be internal (performed within the 434 endpoint itself) or external (performed outside of the endpoint, 435 such as by a hypervisor or remote sensor) 437 o Posture, in the form of posture attributes and evaluation results 439 o Additional information about the endpoint, such as a 440 representation of a software asset, endpoint identity, user 441 identity, address, location, and authorization constraining the 442 endpoint 444 o History, a compilation of previously collected information 446 3.3. Operations 448 Operations that may be carried out the proposed SACM Information 449 Model are: 451 o Publish data: Security information is made available in the 452 information model when a component publishes data to it. 454 o Subscribe to data: A component seeking to consume an on-going 455 stream of security information "subscribes" to such data from the 456 information model. 458 o Query: This operation enables a component to request a specific 459 set of security data regarding a specific asset (such as a 460 specific user endpoint). 462 The subscribe capability will allow SACM components to monitor for 463 selected security-related changes in the graph data store without 464 incurring the performance penalties associated with polling for such 465 changes. 467 3.3.1. Generalized Workflow 469 The proposed SACM Information Model would be most commonly used with 470 a suitable transport protocol for collecting and distributing 471 security data across appropriate network platforms and endpoints. 472 The information model is transport agnostic and can be used with its 473 native transport provided by IF-MAP or by other data transport 474 protocols such as the recently proposed XMPP-Grid. 476 1. A Posture Assessment Information Consumer (Consumer) establishes 477 connectivity and authorization with the transport fabric. 479 2. A Posture Assessment Information Provider (Provider) with a source 480 of security data requests connection to the transport fabric. 482 3. Transport fabric authenticates and establishes authorized 483 privileges (e.g. privilege to publish and/or subscribe to security 484 data) for the requesting components. 486 4. Components may either publish security data, subscribe to security 487 data, query for security data, or any combination of these 488 operations. 490 Any component sharing information - either as Provider or Consumer - 491 may do so on a one-to-one, one-to-many and/or many-to-many meshed 492 basis. 494 4. SACM Usage Scenario Example 496 The following section illustrates the proposed SACM Information Model 497 as applied to SACM Usage Scenario 2.2.3, Detection of Posture 498 Deviations [17]. The following subsections describe the elements 499 (components and objects), graph model, and operations (sample 500 workflow) required to support the Detection of Posture Deviations 501 scenario. 503 4.1. Elements of the Posture Deviation Detection Scenario 505 4.1.1. Components 507 In this example, the components are instantiated as follows: 509 o The Posture Attribute Information Provider is an endpoint security 510 service which monitors the compliance state of the endpoint and 511 reports any deviations for the expected posture. 513 o The Posture Attribute Information Consumer is an analytics engine 514 which absorbs information from around the network and generates a 515 "heat map" of which areas in the network are seeing unusually high 516 rates of posture deviations. 518 o The Control Plane is a security automation broker which receives 519 subscription requests from the analytics engine and authorizes 520 access to appropriate information from the endpoint security 521 service. 523 4.1.2. Objects 525 The Detection of Posture Deviations scenario involves multiple 526 objects interacting to accomplish the goals of the scenario. The 527 following figure illustrates those objects along with their major 528 communication paths. 530 ................ ................ ................. 531 : ENDPOINT : : NETWORK : : USER : +--------+ 532 : : : SESSION : : : +--------+| 533 : +----------+: : +-------+ : : +----------+ : |Location|+ 534 : +----------+|: : +-------+| : : +----------+| : +--------+ 535 : |Credential|+: : |Address|+ : : |Credential|+ : 536 : +----------+ : : +-------+ : : +----------+ : 537 : : : : :...............: 538 : +--------+ : : +----------+ : 539 : +--------+| : : | AuthZ's | : 540 : |Software|| : : +----------+ : 541 : |Asset |+ : :..............: 542 : +--------+ : V 543 : : V 544 : +---------+ : +----------------+ 545 : +---------+| : +----------------+| 546 : |Internal || : |External Collec-|| 547 : |Collec- || : |tion Task (P) |+ 548 : |tion || : +----------------+ 549 : |Task (P) |+ : V 550 : +---------+ : V 551 :......V.......: V 552 V V 553 V V<<<<<<<< 554 V V +---------+ 555 V V +---------+| 556 V +----------+ +--------+ +--------+ |Posture || 557 V +----------+| +--------+| +--------+| |Assess- || 558 V |Posture ||>>| Eval ||>>| Eval ||>>|ment || 559 V |Attribute || |Task (P)|+ |Result |+ |Infor- || 560 >>>|/Event |+ +--------+ +--------+ |mation || 561 +----------+ V |Requestor|+ 562 V ___V__ +---------+ 563 V / \ ^ 564 V |\.____./| ^ 565 >>>>>>>>>>>>>>>>>>>>>>>>|History |>>>>>> 566 |(P) | 567 \.____./ 569 >>> A main information flow 570 (P) Policy is applied 572 Figure 2 - Objects and Information Flow 574 Figure 3 is a more detailed version of Figure 2. Many of the objects 575 in this figure could be represented as identifiers, and many of the 576 relationships could be represented as links. 578 +--------+_______________ 579 ____________|Location|*__________ | 580 | *+--------+* | | 581 | +----------+ | | 582 | _______|Credential|_______ | | 583 | | *+----------+* | | | 584 |* |* |* |* | 585 +--------+ +----------+ +---------+_______+----+ | 586 |Software|____| Endpoint |____| Network |* 0..1|User| | 587 |Asset |* 1| |1 *| Session | +----+ | 588 +--------+ | | | | |* 589 | | | |_________+-------+ 590 | | | | 1..*|Address| 591 +----------+ +---------+ +-------+ 592 |1 |1 |* 1|____+-------------+ 593 V| | V| *|Authorization| 594 |* | |* +-------------+ 595 +----------+ | +----------+ 596 ____|Internal | | |External |____ +----------+____ 597 |> *|Collection| | |Collection|* <| |Evaluation|* <| 598 | |Task | | |Task | | |Task (P) | | 599 |1 +----------+ | +----------+ 1| +----------+ 1| 600 ------------ |0..1 | 0..1| ------------ |1 ------------ 601 |Internal | | | | |External | | |Evaluation| 602 |Collection| | | | |Collection| | |Policy | 603 |Policy | V| | V| |Policy | V| ------------ 604 ------------ | | | ------------ | 605 | |* *| |* 606 | ===========_________________============ 607 |______|Posture |1..* > *|Evaluation| 608 *|Attribute|______ ______|Result | 609 |/Event |* < | | > *============ 610 =========== *| |* |* 611 *| ----------- | 612 | |Retention| |V 613 V| |Policy | | 614 | ----------- |* 615 |______________________+-------------+ 616 _____*|Reporting | 617 | > *|Task | 618 |1 +-------------+ 619 --------------- ^|1 620 |Reporting | | 621 |Policy | V|* 622 --------------- ========= 623 |Report | 624 ========= 626 ---------------------------------------------------------- 627 1 Multiplicity symbols > Direction of causation. For 628 0..1 found in UML 2 [18] < example, a collection policy 629 * class diagrams V affects a collection task. 630 1..* ^ 631 * 632 ---------------------------------------------------------- 634 Figure 3 - Objects and Multiplicity 636 The following subsections elaborate upon the objects found in the two 637 figures. 639 4.1.2.1. Endpoint 641 See the definition in the SACM Terminology for Security Assessment 642 [19]. 644 4.1.2.1.1. Endpoint Credential 646 An endpoint credential provides both identification and 647 authentication of the endpoint. For example, a credential may be an 648 X.509 certificate [20] and corresponding private key. 650 Not all kinds of credentials are guaranteed to be unique. 652 4.1.2.1.2. Software Asset 654 An endpoint generally contains software assets. 656 "Asset" is defined in RFC4949 [21] as "a system resource that is (a) 657 required to be protected by an information system's security policy, 658 (b) intended to be protected by a countermeasure, or (c) required for 659 a system's mission." 661 A software asset is an asset in the form of software. 663 We extend the definition to include any software that may affect an 664 endpoint's posture. An examination of software assets needs to 665 consider both (a) software to be protected and (b) software that may 666 do harm. An inventory system may not know (a) from (b). It is 667 useful to define Software Asset as the union of (a) and (b). 669 General examples of Software Assets: 671 o An application 673 o A patch 675 o The operating system kernel 677 o A boot loader 679 o Firmware that controls a disk drive 681 o A piece of JavaScript found in a web page the user visits 683 Examples of harmful Software Assets: 685 o An entertainment app that contains malware 687 o A web page that contains malicious JavaScript 689 o A business application that shipped with a virus 691 A software asset may have a unique identifier, such as a SWID tag 692 (ISO/IEC 19770). 694 The configuration of a piece of software is regarded as part of the 695 Software Asset. 697 4.1.2.1.3. Non-Software Asset 699 Hardware components in a system may also be considered as resources 700 that must be protected according to security policies. For example, 701 a USB port on a system may be disabled to prevent information flow 702 into our out of a particular system; this provides an additional 703 layer of protection that can complement software based protections. 704 Other such assets may include access to or modification of storage 705 media, hardware key stores, microphones and cameras. Like software 706 assets, we can consider these non-software assets both from the 707 perspective of (a) an asset that needs protection and (b) an asset 708 that can be compromised in some way to do harm. 710 4.1.2.2. Internal Collection Task 712 An endpoint may also contain one or more internal collection tasks. 714 An internal collection task is a collection task, as defined in the 715 SACM Terminology for Security Assessment [19], which collects posture 716 attributes, values, or events from inside the endpoint. In other 717 words, the posture attributes and events are self reported. They may 718 be subject to the lying endpoint problem. 720 Example: a NEA posture collector. [22] 722 4.1.2.3. User 724 4.1.2.3.1. User Credential 726 An endpoint is often - but not always - associated with one or more 727 users. 729 A user's credential provides both identification and authentication 730 of the user. 732 4.1.2.4. Network Session 734 An endpoint connected to a particular network has a network session, 735 and may have multiple network sessions connecting it to multiple 736 networks. 738 4.1.2.4.1. Address 740 A network session generally has one or more addresses. For example, 741 it may have a MAC address and an IP address. 743 These addresses are not necessarily globally unique. Therefore, an 744 address may be qualified with a scope. For example: 746 o A MAC address may be qualified with its layer-2 broadcast domain. 748 o An IP address may be qualified with its IP routing domain. 750 Other kinds of addresses may find application. 752 4.1.2.4.2. Authorizations 754 Authorizations determine what the endpoint can do with its network 755 session. Examples include: 757 o A RADIUS VLAN assignment [23] 759 o A router or firewall access control list (ACL) 761 o An IF-MAP access-request constellation [11], which may determine 762 how a firewall treats the endpoint 764 4.1.2.5. Location 766 This is a logical or physical location. Location can be pertinent to 767 security posture. For example, some endpoints may need to stay in 768 protected areas to protect them. 770 Examples of location: 772 o The switch or access point to which the endpoint has authenticated 774 o The switch port where the endpoint is plugged in 776 o The location of the endpoint's IP address in the network topology 778 o The geographic location of the endpoint (typically self-reported) 780 o A user location, as reported by a physical access control system 782 More than one of these may pertain to an endpoint. Endpoint has a 783 many-to-many relationship with Location. 785 A collection task or other system may express location information as 786 posture attributes. 788 4.1.2.6. External Collection Task 790 An external collection task is a collection task, as defined in the 791 SACM Terminology for Security Assessment [19], which observes 792 endpoints from outside. 794 Examples: 796 o A RADIUS server whereby an endpoint has logged onto the network 798 o A network profiling system, which discovers and classifies network 799 nodes 801 o A Network Intrusion Detection System (NIDS) sensor 803 o A vulnerability scanner 805 o A hypervisor that peeks into the endpoint, the endpoint being a 806 virtual machine 808 o A management system that configures and installs software on the 809 endpoint 811 4.1.2.7. Posture Attribute or Event 813 A Posture Attribute or Event is provided by an internal or external 814 collection task. 816 Although Figure 2 depicts a Posture Attribute or an Event as related 817 to a single Endpoint, the truth is more complex. It would be 818 convenient if every endpoint had a single unforgeable, visible 819 identifier, and every Posture Attribute could refer to that 820 identifier. In fact, a Posture Attribute refers to the endpoint by 821 some identifying attributes. Different Posture Attributes might 822 mention different identifying attributes. 824 For example, one Endpoint can sign on at different times with 825 different credentials; Posture Attributes may mention the credentials 826 in use at the time. 828 In short, an endpoint has many guises. There is a need to see 829 through the guises, to decide whether two Posture Attributes or 830 Events refer to the same endpoint. Perhaps Attribute Evaluation 831 tasks can address this need. 833 4.1.2.7.1. Posture Attribute 835 See the definition in the SACM Terminology for Security Assessment 836 [19]. 838 Examples: 840 o A NEA posture attribute (PA) [22] 842 o A YANG model [15] 844 o An IF-MAP device-characteristics metadata item [11] 846 4.1.2.7.2. Event 848 An event is also an output of an internal or external collection 849 task. Examples: 851 o A structured syslog message [24] 853 o IF-MAP event metadata [11] 855 o A NetFlow message [25] 857 4.1.2.7.3. Difference between Attribute and Event 859 "Attribute" and "event" are often used fairly interchangeably. A 860 clear distinction makes the words more useful. 862 An *attribute* tends to stay true until something causes a change. 863 In contrast, an *event* occurs at a moment in time. 865 For a nontechnical example, "closed" is an attribute of a door. A 866 closed door tends to stay closed until something opens it (a breeze, 867 a person, or a dog). 869 The door's opening or closing is an event. 871 Similarly, "Host firewall is enabled?" may be modeled as an endpoint 872 attribute. Enabling or disabling the host firewall may be modeled as 873 an event. An endpoint's crashing also may be modeled as an event. 875 4.1.2.8. Evaluation Task 877 See the definition in the SACM Terminology for Security Assessment 878 [19]. 880 Example: a NEA posture validator [22] 882 4.1.2.9. Evaluation Result 884 See the definition in the SACM Terminology for Security Assessment 885 [19]. 887 Example: a NEA access recommendation [7] 889 As Figure 2 shows, an Evaluation Result derives from one or more 890 Posture Attributes and Events. 892 An Evaluation Task may be able to evaluate better if history is 893 available. This is a use case for retaining Posture Attributes and 894 Events for a time. 896 An Evaluation Result may be retained longer than the Posture 897 Attributes and Events from which it derives. (Figure 2 does not show 898 this.) In the limiting case, Posture Attributes and Events are not 899 retained. As soon as a Posture Attribute or an Event arrives, an 900 Evaluation Task produces an Evaluation Result. 902 4.1.2.10. Reporting Task 904 A reporting task makes reports based on: 906 o Posture Attributes, 908 o Events, 910 o Evaluation Results, and/or 912 o Other Reports (a weekly report may be created from daily reports) 914 It may summarize data continually, as the data arrives. It also may 915 summarize data in response to an ad hoc query. 917 4.1.2.11. Report 919 A Report summarizes: 921 o Posture Attributes, 923 o Events, and/or 925 o Evaluation Results 926 A Report may routine or ad hoc. 928 Some reports may be machine readable. Machine readable summaries may 929 be consumable by automatic response systems (not part of SACM). 931 4.1.2.12. Policies 933 Policies are generally configurable by human administrators. 935 4.1.2.12.1. Internal Collection Policy 937 An internal collection task may need a policy to govern what it 938 collects and when. 940 4.1.2.12.2. External Collection Policy 942 An external collection task may need a policy to govern what it 943 collects and when. 945 4.1.2.12.3. Evaluation Policy 947 An Evaluation Task typically needs an Evaluation Policy to govern 948 what it considers to be a good or bad security posture. 950 4.1.2.12.4. Retention Policy 952 A SACM deployment may retain posture attributes, events, or 953 evaluation results for some time. Retention supports ad hoc 954 reporting and other use cases. 956 If information is retained, retention policies control what is 957 retained and for how long. 959 If two or more retention policies apply to a piece of information, 960 the policy calling for the longest retention should take precedence. 962 Retained information may be stored in a Configuration Management 963 Database (CMDB), for example. 965 4.1.2.12.5. Reporting Policy 967 A Reporting Task typically needs a Reporting Policy to govern the 968 reports it generates. 970 4.1.2.13. Provenance of Information 972 Each Posture Attribute, Event, Evaluation Result, and Report needs to 973 be labeled with its provenance (see section 3.1.6). 975 4.2. Graph Model for Detection of Posture Deviation 977 The following subsections contain examples of identifiers and 978 metadata which would enable detection of posture deviation. These 979 lists are by no means exhaustive - many other types of metadata would 980 be enumerated in a data model that fully addressed this usage 981 scenario. 983 4.2.1. Identifiers 985 To represent the objects listed above, the set of identifiers might 986 include (but is not limited to): 988 o Identity - a device itself, or a user operating a device, 989 categorized by type of credential (e.g. username or X.509 990 certificate [20]) 992 o Software asset 994 o Network session 996 o Address - categorized by type of address (e.g. MAC address, IP 997 address, Host Identity Protocol (HIP) Host Identity Tag (HIT) 998 [26], etc.) 1000 o Task - categorized by type of task (e.g. internal collection task, 1001 external collection task, evaluation task, or reporting task) 1003 o Result - categorized by type of result (e.g. evaluation result or 1004 report) 1006 o Policy 1008 4.2.2. Metadata 1010 To characterize the objects listed above, the set of metadata types 1011 might include (but is not limited to): 1013 o Authorization metadata attached to an identity identifier, or to a 1014 link between a network session identifier and an identity 1015 identifier, or to a link between a network session identifier and 1016 an address identifier. 1018 o Location metadata attached to a link between a network session 1019 identifier and an address identifier. 1021 o Event metadata attached to an address identifier or an identity 1022 identifier of an endpoint, which would be made available to 1023 interested parties at the time of publication, but not stored 1024 long-term. For example, an internal collection task associated 1025 with an endpoint security service might publish policy violation 1026 event metadata attached to the identity identifier of an endpoint 1027 when a user disables required security software to notify 1028 consumers of the change in endpoint state. 1030 o Posture attribute metadata attached to an identity identifier of 1031 an endpoint. For example, an internal collection task associated 1032 with an endpoint security service might publish posture attribute 1033 metadata attached to the identity identifier of an endpoint when 1034 required security software is not running to notify consumers of 1035 the current state of the endpoint. 1037 4.2.3. Relationships between Identifiers and Metadata 1039 Interaction between multiple sets of identifiers and metadata lead to 1040 some fairly common patterns, or "constellations", of metadata. For 1041 example, an authenticated-session metadata constellation might 1042 include a central network session with authorizations and location 1043 attached, and links to a user identity, an endpoint identity, a MAC 1044 address, an IP address, and the identity of the policy server that 1045 authorized the session, for the duration of the network session. 1047 These constellations may be independent of each other, or one 1048 constellation may be connected to another. For example, an 1049 authenticated-session metadata constellation may be created when a 1050 user connects an endpoint to the network; separately, an endpoint- 1051 posture metadata constellation may be created when an endpoint 1052 security system and other collection tasks gather and publish posture 1053 information related to an endpoint. These two constellations are not 1054 necessarily connected to each other, but may be joined if the 1055 component publishing the authenticated-session metadata constellation 1056 is able to link the network session identifier to the identity 1057 identifier of the endpoint. 1059 4.3. Workflow 1061 The workflow for exchange of information supporting detection of 1062 posture deviation, using a standard publish/subscribe/query transport 1063 model such as available with IF-MAP [10] or XMPP-Grid [27], is as 1064 follows: 1066 5. The analytics engine (Posture Assessment Information Consumer) 1067 establishes connectivity and authorization with the transport 1068 fabric, and subscribes to updates on posture deviations. 1070 6. The endpoint security service (Posture Assessment Information 1071 Provider) requests connection to the transport fabric. 1073 7. Transport fabric authenticates and establishes authorized 1074 privileges (e.g. privilege to publish and/or subscribe to security 1075 data) for the requesting components. 1077 8. The endpoint security service evaluates the endpoint, detects 1078 posture deviation, and publishes information on the posture 1079 deviation. 1081 9. The transport fabric notifies the analytics engine, based on its 1082 subscription of the new posture deviation information. 1084 Other components, such as access control policy servers or 1085 remediation systems, may also consume the posture deviation 1086 information provided by the endpoint security service. 1088 5. Security Considerations 1090 The TNC IF-MAP Binding for SOAP [10] and TNC IF-MAP Metadata for 1091 Network Security [11] document security considerations for sharing 1092 information via security automation. Most, and possibly all, of 1093 these considerations also apply to information shared via this 1094 proposed information model. 1096 6. IANA Considerations 1098 This memo includes no requests to IANA. 1100 7. Conclusion 1102 The proposed SACM Information Model is designed to ensure 1103 adaptability for changing networking environments, as well as 1104 interoperability with a variety of transport protocols. 1106 8. References 1108 8.1. Informative References 1110 [1] Trusted Computing Group, "TNC Architecture", Specification 1111 Version 1.5, May 2012. 1113 [2] Trusted Computing Group, "TNC IF-M: TLV Binding", Specification 1114 Version 1.0, May 2014. 1116 [3] Trusted Computing Group, "TNC IF-TNCCS: TLV Binding", 1117 Specification Version 2.0, May 2014. 1119 [4] Trusted Computing Group, "TNC IF-T: Protocol Bindings for 1120 Tunneled EAP Methods", Specification Version 2.0, May 2014. 1122 [5] Trusted Computing Group, "TNC IF-T: Binding to TLS", 1123 Specification Version 2.0, February 2013. 1125 [6] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1126 Protocol (PA) Compatible with TNC", RFC 5792, March 2010. 1128 [7] Sahita, R., Hanna, S., Hurst, R., and K. Narayanan, "PB-TNC: A 1129 Posture Broker (PB) Protocol Compatible with Trusted Network 1130 Connect (TNC)", RFC 5793, March 2010. 1132 [8] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) 1133 Protocol For Extensible Authentication Protocol (EAP) Tunnel 1134 Methods", RFC 7171, April 2014. 1136 [9] Sangster, P., Cam-Winget, N., and J. Salowey, "PT-TLS: A TCP- 1137 based Posture Transport (PT) Protocol", RFC 6876, February 1138 2013. 1140 [10] Trusted Computing Group, "TNC IF-MAP Binding for SOAP", 1141 Specification Version 2.2, March 2014. 1143 [11] Trusted Computing Group, "TNC IF-MAP Metadata for Network 1144 Security", Specification Version 1.1, May 2012. 1146 [12] Trusted Computing Group, "TNC IF-MAP Metadata for ICS 1147 Security", Specification Version 1.0, May 2014. 1149 [13] W3C, "SOAP Version 1.2" Part 1: Messaging Framework (Second 1150 Edition), April 2007. 1152 [14] W3C, "RDF W3C, "RDF 1.1 Concepts and Abstract Syntax", version 1153 1.1, February 2014. 1155 [15] Bjorklund, M. (Editor), "YANG - A Data Modeling Language for 1156 the Network Configuration Protocol (NETCONF)", RFC 6020, 1157 October 2010. 1159 [16] Cam-Winget, N., Ford, B., Lorenzin, L., McDonald, I., and A. 1160 Woland, "Secure Automation and Continuous Monitoring (SACM) 1161 Architecture", draft-camwinget-sacm-architecture-00 (work in 1162 progress), June 2014. 1164 [17] Waltermire, D., and D. Harrington, "Endpoint Security Posture 1165 Assessment - Enterprise Use Cases", draft-ietf-sacm-use-cases- 1166 07 (work in progress), April 2014. 1168 [18] Object Management Group, "Unified Modeling Language TM (UML 1169 (R))", Version 2.4.1, August 2011. 1171 [19] Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1172 Winget, "Terminology for Security Assessment", draft-ietf-sacm- 1173 terminology-04 (work in progress), May 2014. 1175 [20] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 1176 R., and W. Polk, "Internet X.509 Public Key Infrastructure 1177 Certificate and Certificate Revocation List (CRL) Profile", RFC 1178 5280, May 2008. 1180 [21] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 1181 August 2007. 1183 [22] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1184 Tardo, "Network Endpoint Assessment (NEA): Overview and 1185 Requirements", RFC 5209, June 2008. 1187 [23] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 1188 "IEEE 802.1X Remote Authentication Dial In User Service 1189 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1191 [24] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1193 [25] Claise, B., "Cisco Systems NetFlow Services Export Version 9", 1194 RFC 3954, October 2004. 1196 [26] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1197 "Host Identity Protocol", RFC 5201, April 2008. 1199 [27] Salowey, J. (Ed.), Lorenzin, L., Kahn, C., Pope, S., Appala, 1200 S., and N. Cam-Winget, "XMPP Protocol Extensions for Use in 1201 SACM Information Transport", draft-salowey-sacm-xmpp-grid-00 1202 (work in progress), July 2014. 1204 9. Acknowledgments 1206 The authors would like to acknowledge the contributions, authoring, 1207 and/or editing of the following people: Syam Appala, Nancy Cam- 1208 Winget, Jessica Fitzgerald-McKay, Steve Hanna, and Aaron Woland. 1210 This document was prepared using 2-Word-v2.0.template.dot. 1212 Appendix A. Examples of TNC IF-MAP in Security Deployments 1214 IF-MAP has been continually enhanced by the Trusted Computing Group, 1215 culminating in the most recent version, IF-MAP 2.2, published in 1216 March 2014. Vendors have been shipping IF-MAP enabled products since 1217 2008 to provide an ecosystem that supports standardized, dynamic 1218 security data interexchange among a wide variety of networking and 1219 security components. IF-MAP has focused on providing a standardized 1220 information model that can be utilized for data interoperability 1221 between vendors. 1223 IF-MAP has been deployed most commonly for: 1225 o Seamless remote and local access control, providing single sign-on 1226 for either initial access to a network, or remote access to a 1227 network, coordinated with access control enforcement deeper in the 1228 network 1230 o Integration of physical and logical access control, so user 1231 location obtained from a badge access system can be used as input 1232 into a network access policy decision 1234 o Usage of IF-MAP as a point of coordination for industrial control 1235 system security, for policy enforcement and certificate lifecycle 1236 management 1238 o Leveraging IP address mappings to MAC addresses from DHCP servers 1239 to enable network-based enforcement for MAC authenticated devices 1241 o Integration of detailed behavioral information from threat sensors 1242 -- such as IPS, endpoint profiling / behavior monitoring, and 1243 network leak detection systems -- into network access control 1244 policy decisions 1246 Additional use cases explored include: 1248 o A content management database (CMDB) receives notification of a 1249 new device on the network -- perhaps via notification that a DHCP 1250 server has assigned an IP address to a new MAC address -- and 1251 scans the new endpoint, then updates its data store. 1253 o A security administrator modifies an existing security policy, or 1254 adds a new policy, and various policy servers / sensors are 1255 notified, triggering a re-evaluation of the network's endpoints. 1257 o An application server publishes a request for bandwidth for a 1258 particular user based on the service the user is accessing; 1259 network infrastructure components change QoS settings for those 1260 traffic flows based on that request. 1262 o An analysis system determines that there's an attack underway; in 1263 addition to triggering a response, it notifies security 1264 administrators of the attack taking place, populating a dashboard 1265 with information to create a "heat map" of the attack. 1267 Authors' Addresses 1269 Cliff Kahn 1270 Juniper Networks, Inc. 1271 10 Technology Park Drive 1272 Westford, MA 01886 1273 USA 1275 Email: cliffordk@juniper.net 1277 Lisa Lorenzin 1278 Juniper Networks, Inc. 1279 3614 Laurel Creek Way 1280 Durham, NC 27712 1281 USA 1283 Email: llorenzin@juniper.net 1285 Steven Venema 1286 The Boeing Company 1287 PO Box 3707, MC 4C-77 1288 Seattle, WA 98124-2207 1290 Email: steven.c.venema@boeing.com 1292 Scott Pope 1293 Cisco Systems 1294 5400 Meadows Road 1295 Suite 300 1296 Lake Oswego, OR 97035 1297 USA 1299 Email: scottp@cisco.com 1301 Henk Birkholz 1302 Fraunhofer SIT 1303 Rheinstrasse 75 1304 64295 Darmstadt 1305 Germany 1307 Email: henk.birkholz@sit.fraunhofer.de