idnits 2.17.1 draft-combined-sacm-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 abstract seems to contain references ([TNC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 (September 7, 2014) is 3516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 3161 == Unused Reference: 'TNC-IF-M-TLV-Binding' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'TNC-IF-T-TLS' is defined on line 1560, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-05 == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-07 == Outdated reference: A later version (-02) exists of draft-salowey-sacm-xmpp-grid-00 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Waltermire, Ed. 3 Internet-Draft NIST 4 Intended status: Informational K. Watson 5 Expires: March 11, 2015 DHS 6 C. Kahn 7 L. Lorenzin 8 Juniper Networks, Inc. 9 September 7, 2014 11 SACM Information Model 12 draft-combined-sacm-information-model-00 14 Abstract 16 TODO: reconcile 18 [TNC]This document proposes an information model for endpoint posture 19 assessment. It describes the information needed to perform certain 20 assessment activities and to communicate and respond to the 21 assessments.[/TNC] 23 [wandw]This document defines an information model for aggregated 24 configuration and operational data, so that the data can be evaluated 25 to determine an organization's security posture.[/wandw] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 11, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Mapping to SACM Use Cases . . . . . . . . . . . . . . . . 6 64 3. Conventions used in this document . . . . . . . . . . . . . . 7 65 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 66 4. Elements of the SACM Information Model . . . . . . . . . . . 7 67 4.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1.1. Unique Endpoint Identifier . . . . . . . . . . . . . 9 69 4.1.2. Endpoint Credential . . . . . . . . . . . . . . . . . 9 70 4.1.3. Software Component . . . . . . . . . . . . . . . . . 10 71 4.1.3.1. Unique Software Identifier . . . . . . . . . . . 10 72 4.1.4. Software Instance . . . . . . . . . . . . . . . . . . 11 73 4.1.5. Hardware Component . . . . . . . . . . . . . . . . . 11 74 4.1.6. Hardware Instance . . . . . . . . . . . . . . . . . . 11 75 4.2. Internal Attribute Collector . . . . . . . . . . . . . . 11 76 4.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.3.1. User Credential . . . . . . . . . . . . . . . . . . . 12 78 4.4. Network Session . . . . . . . . . . . . . . . . . . . . . 12 79 4.4.1. Address . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.4.2. Authorizations . . . . . . . . . . . . . . . . . . . 12 81 4.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.6. External Attribute Collector . . . . . . . . . . . . . . 13 83 4.7. Endpoint Attribute Assertion . . . . . . . . . . . . . . 14 84 4.7.1. Form and Precise Meaning . . . . . . . . . . . . . . 14 85 4.7.2. Source . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 87 4.7.4. A Use Case . . . . . . . . . . . . . . . . . . . . . 15 88 4.7.5. Posture Attribute . . . . . . . . . . . . . . . . . . 15 89 4.7.6. Event . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.7.7. Difference between Attribute and Event . . . . . . . 16 91 4.8. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.9. Evaluation Result . . . . . . . . . . . . . . . . . . . . 17 93 4.10. Report Generator . . . . . . . . . . . . . . . . . . . . 17 94 4.11. Report . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.12. Organization? . . . . . . . . . . . . . . . . . . . . . . 18 96 4.13. Guidance . . . . . . . . . . . . . . . . . . . . . . . . 19 97 4.13.1. Internal Collection Guidance . . . . . . . . . . . . 19 98 4.13.2. External Collection Guidance . . . . . . . . . . . . 19 99 4.13.3. Evaluation Guidance . . . . . . . . . . . . . . . . 19 100 4.13.4. Retention Guidance . . . . . . . . . . . . . . . . . 19 101 4.13.5. Reporting Guidance . . . . . . . . . . . . . . . . . 19 102 4.14. Provenance of Information . . . . . . . . . . . . . . . . 20 103 5. Graph Model . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 5.1. Background: Graph Models . . . . . . . . . . . . . . . . 21 105 5.2. Graph Model Overview . . . . . . . . . . . . . . . . . . 21 106 5.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 22 107 5.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 5.5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 22 109 5.6. Use for SACM . . . . . . . . . . . . . . . . . . . . . . 23 110 5.7. Provenance . . . . . . . . . . . . . . . . . . . . . . . 23 111 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24 112 6. SACM Usage Scenario Example . . . . . . . . . . . . . . . . . 24 113 6.1. Graph Model for Detection of Posture Deviation . . . . . 24 114 6.1.1. Components . . . . . . . . . . . . . . . . . . . . . 25 115 6.1.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 25 116 6.1.3. Metadata . . . . . . . . . . . . . . . . . . . . . . 26 117 6.1.4. Relationships between Identifiers and Metadata . . . 26 118 6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 27 119 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 120 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 121 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 122 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 123 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 124 10.2. Informative References . . . . . . . . . . . . . . . . . 29 125 Appendix A. Security Automation with TNC IF-MAP . . . . . . . . 34 126 A.1. What is Trusted Network Connect? . . . . . . . . . . . . 34 127 A.2. What is TNC IF-MAP? . . . . . . . . . . . . . . . . . . . 35 128 A.3. What is the TNC Information Model? . . . . . . . . . . . 35 129 Appendix B. Text for Possible Inclusion in the Terminology Draft 36 130 B.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 36 131 B.1.1. Pre-defined and Modified Terms . . . . . . . . . . . 36 132 B.1.2. New Terms . . . . . . . . . . . . . . . . . . . . . . 37 133 Appendix C. Text for Possible Inclusion in the Architecture or 134 Use Cases . . . . . . . . . . . . . . . . . . . . . 37 135 C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 37 136 C.2. Core Principles . . . . . . . . . . . . . . . . . . . . . 38 137 C.3. Architecture Assumptions . . . . . . . . . . . . . . . . 39 138 Appendix D. Text for Possible Inclusion in the Requirements 139 Draft . . . . . . . . . . . . . . . . . . . . . . . 43 140 D.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 43 141 D.2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 43 142 Appendix E. Text With No Clear Home Yet . . . . . . . . . . . . 44 143 E.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 44 144 E.1.1. Generalized Workflow . . . . . . . . . . . . . . . . 44 146 E.2. From Information Needs to Information Elements . . . . . 45 147 E.3. Information Model Elements . . . . . . . . . . . . . . . 45 148 E.3.1. Asset Identifiers . . . . . . . . . . . . . . . . . . 47 149 E.3.1.2. Endpoint Identification . . . . . . . . . . . . . 49 150 E.3.1.3. Software Identification . . . . . . . . . . . . . 50 151 E.3.1.4. Hardware Identification . . . . . . . . . . . . . 53 152 E.3.2. Other Identifiers . . . . . . . . . . . . . . . . . . 53 153 E.3.2.1. Platform Configuration Item Identifier . . . . . 53 154 E.3.2.2. Configuration Item Identifier . . . . . . . . . . 59 155 E.3.2.3. Vulnerability Identifier . . . . . . . . . . . . 61 156 E.3.3. Endpoint characterization . . . . . . . . . . . . . . 61 157 E.3.4. Posture Attribute Expression . . . . . . . . . . . . 65 158 E.3.4.2. Platform Configuration Attributes . . . . . . . . 65 159 E.3.5. Actual Value Representation . . . . . . . . . . . . . 67 160 E.3.5.1. Software Inventory . . . . . . . . . . . . . . . 67 161 E.3.5.2. Collected Platform Configuration Posture 162 Attributes . . . . . . . . . . . . . . . . . . . 68 163 E.3.6. Evaluation Guidance . . . . . . . . . . . . . . . . . 69 164 E.3.6.1. Configuration Evaluation Guidance . . . . . . . . 69 165 E.3.7. Evaluation Result Reporting . . . . . . . . . . . . . 71 166 E.3.7.1. Configuration Evaluation Results . . . . . . . . 71 167 E.3.7.2. Software Inventory Evaluation Results . . . . . . 73 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 170 1. Introduction 172 TODO: reconcile 174 [TNC]This document proposes an information model to serve the 175 security automation use- cases outlined by the IETF SACM 176 workgroup.[/TNC] 178 [wandw]This draft was developed in response to the Call for 179 Contributions for the SACM Information Model sent to NIST 180 [IM-LIAISON-STATEMENT-NIST]. This draft proposes a notional 181 information model for endpoint posture assessment. It describes the 182 information needed to perform certain assessment activities and 183 relevant work that may be used as a basis for the development of 184 specific data models. The terms information model and data model 185 loosely align with the terms defined in RFC3444 [RFC3444]. 187 The four primary activities to support this information model are: 189 1. Endpoint Identification 191 2. Endpoint Characterization 193 3. Endpoint Attribute Expression/Representation 194 4. Policy evaluation expression and results reporting 196 These activities are aimed at the level of the technology that 197 performs operations to support collection, evaluation, and reporting. 199 Review of the SACM Use Case [I-D.ietf-sacm-use-cases] usage scenarios 200 show a common set of business process areas that are critical to 201 understanding endpoint posture such that appropriate policies, 202 security capabilities, and decisions can be developed and 203 implemented. 205 For this information model we have chosen to focus on the following 206 business process areas: 208 o Endpoint Management 210 o Software Management 212 o Configuration Management 214 o Vulnerability Management 216 These management process areas are a way to connect the SACM use 217 cases and building blocks [I-D.ietf-sacm-use-cases] to the 218 organizational needs such that the definition of information 219 requirements has a clearly understood context.[/wandw] 221 [TNC]The proposed SACM information model offers a loose coupling 222 between providers and consumers of security information. A provider 223 can relay what it observes or infers, without knowing which consumers 224 will use the information, or how they will use it. A consumer need 225 not know exactly which provider generated a piece of information, or 226 by what method. 228 At the same time, a consumer *can* know these things, if necessary. 230 As things evolve, a provider can relay supplemental information. 231 Some consumers will understand and benefit from the supplemental 232 information; other consumers will not understand and will disregard 233 it. 235 The structure of each unit of information is extensible. The 236 arrangement of information units into a graph is also extensible; new 237 arrangements can be defined for new use cases.[/TNC] 239 2. Problem Statement 241 TODO: revise 243 [wandw]SACM requires a large and broad set of mission and business 244 processes, and to make the most effective of use of technology, the 245 same data must support multiple processes. The activities and 246 processes described within this document tend to build off of each 247 other to enable more complex characterization and assessment. In an 248 effort to create an information model that serves a common set of 249 management processes represented by the usage scenarios in the SACM 250 Use Cases document, we have narrowed down the scope of this 251 model.[/wandw] [What does "narrowed down the scope of this model" 252 mean? - LL] 254 Administrators can't get technology from disparate sources to work 255 together; they need information to make decisions, but the 256 information is not available. Everyone is collecting the same data, 257 but storing it as different information. Administrators therefore 258 need to collect data and craft their own information, which may not 259 be accurate or interoperable because it's customized by each 260 administrator, not shared. A standard information model enables 261 flexibility in collecting, storing, and sharing information despite 262 platform differences. 264 A way is needed to exchange information that (a) has breadth, meaning 265 the pieces of the notation are useful about a variety of endpoints 266 and software components, and (b) has longevity, meaning that the 267 pieces of the notation will stay useful over time. 269 When creating standards, it's not sufficient to go from requirements 270 directly to protocol; the standards must eliminate ambiguity in the 271 information transported. This is the purpose of information models 272 generally. The SACM problem space is about integrating many 273 information sources. This information model addresses the need to 274 integrate security components, support multiple data models, and 275 provide interoperability in a way that is platform agnostic, scales, 276 and works over time. 278 2.1. Mapping to SACM Use Cases 280 TODO: revise 282 [wandw]This information model directly corresponds to all four use 283 cases defined in the SACM Use Cases draft [I-D.ietf-sacm-use-cases]. 284 It uses these use cases in coordination to achieve a small set of 285 well-defined tasks. 287 Sections [removed] thru [removed] address each of the process areas. 288 For each process area, a "Process Area Description" sub-section 289 represent an end state that is consistent with all the General 290 Requirements and many of the Use Case Requirements identified in the 291 requirements draft [I-D.camwinget-sacm-requirements]. 293 The management process areas and supporting operations defined in 294 this memo directly support REQ004 Endpoint Discovery; REQ005-006 295 Attribute and Information Based Queries, and REQ0007 Asynchronous 296 Publication. 298 In addition, the operations that defined for each business process in 299 this memo directly correlate with the typical workflow identified in 300 the SACM Use Case document.[/wandw] 302 3. Conventions used in this document 304 3.1. Requirements Language 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 308 document are to be interpreted as described in RFC 2119 [RFC2119]. 310 4. Elements of the SACM Information Model 312 The proposed SACM Information Model contains several elements of the 313 architecture, including: 315 o Collectors, which may be internal (performed within the endpoint 316 itself) or external (performed outside of the endpoint, such as by 317 a hypervisor or remote sensor) 319 o Posture, in the form of posture attributes and evaluation results 321 o Additional information about the endpoint, such as a 322 representation of a software component, endpoint identity, user 323 identity, address, location, and authorization constraining the 324 endpoint 326 o History, a compilation of previously collected information [cek: 327 We don't model history per se. We have reports, which could be a 328 compilation of present information and/or of historical 329 information. I think it's helpful that the past and present are 330 modeled the same. They won't be implemented the same, but this is 331 an information model. So, can we remove this bullet?] 333 Figure 1 depicts the elements of the information model. Each element 334 has a meaning -- a denotation. 336 +---------+ +---------+ +--------+____________________ 337 |Hardware | |Software | __________|Location|*_______________ | 338 |Component| |Component| | *+--------+* | | 339 +---------+ +---------+ | | | 340 |1 |1 | +----------+ | | 341 |* |* | ______|Credential|____________ | | 342 +---------+ +--------+ | | *+----------+* |* |* | 343 |Hardware | |Software| | | +---------+ +----+ | 344 |Instance | |Instance| | | |Network |_________|User| | 345 +---------+ +--------+ | | |Session |* 0..1+----+ | 346 |* |* *| *| |- - - - -| *| 347 | |___1+-----------+1______*|Network |__________+-------+ 348 |____________| Endpoint |_____ |Interface|* 1..*|Address| 349 1| |0..1 | +---------+ +-------+ 350 +-----------+ | 1| 351 |0..1 1| |* | |_____+-------------+ 352 v| | |______| *|Authorization| 353 | | part-of> +-------------+ 354 .................. |* .... | ........................................ 355 ------------ +---------+ | ------------ 356 |Collection|_>_|Attribute| | |Evaluation|__>__+----------+ 357 |Guidance |1 *|Collector| |v |Guidance |1 *|Evaluator | 358 ------------ +---------+ | ------------ +----------+ 359 |1 | 1| 360 v| | |v 361 |* |* *| 362 ===========_______________________============ 363 +----------+ |Endpoint |1..* > *|Evaluation| 364 |Attribute/|________|Attribute|_____-----------_______|Result | 365 |Event |1..* 1|Assertion|* < *|Retention|* > *============ 366 +----------+ =========== |Guidance |____ *| 367 *| -----------* | | 368 ----------- +---------+ | ======== |v | 369 |Reporting| |Report | |___>___*|Report|*____| | 370 |Guidance |__>__|Generator|___________| |______________| 371 -----------1 *+---------+1 > *========* < 373 ------------------------------------------------------------- 374 1 Multiplicity symbols > < Direction of causation. For 375 0..1 found in UML 2 v ^ example, collection guidance 376 * class diagrams affects a collector. 377 1..* 378 ..... Above this line is the 379 monitorable world 380 ------------------------------------------------------------- 382 Figure 1: Elements and Multiplicity 384 Note: UML 2 is specified by [UML]. 386 The following subsections elaborate upon the elements found in the 387 two figures. 389 4.1. Endpoint 391 See the definition in the SACM Terminology for Security Assessment 392 [I-D.ietf-sacm-terminology]. 394 In the model, an endpoint can be part of another endpoint. This 395 covers cases where multiple physical endpoints act as one endpoint. 396 The constituent endpoints may not be distinguishable by external 397 observation of network behavior. 399 For example, a hosting center may maintain a redundant set 400 (redundancy group) of multi-chassis setups to provide active 401 redundancy and load distribution on network paths to WAN gateways. 402 Multi-chassis link aggregation groups make the chassis appear as one 403 endpoint. Traditional security controls must be applied either to 404 physical endpoints or the redundancy groups they compose (and 405 occasionally both). Loss of redundancy is difficult to detect or 406 mitigate without specific posture information about the current state 407 of redundancy groups. Even if a physical endpoint (e.g. router) that 408 is part of a redundancy group is replaced, the redundancy group can 409 remain the same. 411 EDITOR'S NOTE: The endpoints to which an endpoint connects affects 412 its security posture. Should we add peer endpoints to the model? 414 4.1.1. Unique Endpoint Identifier 416 An organization needs to uniquely identify and label an endpoint, 417 whether the endpoint is enrolled or is discovered in the operational 418 environment. The identifier should be assigned by or used in the 419 enrollment process. 421 Here "unique" means one-to-one. In practice, uniqueness is not 422 always attainable. Even if an endpoint has a unique identifier, an 423 attribute collector may not always know it. 425 4.1.2. Endpoint Credential 427 An endpoint credential provides both identification and 428 authentication of the endpoint. For example, a credential may be an 429 X.509 certificate [RFC5280] and corresponding private key. [jmf- 430 this example should be formatted like the other examples in this 431 section] 432 Not all kinds of credentials are guaranteed to be unique. 434 4.1.3. Software Component 436 An endpoint contains and runs software components. 438 Some of the software components are assets. "Asset" is defined in 439 RFC4949 [RFC4949] as "a system resource that is (a) required to be 440 protected by an information system's security policy, (b) intended to 441 be protected by a countermeasure, or (c) required for a system's 442 mission." 444 An examination of software needs to consider both (a) software assets 445 and (b) software that may do harm. A posture attribute collector may 446 not know (a) from (b). It is useful to define Software Component as 447 the union of (a) and (b). 449 Examples of Software Assets: 451 o An application 453 o A patch 455 o The operating system kernel 457 o A boot loader 459 o Firmware that controls a disk drive 461 o A piece of JavaScript found in a web page the user visits 463 Examples of harmful software components: 465 o An entertainment app that contains malware 467 o A malicious executable 469 o A web page that contains malicious JavaScript 471 o A business application that shipped with a virus 473 4.1.3.1. Unique Software Identifier 475 Organizations need to be able to uniquely identify and label software 476 installed or run on an endpoint. Specifically, they need to know the 477 name, publisher, unique ID, and version; and any related patches. In 478 some cases the software's identity might be known a priori by the 479 organization; in other cases, a software identity might be first 480 detected by an organization when the software is first inventoried in 481 an operational environment. Due to this, it is important that an 482 organization have a stable and consistent means to identify software 483 found during collection. 485 A piece of software may have a unique identifier, such as a SWID tag 486 (ISO/IEC 19770). 488 4.1.4. Software Instance 490 Each copy of a piece of software is called a software instance. The 491 configuration of a software instance is regarded as part of the 492 software instance. Configuration can strongly affect security 493 posture. 495 4.1.5. Hardware Component 497 Hardware components may also be assets and or harmful. For example, 498 a USB port on a system may be disabled to prevent information flow 499 into our out of a particular system; this provides an additional 500 layer of protection that can complement software based protections. 501 Other such assets may include access to or modification of storage 502 media, hardware key stores, microphones and cameras. Like software 503 assets, we can consider these hardware components both from the 504 perspective of (a) an asset that needs protection and (b) an asset 505 that can be compromised in some way to do harm. 507 A hardware component is often designated by a manufacturer and a part 508 number. 510 4.1.6. Hardware Instance 512 A hardware instance is just an instance of a particular component. A 513 hardware instance often has a unique serial number. 515 Hardware instances may need to be modeled because (a) an endpoint may 516 have multiple instances of a hardware component, (b) a hardware 517 instance may be compromised, whereas other instances may remain 518 intact. 520 4.2. Internal Attribute Collector 522 An endpoint may also contain one or more internal collectors. 524 An internal attribute collector is an attribute collector that 525 collects posture attributes, values, or events from inside the 526 endpoint. In other words, the posture attributes and events are self 527 reported. 529 Example: a NEA posture collector. [RFC5209] 531 4.3. User 533 4.3.1. User Credential 535 An endpoint is often - but not always - associated with one or more 536 users. 538 A user's credential provides both identification and authentication 539 of the user. 541 4.4. Network Session 543 An endpoint generally has a connection to a network, referred to here 544 as a network session. A multi-homed endpoint may have more than one 545 network session. 547 4.4.1. Address 549 A network session generally is associated with addresses, such as MAC 550 and IP addresses. 552 These addresses are not necessarily globally unique. Therefore, an 553 address may be qualified with a scope. For example: 555 o A MAC address may be qualified with its layer-2 broadcast domain. 557 o An IP address may be qualified with its IP routing domain. 559 Other kinds of addresses may find application. 561 4.4.2. Authorizations 563 Authorizations determine what the endpoint can do with its network 564 session. Examples include: 566 o A RADIUS VLAN assignment [RFC3580] 568 o A router or firewall access control list (ACL) 570 o An IF-MAP access-request constellation 571 [TNC-IF-MAP-NETSEC-METADATA], which may determine how a firewall 572 treats the endpoint 574 4.5. Location 576 Location can be logical or physical, and may be pertinent to security 577 posture. For example, some endpoints may need to stay in protected 578 areas for their own protection. 580 Examples of location: 582 o The switch or access point to which the endpoint has authenticated 584 o The switch port where the endpoint is plugged in 586 o The location of the endpoint's IP address in the network topology 588 o The geographic location of the endpoint (typically self-reported) 590 o A user location (typically reported by a physical access control 591 system) 593 More than one of these may pertain to an endpoint. Endpoint has a 594 many-to-many relationship with Location. 596 A collector or other system may express location information as 597 posture attributes. 599 4.6. External Attribute Collector 601 An external collector is a collector that observes endpoints from 602 outside. [kkw-many of these [collectors] are actually configured and 603 operated to manage assets for reasons other than posture assessments. 604 it is critical to bring them into this, so i like it...but does it 605 matter if the [collector] isn't intended to support posture 606 assessment, but happens to have information that can be used by 607 posture assessment collection consumers? do we lump them together 608 with collectors that are intended to support posture assessment but 609 run external to the endpoint?] [jmf: ditto. The exampled below are 610 of things that would perform external collection]. 612 [cek-to kkw's comment, I think the purpose here is to capture their 613 contribution to continuous monitoring. I don't see the need to 614 separate things whose primary job is monitoring from things whose 615 primary job is something else. Is there a need?] 617 [cek-to jmf's comment, that is what they are examples of; is a text 618 change needed?] 620 Examples: 622 o A RADIUS server whereby an endpoint has logged onto the network 624 o A network profiling system, which discovers and classifies network 625 nodes 627 o A Network Intrusion Detection System (NIDS) sensor 629 o A vulnerability scanner 631 o A hypervisor that peeks into the endpoint, the endpoint being a 632 virtual machine 634 o A management system that configures and installs software on the 635 endpoint 637 4.7. Endpoint Attribute Assertion 639 4.7.1. Form and Precise Meaning 641 An endpoint attribute assertion contains: 643 o One or more attribute-value pairs 645 o Optionally, one or more events 647 o A time interval 649 o Endpoint uniquely identified? True or false 651 It means: 653 o Over the specified time interval, there was an endpoint for which 654 all of the listed attribute-value pairs were true. 656 o For that endpoint, each event happened sometime during the time 657 interval. (This is meant as a normative definition of the 658 semantics of an endpoint attribute assertion.) 660 o If the "Endpoint uniquely identified" is true, the set of 661 attributes-value pairs together make this assertion apply to only 662 one endpoint. 664 The attributes can include posture attributes and identification 665 attributes. The model does not make a rigid distinction between the 666 two uses of attributes. 668 Some of the attributes may be multi-valued. 670 An Endpoint Attribute Assertion may or may not include a unique 671 endpoint identifier. Not every endpoint will have one. If there is 672 one, the SACM component that produces the Endpoint Attribute 673 Assertion will not necessarily know what it is. 675 4.7.2. Source 677 An Endpoint Attribute Assertion is typically provided by an attribute 678 collector. However, we envision some SACM components that produce 679 Endpoint Attribute Assertions from out-of-band sources, such as a 680 physical inventory system. We also envision some deriving Endpoint 681 Attribute Assertions from other Endpoint Attribute Assertions. 683 4.7.3. Example 685 For example, an attribute assertion might have these attribute-value 686 pairs: 688 mac-address = 01:23:45:67:89:ab 690 os = OS X 692 os-version = 10.6.8 694 This asserts that an endpoint with MAC address 01:23:45:67:89:ab ran 695 OS X 10.6.8 throughout the specified time interval. A profiler might 696 have provided this assertion. 698 4.7.4. A Use Case 700 For example, Endpoint Attribute Assertions should help SACM 701 components to track an endpoint as it roams or stays stationary. 702 They must track it to track the endpoint's posture over time. 703 Tracking of an endpoint can employ many clues, such as: 705 The endpoint's MAC address 707 The authenticated identity (even if it identifies a user) 709 The location of the endpoint and the user 711 4.7.5. Posture Attribute 713 See the definition in the SACM Terminology for Security Assessment 714 [I-D.ietf-sacm-terminology]. 716 Examples: 718 o A NEA posture attribute (PA) [RFC5209] 720 o A YANG model [RFC6020] 722 o An IF-MAP device-characteristics metadata item 723 [TNC-IF-MAP-NETSEC-METADATA] 725 4.7.6. Event 727 Examples: 729 o A structured syslog message [RFC5424] 731 o IF-MAP event metadata [TNC-IF-MAP-NETSEC-METADATA] 733 o A NetFlow message [RFC3954] 735 4.7.7. Difference between Attribute and Event 737 "Attribute" and "event" are often used fairly interchangeably. A 738 clear distinction makes the words more useful. 740 An *attribute* tends to stay true until something causes a change. 741 In contrast, an *event* occurs at a moment in time. 743 For a nontechnical example, "closed" is an attribute of a door. A 744 closed door tends to stay closed until something opens it (a breeze, 745 a person, or a dog). 747 The door's opening or closing is an event. 749 Similarly, "Host firewall is enabled?" may be modeled as an endpoint 750 attribute. Enabling or disabling the host firewall may be modeled as 751 an event. An endpoint's crashing also may be modeled as an event. 753 4.8. Evaluator 755 An evaluator can consume endpoint attribute assertions, previous 756 evaluations of posture attributes, or previous reports of evaluation 757 results. [kkw-i don't think this conflicts with the definition in the 758 terminology doc re: that evaluation tasks evaluate posture 759 attributes.] 761 [cek-I like the change. I think it *does* require a change in the 762 terminology doc, though.] 764 Example: a NEA posture validator [RFC5209] 766 [jmf- a NEA posture validator is not an example of this definition. 767 A NEA posture assessment is, maybe?] 769 [cek-Why isn't a NEA posture validator an example?] 771 4.9. Evaluation Result 773 See the definition in the SACM Terminology for Security Assessment 774 [I-D.ietf-sacm-terminology]. 776 Example: a NEA access recommendation [RFC5793] 778 As Figure 1 shows, an Evaluation Result derives from one or more 779 Posture Attributes and Events. 781 An evaluator may be able to evaluate better if history is available. 782 This is a use case for retaining Posture Attributes and Events for a 783 time. 785 An Evaluation Result may be retained longer than the Endpoint 786 Attribute Assertions from which it derives. (Figure 1 does not show 787 this.) In the limiting case, Endpoint Attribute Assertions are not 788 retained. When as an Endpoint Attribute Assertion arrives, an 789 evaluator produces an Evaluation Result. 791 4.10. Report Generator 793 A report generator makes reports based on: 795 o Endpoint Attribute Assertions, 797 o Evaluation Results, and/or 799 o Other Reports (a weekly report may be created from daily reports) 801 It may summarize data continually, as the data arrives. It also may 802 summarize data in response to an ad hoc query. 804 4.11. Report 806 A Report summarizes: 808 o Endpoint Attribute Assertions, 810 o [kkw-if we state that a software asset is a type of posture 811 attribute, then a software inventory is nothing more than a report 812 that summarizes all software assets for an endpoint. i think this 813 makes much more sense than adding an object that is the software 814 inventory. contingent on adding the fact that an evaluator can 815 operate on posture attributes, evaluation results, or reports.] 817 o [cek - I like the move of saying that an inventory is a type of 818 report. Let's.] 820 o [cek - I like the move of defining a posture attribute whose value 821 is the identifier of a software component.] 823 o [cek - I'm not sure I'd say that a software asset is a type of 824 posture attribute, though. There's description and there's 825 reality. I'd tend to say that a posture attribute (always) a 826 partial description of an endpoint, and is the output of a posture 827 attribute collector. Suppose there's a stealthy piece of malware 828 that hasn't been detected. It's a software component, but is it a 829 posture attribute? I'm not sure how to talk about this.] 831 o Events, and/or 833 o Evaluation Results 835 A Report may routine or ad hoc. 837 Some reports may be machine readable. Machine readable summaries may 838 be consumable by automatic response systems (not part of SACM). 840 4.12. Organization? 842 [kkw-from a reporting standpoint there needs to be some concept like 843 organization or system. without this, there is no way to produce 844 result reports that can be acted upon to provide the insight or 845 accountability that almost all continuous monitoring instances are 846 trying to achieve. from a scoring or grading standpoint, an endpoint 847 needs to be associated with exactly one organization or system. it 848 can have a many to many relationship with other types of results 849 reporting "bins". is this important to include here? we had 850 organization as a core asset type for this reason, so i think it is a 851 key information element. but i also know that i do not want to define 852 all the different reporting types, so i am unsure.] 854 [cek-I had not thought of this at all. Would it make sense to treat 855 the organization and the bins as part of the guidance for creating 856 reports? Maybe not. We should discuss.] 858 4.13. Guidance 860 [jmf- the guidance sections need more detail. . .] 862 [cek - What is missing? We would welcome a critique or text.] 864 Guidance is generally configurable by human administrators. 866 4.13.1. Internal Collection Guidance 868 An internal collector may need guidance to govern what it collects 869 and when. 871 4.13.2. External Collection Guidance 873 An external collector may need guidance to govern what it collects 874 and when. 876 4.13.3. Evaluation Guidance 878 An evaluator typically needs Evaluation Guidance to govern what it 879 considers to be a good or bad security posture. 881 4.13.4. Retention Guidance 883 A SACM deployment may retain posture attributes, events, or 884 evaluation results for some time. Retention supports ad hoc 885 reporting and other use cases. 887 If information is retained, retention guidance controls what is 888 retained and for how long. 890 If two or more pieces of retention guidance apply to a piece of 891 information, the guidance calling for the longest retention should 892 take precedence. 894 Retained information may be stored in a Configuration Management 895 Database (CMDB), for example. 897 4.13.5. Reporting Guidance 899 A Reporting Task typically needs Reporting Guidance to govern the 900 reports it generates. 902 4.14. Provenance of Information 904 Each Posture Attribute, Event, Evaluation Result, and Report needs to 905 be labeled with its provenance (see Section 5.7). 907 5. Graph Model 909 TODO: Write text on how the information model above can be realized 910 in this kind of graph model. 912 The graph model describes how security information is structured, 913 related, and accessed. Control of operations to supply and/or access 914 the data is architecturally distinct from the structuring of the data 915 in the information model. Authorization may be applied by the 916 Control Plane (as defined in the SACM Architecture 917 [I-D.camwinget-sacm-architecture]) to requests for information from a 918 consumer or requests for publication from a provider, and may also be 919 applied by a provider to a direct request from a consumer. 921 This architecture addresses information structure independently of 922 the access/transport of that information. This separation enables 923 scalability, customizability, and extensibility. Access to provide 924 or consume information is particularly suited to publish/subscribe/ 925 query data transport and data access control models. 927 This graph model is a framework that: 929 o Facilitates the definition of extensible data types that support 930 SACM's use cases 932 o Provides a structure for the defined data types to be exchanged 933 via a variety of data transport models 935 o Describes components used in information exchange, and the objects 936 exchanged 938 o Captures and organizes evolving information and information 939 relationships for multiple data publishers 941 o Provides access to the published information via publish, query, 942 and subscribe operations 944 o Leverages the knowledge and experience gained from incorporating 945 TNC IF-MAP into many disparate products that have to integrate and 946 share an information model in a scalable, extensible manner 948 5.1. Background: Graph Models 950 Knowledge is often represented with graph-based formalisms. A common 951 formalism defines a graph as follows: 953 o A set of *vertices* 955 o A set of *edges*, each connecting two vertices (technically, an 956 edge is an ordered pair of vertices) 958 o A set of zero or more *properties* attached to each vertices and 959 edges. Each property consists of a type and a optionally a value. 960 The type and the value are typically just strings 962 +------------------+ +-----------------+ 963 | Id: 1 | parent-of |Id: 2 | 964 | Given name: Sue | --------------> |Given name: Ann | 965 | Family name: Wong| |Family name: Wong| 966 +------------------+ +-----------------+ 968 A VERTEX AN EDGE A VERTEX 970 Figure 2: Knowledge represented by a graph 972 A pair of vertices connected by an edge is commonly referred to as a 973 triple that comprises subject, predicate and object. For example, 974 subject = Sue Wong, predicate = is-parent-of, object = Ann Wong. A 975 common language that uses this representation is the Resource 976 Description Framework (RDF) [W3C.REC-rdf11-concepts-20140225]. 978 5.2. Graph Model Overview 980 The proposed model, influenced by IF-MAP, is a labeled graph: each 981 vertex has a label. 983 A table of synonyms follows. 985 +----------------+-----------------+--------------------------------+ 986 | Graph Theory | Graph Databases | IF-MAP and This Internet Draft | 987 +----------------+-----------------+--------------------------------+ 988 | Vertex or Node | Node | - | 989 | Label | - | Identifier | 990 | Edge | Edge | Link | 991 | - | Property | Metadata Item | 992 +----------------+-----------------+--------------------------------+ 994 In this mode, identifiers and metadata have hierarchical structure. 996 The graphical aspect makes this model well suited to non-hierarchical 997 relationships, such as connectivity in a computer network. 999 Hierarchical properties allow this model to accommodate structures 1000 such as YANG [RFC6020] data models. 1002 5.3. Identifiers 1004 Each identifier is an XML element. For extensibility, schemas use 1005 xsd:anyAttribute and such. 1007 Alternately, this model could be changed to use another hierarchical 1008 notation, such as JSON. 1010 Identifiers are unique: two different vertices cannot have equivalent 1011 identifiers. 1013 An identifier has a type. There is a finite, but extensible, set of 1014 identifier types. If the identifier is XML, the type is based on the 1015 XML schema. 1017 In IF-MAP, standard identifier types include IP address, MAC address, 1018 identity, and overlay network. Additional identifier types will need 1019 to be standardized for SACM use cases. 1021 Any number of metadata items can be attached to an identifier. 1023 Some identifiers, especially those relating to identity, address, and 1024 location, require the ability to specify an administrative domain 1025 (such as AD domain, L2 broadcast domain / L3 routing domain, or 1026 geographic domain) in order to differentiate between instances with 1027 the same name occurring in different realms. 1029 5.4. Links 1031 A link can be thought of as an ordered pair of identifiers. 1033 Any number of metadata items can be attached to a link. 1035 5.5. Metadata 1037 A metadata item is the basic unit of information, and is attached to 1038 an identifier or to a link. 1040 A given metadata item is an XML document. In IF-MAP metadata items 1041 are generally small. However, larger ones, such as YANG data models, 1042 can also fit. For extensibility, the XML schemas of metadata items 1043 use xsd:anyAttribute and such. 1045 Alternately, this model could be changed to use another hierarchical 1046 notation, such as JSON. 1048 A metadata item has a type. There is a finite, but extensible, set 1049 of metadata types. If the metadata item is XML, the type is based on 1050 the XML schema. An example metadata type is 1051 http://www.trustedcomputinggroup.org/2010/IFMAP-METADATA/2#device- 1052 characteristic. 1054 TNC IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA] 1055 and TNC IF-MAP Metadata for ICS Security [TNC-IF-MAP-ICS-METADATA] 1056 define many pertinent metadata types. More will need to be 1057 standardized for SACM use cases. 1059 5.6. Use for SACM 1061 Many of the information elements can be represented as vertices, and 1062 many of the relationships can be represented as edges. 1064 Identifiers are like database keys. For example, there would be 1065 identifiers for addresses, identities, unique endpoint identifiers, 1066 software component identifiers, and hardware component identifiers. 1067 The inventory of software instances and hardware instances within an 1068 endpoint might be expressed using a single YANG description, as a 1069 single metadata item in the graph. Where to put Endpoint Attribute 1070 Assertions, Evaluation Results, and the like is an open question. 1072 5.7. Provenance 1074 Provenance helps to protect the SACM ecosystem against a misled or 1075 malicious provider. 1077 The provenance of a metadata item includes: 1079 o The time when the item was produced 1081 o The component that produced the item, including its software and 1082 version 1084 o The policies that governed the producing component, with versions 1086 o The method used to produce the information (e.g., vulnerability 1087 scan) 1089 How provenance should be expressed is an open question. For 1090 reference, in IF-MAP provenance of a metadata item is expressed 1091 within the metadata item [TNC-IF-MAP-NETSEC-METADATA]. For example, 1092 there is a top-level XML attribute called "timestamp". 1094 It is critical that provenance be secure from tampering. How to 1095 achieve that security is out of scope of this document. 1097 5.8. Extensibility 1099 Anyone can define an identifier type or a metadata type, by creating 1100 an XML schema (or other specification). There is no need for a 1101 central authority. Some deployments may exercise administrative 1102 control over the permitted identifier types and metadata types; 1103 others may leave components free rein. 1105 A community of components can agree on and use new identifier and 1106 metadata types, if the administrators allow it. This allows rapid 1107 innovation. Intermediate software that conveys graph changes from 1108 one component to another does not need changes. Components that do 1109 not understand the new types do not need changes. Accordingly, a 1110 consumer normally ignores metadata types and identifier types it does 1111 not understand. 1113 As a proof point for this agility, the original use cases for TNC IF- 1114 MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] were addressed in TNC 1115 IF-MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA]. 1116 Some years later an additional, major set of use cases, TNC IF-MAP 1117 Metadata for ICS [TNC-IF-MAP-ICS-METADATA], were specified and 1118 implemented. 1120 6. SACM Usage Scenario Example 1122 TODO: this section needs to refer out to wherever the operations / 1123 generalized workflow content ends up 1125 This section illustrates the proposed SACM Information Model as 1126 applied to SACM Usage Scenario 2.2.3, Detection of Posture Deviations 1127 [I-D.ietf-sacm-use-cases]. The following subsections describe the 1128 elements (components and elements), graph model, and operations 1129 (sample workflow) required to support the Detection of Posture 1130 Deviations scenario. 1132 The Detection of Posture Deviations scenario involves multiple 1133 elements interacting to accomplish the goals of the scenario. 1134 Figure 1 illustrates those elements along with their major 1135 communication paths. 1137 6.1. Graph Model for Detection of Posture Deviation 1139 The following subsections contain examples of identifiers and 1140 metadata which would enable detection of posture deviation. These 1141 lists are by no means exhaustive - many other types of metadata would 1142 be enumerated in a data model that fully addressed this usage 1143 scenario. 1145 6.1.1. Components 1147 The proposed SACM Information Model contains three components, as 1148 defined in the SACM Architecture [I-D.camwinget-sacm-architecture]: 1149 Posture Attribute Information Provider, Posture Attribute Information 1150 Consumer, and Control Plane. 1152 In this example, the components are instantiated as follows: 1154 o The Posture Attribute Information Provider is an endpoint security 1155 service which monitors the compliance state of the endpoint and 1156 reports any deviations for the expected posture. 1158 o The Posture Attribute Information Consumer is an analytics engine 1159 which absorbs information from around the network and generates a 1160 "heat map" of which areas in the network are seeing unusually high 1161 rates of posture deviations. 1163 o The Control Plane is a security automation broker which receives 1164 subscription requests from the analytics engine and authorizes 1165 access to appropriate information from the endpoint security 1166 service. 1168 6.1.2. Identifiers 1170 To represent the elements listed above, the set of identifiers might 1171 include (but is not limited to): 1173 o Identity - a device itself, or a user operating a device, 1174 categorized by type of credential (e.g. username or X.509 1175 certificate [RFC5280]) 1177 o Software asset 1179 o Network Session 1181 o Address - categorized by type of address (e.g. MAC address, IP 1182 address, Host Identity Protocol (HIP) Host Identity Tag (HIT) 1183 [RFC5201], etc.) 1185 o Task - categorized by type of task (e.g. internal collector, 1186 external collector, evaluator, or reporting task) 1188 o Result - categorized by type of result (e.g. evaluation result or 1189 report) 1191 o Guidance 1193 6.1.3. Metadata 1195 To characterize the elements listed above, the set of metadata types 1196 might include (but is not limited to): 1198 o Authorization metadata attached to an identity identifier, or to a 1199 link between a network session identifier and an identity 1200 identifier, or to a link between a network session identifier and 1201 an address identifier. 1203 o Location metadata attached to a link between a network session 1204 identifier and an address identifier. 1206 o Event metadata attached to an address identifier or an identity 1207 identifier of an endpoint, which would be made available to 1208 interested parties at the time of publication, but not stored 1209 long-term. For example, when a user disables required security 1210 software, an internal collector associated with an endpoint 1211 security service might publish guidance violation event metadata 1212 attached to the identity identifier of the endpoint, to notify 1213 consumers of the change in endpoint state. 1215 o Posture attribute metadata attached to an identity identifier of 1216 an endpoint. For example, when required security software is not 1217 running, an internal collector associated with an endpoint 1218 security service might publish posture attribute metadata attached 1219 to the identity identifier of the endpoint, to notify consumers of 1220 the current state of the endpoint. 1222 6.1.4. Relationships between Identifiers and Metadata 1224 Interaction between multiple sets of identifiers and metadata lead to 1225 some fairly common patterns, or "constellations", of metadata. For 1226 example, an authenticated-session metadata constellation might 1227 include a central network session with authorizations and location 1228 attached, and links to a user identity, an endpoint identity, a MAC 1229 address, an IP address, and the identity of the policy server that 1230 authorized the session, for the duration of the network session. 1232 These constellations may be independent of each other, or one 1233 constellation may be connected to another. For example, an 1234 authenticated-session metadata constellation may be created when a 1235 user connects an endpoint to the network; separately, an endpoint- 1236 posture metadata constellation may be created when an endpoint 1237 security system and other collectors gather and publish posture 1238 information related to an endpoint. These two constellations are not 1239 necessarily connected to each other, but may be joined if the 1240 component publishing the authenticated-session metadata constellation 1241 is able to link the network session identifier to the identity 1242 identifier of the endpoint. 1244 6.2. Workflow 1246 The workflow for exchange of information supporting detection of 1247 posture deviation, using a standard publish/subscribe/query transport 1248 model such as available with IF-MAP [TNC-IF-MAP-SOAP-Binding] or 1249 XMPP-Grid [I-D.salowey-sacm-xmpp-grid], is as follows: 1251 1. The analytics engine (Posture Assessment Information Consumer) 1252 establishes connectivity and authorization with the transport 1253 fabric, and subscribes to updates on posture deviations. 1255 2. The endpoint security service (Posture Assessment Information 1256 Provider) requests connection to the transport fabric. 1258 3. Transport fabric authenticates and establishes authorized 1259 privileges (e.g. privilege to publish and/or subscribe to 1260 security data) for the requesting components. 1262 4. The endpoint security service evaluates the endpoint, detects 1263 posture deviation, and publishes information on the posture 1264 deviation. 1266 5. The transport fabric notifies the analytics engine, based on its 1267 subscription of the new posture deviation information. 1269 Other components, such as access control policy servers or 1270 remediation systems, may also consume the posture deviation 1271 information provided by the endpoint security service. 1273 7. Acknowledgements 1275 Many of the specifications in this document have been developed in a 1276 public-private partnership with vendors and end-users. The hard work 1277 of the SCAP community is appreciated in advancing these efforts to 1278 their current level of adoption. 1280 Over the course of developing the initial draft, Henk Birkholz, Brant 1281 Cheikes, Matt Hansbury, Daniel Haynes, Scott Pope, Charles Schmidt, 1282 and Steve Venema have contributed text to many sections of this 1283 document. 1285 8. IANA Considerations 1287 This memo includes no request to IANA. 1289 9. Security Considerations 1291 Posture Assessments need to be performed in a safe and secure manner. 1292 In that regard, there are multiple aspects of security that apply to 1293 the communications between components as well as the capabilities 1294 themselves. Due to time constraints, this information model only 1295 contains an initial listing of items that need to be considered with 1296 respect to security. This list is not exhaustive, and will need to 1297 be augmented as the model continues to be developed/refined. 1299 Initial list of security considerations include: 1301 Authentication: Every component and asset needs to be able to 1302 identify itself and verify the identity of other components 1303 and assets. 1305 Confidentiality: Communications between components need to be 1306 protected from eavesdropping or unauthorized collection. 1307 Some communications between components and assets may need to 1308 be protected as well. 1310 Integrity: The information exchanged between components needs to be 1311 protected from modification. some exchanges between assets 1312 and components will also have this requirement. 1314 Restricted Access: Access to the information collected, evaluated, 1315 reported, and stored should only be viewable/consumable to 1316 authenticated and authorized entities. 1318 The TNC IF-MAP Binding for SOAP [TNC-IF-MAP-SOAP-Binding] and TNC IF- 1319 MAP Metadata for Network Security [TNC-IF-MAP-NETSEC-METADATA] 1320 document security considerations for sharing information via security 1321 automation. Most, and possibly all, of these considerations also 1322 apply to information shared via this proposed information model. 1324 10. References 1326 10.1. Normative References 1328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1329 Requirement Levels", BCP 14, RFC 2119, March 1997. 1331 10.2. Informative References 1333 [CCE] The National Institute of Standards and Technology, 1334 "Common Configuration Enumeration", 2014, 1335 . 1337 [CCI] United States Department of Defense Defense Information 1338 Systems Agency, "Control Correlation Identifier", 2014, 1339 . 1341 [CPE-WEBSITE] 1342 The National Institute of Standards and Technology, 1343 "Common Platform Enumeration", 2014, 1344 . 1346 [CVE-WEBSITE] 1347 The MITRE Corporation, "Common Vulnerabilities and 1348 Exposures", 2014, . 1350 [I-D.camwinget-sacm-architecture] 1351 Cam-Winget, N., Ford, B., llorenzin@juniper.net, l., 1352 McDonald, I., and l. loxx@cisco.com, "Secure Automation 1353 and Continuous Monitoring (SACM) Architecture", draft- 1354 camwinget-sacm-architecture-00 (work in progress), June 1355 2014. 1357 [I-D.camwinget-sacm-requirements] 1358 Cam-Winget, N., "Secure Automation and Continuous 1359 Monitoring (SACM) Requirements", draft-camwinget-sacm- 1360 requirements-04 (work in progress), June 2014. 1362 [I-D.ietf-sacm-terminology] 1363 Waltermire, D., Montville, A., Harrington, D., and N. Cam- 1364 Winget, "Terminology for Security Assessment", draft-ietf- 1365 sacm-terminology-05 (work in progress), August 2014. 1367 [I-D.ietf-sacm-use-cases] 1368 Waltermire, D. and D. Harrington, "Endpoint Security 1369 Posture Assessment - Enterprise Use Cases", draft-ietf- 1370 sacm-use-cases-07 (work in progress), April 2014. 1372 [I-D.salowey-sacm-xmpp-grid] 1373 Salowey, J., llorenzin@juniper.net, l., Kahn, C., Pope, 1374 S., Appala, S., Woland, A., and N. Cam-Winget, "XMPP 1375 Protocol Extensions for Use in SACM Information 1376 Transport", draft-salowey-sacm-xmpp-grid-00 (work in 1377 progress), July 2014. 1379 [IM-LIAISON-STATEMENT-NIST] 1380 Montville, A., "Liaison Statement: Call for Contributions 1381 for the SACM Information Model to NIST", May 2014, 1382 . 1384 [ISO.18180] 1385 "Information technology -- Specification for the 1386 Extensible Configuration Checklist Description Format 1387 (XCCDF) Version 1.2", ISO/IEC 18180, 2013, 1388 . 1391 [ISO.19770-2] 1392 "Information technology -- Software asset management -- 1393 Part 2: Software identification tag", ISO/IEC 19770-2, 1394 2009. 1396 [NISTIR-7275] 1397 Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring, 1398 "Specification for the Extensible Configuration Checklist 1399 Description Format (XCCDF) Version 1.2", NISTIR 7275r4, 1400 March 2013, . 1403 [NISTIR-7693] 1404 Wunder, J., Halbardier, A., and D. Waltermire, 1405 "Specification for Asset Identification 1.1", NISTIR 7693, 1406 June 2011, 1407 . 1410 [NISTIR-7694] 1411 Halbardier, A., Waltermire, D., and M. Johnson, 1412 "Specification for the Asset Reporting Format 1.1", NISTIR 1413 7694, June 2011, 1414 . 1417 [NISTIR-7695] 1418 Cheikes, B., Waltermire, D., and K. Scarfone, "Common 1419 Platform Enumeration: Naming Specification Version 2.3", 1420 NISTIR 7695, August 2011, 1421 . 1424 [NISTIR-7696] 1425 Parmelee, M., Booth, H., Waltermire, D., and K. Scarfone, 1426 "Common Platform Enumeration: Name Matching Specification 1427 Version 2.3", NISTIR 7696, August 2011, 1428 . 1431 [NISTIR-7697] 1432 Cichonski, P., Waltermire, D., and K. Scarfone, "Common 1433 Platform Enumeration: Dictionary Specification Version 1434 2.3", NISTIR 7697, August 2011, 1435 . 1438 [NISTIR-7698] 1439 Waltermire, D., Cichonski, P., and K. Scarfone, "Common 1440 Platform Enumeration: Applicability Language Specification 1441 Version 2.3", NISTIR 7698, August 2011, 1442 . 1445 [NISTIR-7848] 1446 Davidson, M., Halbardier, A., and D. Waltermire, 1447 "Specification for the Asset Summary Reporting Format 1448 1.0", NISTIR 7848, May 2012, 1449 . 1452 [OVAL-LANGUAGE] 1453 Baker, J., Hansbury, M., and D. Haynes, "The OVAL Language 1454 Specification version 5.10.1", January 2012, 1455 . 1457 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1458 Architecture for Describing Simple Network Management 1459 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1460 December 2002. 1462 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1463 Simple Network Management Protocol (SNMP)", STD 62, RFC 1464 3416, December 2002. 1466 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1467 Simple Network Management Protocol (SNMP)", STD 62, RFC 1468 3418, December 2002. 1470 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1471 Information Models and Data Models", RFC 3444, January 1472 2003. 1474 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 1475 "IEEE 802.1X Remote Authentication Dial In User Service 1476 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1478 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1479 9", RFC 3954, October 2004. 1481 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1482 Syndication Format", RFC 4287, December 2005. 1484 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1485 4949, August 2007. 1487 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1488 "Host Identity Protocol", RFC 5201, April 2008. 1490 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1491 Tardo, "Network Endpoint Assessment (NEA): Overview and 1492 Requirements", RFC 5209, June 2008. 1494 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1495 Housley, R., and W. Polk, "Internet X.509 Public Key 1496 Infrastructure Certificate and Certificate Revocation List 1497 (CRL) Profile", RFC 5280, May 2008. 1499 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1501 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1502 (PA) Protocol Compatible with Trusted Network Connect 1503 (TNC)", RFC 5792, March 2010. 1505 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1506 A Posture Broker (PB) Protocol Compatible with Trusted 1507 Network Connect (TNC)", RFC 5793, March 2010. 1509 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1510 Network Configuration Protocol (NETCONF)", RFC 6020, 1511 October 2010. 1513 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1514 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1515 6241, June 2011. 1517 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture 1518 Transport Protocol over TLS (PT-TLS)", RFC 6876, February 1519 2013. 1521 [RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 1522 (PT) Protocol for Extensible Authentication Protocol (EAP) 1523 Tunnel Methods", RFC 7171, May 2014. 1525 [SP800-117] 1526 Quinn, S., Scarfone, K., and D. Waltermire, "Guide to 1527 Adopting and Using the Security Content Automation 1528 Protocol (SCAP) Version 1.2", SP 800-117, January 2012, 1529 . 1532 [SP800-126] 1533 Waltermire, D., Quinn, S., Scarfone, K., and A. 1534 Halbardier, "The Technical Specification for the Security 1535 Content Automation Protocol (SCAP): SCAP Version 1.2", SP 1536 800-126, September 2011, 1537 . 1540 [TNC-Architecture] 1541 Trusted Computing Group, ""TNC Architecture", 1542 Specification Version 1.5", May 2012. 1544 [TNC-IF-M-TLV-Binding] 1545 Trusted Computing Group, ""TNC IF-M: TLV Binding", 1546 Specification Version 1.0", May 2014. 1548 [TNC-IF-MAP-ICS-METADATA] 1549 Trusted Computing Group, ""TNC IF-MAP Metadata for ICS 1550 Security", Specification Version 1.0", May 2014. 1552 [TNC-IF-MAP-NETSEC-METADATA] 1553 Trusted Computing Group, ""TNC IF-MAP Metadata for Network 1554 Security", Specification Version 1.1", May 2012. 1556 [TNC-IF-MAP-SOAP-Binding] 1557 Trusted Computing Group, ""TNC IF-MAP Binding for SOAP", 1558 Specification Version 2.2", March 2014. 1560 [TNC-IF-T-TLS] 1561 Trusted Computing Group, ""TNC IF-T: Binding to TLS", 1562 Specification Version 2.0", February 2013. 1564 [TNC-IF-T-Tunneled-EAP] 1565 Trusted Computing Group, ""TNC IF-T: Protocol Bindings for 1566 Tunneled EAP Methods", Specification Version 2.0", May 1567 2014. 1569 [TNC-IF-TNCCS-TLV-Binding] 1570 Trusted Computing Group, ""TNC IF-TNCCS: TLV Binding", 1571 Specification Version 2.0", May 2014. 1573 [UML] Object Management Group, ""Unified Modeling Language TM 1574 (UML (R))", Version 2.4.1", August 2011. 1576 [W3C.REC-rdf11-concepts-20140225] 1577 Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1 1578 Concepts and Abstract Syntax", World Wide Web Consortium 1579 Recommendation REC-rdf11-concepts-20140225, February 2014, 1580 . 1582 [W3C.REC-soap12-part1-20070427] 1583 Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., 1584 Nielsen, H., Karmarkar, A., and Y. Lafon, "SOAP Version 1585 1.2 Part 1: Messaging Framework (Second Edition)", World 1586 Wide Web Consortium Recommendation REC- 1587 soap12-part1-20070427, April 2007, 1588 . 1590 10.3. URIs 1592 [1] https://github.com/OVALProject/Sandbox/blob/master/x-netconf- 1593 definitions-schema.xsd 1595 Appendix A. Security Automation with TNC IF-MAP 1597 A.1. What is Trusted Network Connect? 1599 Trusted Network Connect (TNC) is a vendor-neutral open architecture 1600 [TNC-Architecture] and a set of open standards for network security 1601 developed by the Trusted Computing Group (TCG). TNC standards 1602 integrate security components across end user systems, servers, and 1603 network infrastructure devices into an intelligent, responsive, 1604 coordinated defense. TNC standards have been widely adopted by 1605 vendors and customers; the TNC endpoint assessment protocols [TNC-IF- 1606 M-TLV-Binding][TNC-IF-TNCCS-TLV-Binding][TNC-IF-T-Tunneled-EAP][TNC-I 1607 F-T-TLS] were used as the base for the IETF NEA RFCs 1608 [RFC5792][RFC5793][RFC7171][RFC6876]. 1610 Traditional information security architectures have separate silos 1611 for endpoint security, network security, server security, physical 1612 security, etc. The TNC architecture enables the integration and 1613 categorization of security telemetry sources via the information 1614 model contained in its Interface for Metadata Access Points (IF-MAP) 1615 [TNC-IF-MAP-SOAP-Binding]. IF-MAP provides a query-able repository 1616 of security telemetry that may be used for storage or retrieval of 1617 such data by multiple types of security systems and endpoints on a 1618 vendor-neutral basis. The information model underlying the IF-MAP 1619 repository covers, directly or indirectly, all of the security 1620 information types required to serve SACM use-cases. 1622 A.2. What is TNC IF-MAP? 1624 IF-MAP provides a standard client-server protocol for MAP clients to 1625 exchange security-relevant information via database server known as 1626 the Metadata Access Point or MAP. The data (known as "metadata") 1627 stored in the MAP is XML data. Each piece of metadata is tagged with 1628 a metadata type that indicates the meaning of the metadata and 1629 identifies an XML schema for it. Due to the XML language, the set of 1630 metadata types is easily extensible. 1632 The MAP is a graph database, not a relational database. Metadata can 1633 be associated with an identifier (e.g. the email address 1634 "user@example.com") or with a link between two identifiers (e.g. the 1635 link between MAC address 00:11:22:33:44:55 and IPv4 address 1636 192.0.2.1) where the link defines an association (for example: a 1637 relation or state) between the identifiers. These links between 1638 pairs of identifiers create an ad hoc graph of relationships between 1639 identifiers. The emergent structure of this graph reflects a 1640 continuously evolving knowledge base of security-related metadata 1641 that is shared between various providers and consumers. 1643 A.3. What is the TNC Information Model? 1645 The TNC Information Model underlying IF-MAP relies on the graph 1646 database architecture to enable a (potentially distributed) MAP 1647 service to act as a shared clearinghouse for information that 1648 infrastructure devices can act upon. The IF-MAP operations and 1649 metadata schema specifications (TNC IF-MAP Binding for SOAP 1650 [TNC-IF-MAP-SOAP-Binding], TNC IF-MAP Metadata for Network Security 1651 [TNC-IF-MAP-NETSEC-METADATA], and TNC IF-MAP Metadata for ICS 1652 Security [TNC-IF-MAP-ICS-METADATA]) define an extensible set of 1653 identifiers and data types. 1655 Each IF-MAP client may interact with the IF-MAP graph data store 1656 through three fundamental types of operation requests: 1658 o Publish, which may create, modify, or delete metadata associated 1659 with one or more identifiers and/or links in the graph 1661 o Search, which retrieves a selected sub-graph according to a set of 1662 search criteria 1664 o Subscribe, which allows a client to manage a set of search 1665 commands which asynchronously return selected sub-graphs when 1666 changes to that sub-graph are made by other IF-MAP clients 1668 The reader is invited to review the existing IF-MAP specification 1669 [TNC-IF-MAP-SOAP-Binding] for more details on the above graph data 1670 store operation requests and their associated arguments. 1672 The current IF-MAP specification provides a SOAP 1673 [W3C.REC-soap12-part1-20070427] binding for the above operations, as 1674 well as associated SOAP operations for managing sessions, error 1675 handling, etc. 1677 Appendix B. Text for Possible Inclusion in the Terminology Draft 1679 B.1. Terms and Definitions 1681 This section describes terms that have been defined by other RFCs and 1682 Internet Drafts, as well as new terms introduced in this document. 1684 B.1.1. Pre-defined and Modified Terms 1686 This section contains pre-defined terms that are sourced from other 1687 IETF RFCs and Internet Drafts. Descriptions of terms in this section 1688 will reference the original source of the term and will provide 1689 additional specific context for the use of each term in SACM. For 1690 sake of brevity, terms from [I-D.ietf-sacm-terminology] are not 1691 repeated here unless the original meaning has been changed in this 1692 document. 1694 Asset For this Information Model it is necessary to change the 1695 scope of the definition of asset from the one provided in 1696 [I-D.ietf-sacm-terminology]. Originally defined in [RFC4949] 1697 and referenced in [I-D.ietf-sacm-terminology] as "a system 1698 resource that is (a) required to be protected by an 1699 information system's security policy, (b) intended to be 1700 protected by a countermeasure, or (c) required for a system's 1701 mission." This definition generally relates to an "IT 1702 Asset", which in the context of this document is overly 1703 limiting. For use in this document, a broader definition of 1704 the term is needed to represent non-IT asset types as well. 1706 In [NISTIR-7693] an asset is defined as "anything that has 1707 value to an organization, including, but not limited to, 1708 another organization, person, computing device, information 1709 technology (IT) system, IT network, IT circuit, software 1710 (both an installed instance and a physical instance), virtual 1711 computing platform (common in cloud and virtualized 1712 computing), and related hardware (e.g., locks, cabinets, 1713 keyboards)." This definition aligns better with common 1714 dictionary definitions of the term and better fits the needs 1715 of this document. 1717 B.1.2. New Terms 1719 IT Asset Originally defined in [RFC4949] as "a system resource that 1720 is (a) required to be protected by an information system's 1721 security policy, (b) intended to be protected by a 1722 countermeasure, or (c) required for a system's mission." 1724 Security Content Automation Protocol (SCAP) According to SP800-126, 1725 SCAP, pronounced "ess-cap", is "a suite of specifications 1726 that standardize the format and nomenclature by which 1727 software flaw and security configuration information is 1728 communicated, both to machines and humans." SP800-117 1729 revision 1 [SP800-117] provides a general overview of SCAP 1730 1.2. The 11 specifications that comprise SCAP 1.2 are 1731 synthesized by a master specification, SP800-126 revision 2 1732 [SP800-126], that addresses integration of the specifications 1733 into a coherent whole. The use of "protocol" in its name is 1734 a misnomer, as SCAP defines only data models. SCAP has been 1735 adopted by a number of operating system and security tool 1736 vendors. 1738 Appendix C. Text for Possible Inclusion in the Architecture or Use 1739 Cases 1741 C.1. Introduction 1743 The posture of an endpoint is the status of the endpoint with respect 1744 to the security policies and risk models of the organization. 1746 A system administrator needs to be able to determine which elements 1747 of an endpoint have a security problem and which do not conform the 1748 organization's security policies. The CIO needs to be able to 1749 determine whether endpoints have security postures that conform to 1750 the organization's policies to ensure that the organization is 1751 complying with its fiduciary and regulatory responsibilities. The 1752 regulator or auditor needs to be able to assess the level of due 1753 diligence being achieved by an organization to ensure that all 1754 regulations and due diligence expectations are being met. The 1755 operator needs to understand which assets have deviated from 1756 organizational policies so that those assets can be remedied. 1758 Operators will focus on which endpoints are composed of specific 1759 assets with problems. CIO and auditors need a characterization of 1760 how an organization is performing as a whole to manage the posture of 1761 its endpoints. All of these actors need deployed capabilities that 1762 implement security automation standards in the form of data formats, 1763 interfaces, and protocols to be able to assess, in a timely and 1764 secure fashion, all assets on all endpoints within their enterprise. 1765 This information model provides a basis to identify the desirable 1766 characteristics of data models to support these scenarios. Other 1767 SACM specifications, such as the SACM Architecture, will describe the 1768 potential components of an interoperable system solution based on the 1769 SACM information model to address the requirements for scalability, 1770 timeliness, and security. 1772 C.2. Core Principles 1774 This information model is built on the following core principles: 1776 o Collection and Evaluation are separate tasks. 1778 o Collection and Evaluation can be performed on the endpoint, at a 1779 local server that communicates directly with the endpoint, or 1780 based on data queried from a back end data store that does not 1781 communicate directly with any endpoints. 1783 o Every entity (human or machine) that notifies, queries, or 1784 responds to any guidance, collection, or evaluator must have a way 1785 of identifying itself and/or presenting credentials. 1786 Authentication is a key step in all of the processes, and while 1787 needed to support the business processes, information needs to 1788 support authentication are not highlighted in this information 1789 model. There is already a large amount of existing work that 1790 defines information needs for authentication. 1792 o Policies are reflected in guidance for collection, evaluation, and 1793 reporting. 1795 o Guidance will often be generated by humans or through the use of 1796 transformations on existing automation data. In some cases, 1797 guidance will be generated dynamically based on shared information 1798 or current operational needs. As guidance is created it will be 1799 published to an appropriate guidance data store allowing guidance 1800 to be managed in and retrieved from convenient locations. 1802 o Operators of a continuous monitoring or security automation system 1803 will need to make decisions when defining policies about what 1804 guidance to use or reference. The guidance used may be directly 1805 associated with policy or may be queried dynamically based on 1806 associated metadata. 1808 o Guidance can be gathered from multiple data stores. It may be 1809 retrieved at the point of use or may be packaged and forwarded for 1810 later use. Guidance may be retrieved in event of a collection or 1811 evaluation trigger or it may be gathered ahead of time and stored 1812 locally for use/reference during collection and evaluation 1813 activities. 1815 C.3. Architecture Assumptions 1817 This information model will focus on WHAT information needs to be 1818 exchanged to support the business process areas. The architecture 1819 document is the best place to represent the HOW and the WHERE this 1820 information is used. In an effort to ensure that the data models 1821 derived from this information model scale to the architecture, four 1822 core architectural components need to be defined. They are 1823 producers, consumers, capabilities, and repositories. These elements 1824 are defined as follows: 1826 o Producers (e.g., Evaluation Producer) collect, aggregate, and/or 1827 derive information items and provide them to consumers. For this 1828 model there are Collection, Evaluation, and Results Producers. 1829 There may or may not be Guidance Producers. 1831 o Consumers (e.g., Collection Consumer) request and/or receive 1832 information items from producers for their own use. For this 1833 model there are Collection, Evaluation, and Results Consumers. 1834 There may or may not be Guidance Consumers. 1836 o Capabilities (e.g., Posture Evaluation Capability) take the input 1837 from one or more producers and perform some function on or with 1838 that information. For this model there are Collection Guidance, 1839 Collection, Evaluation Guidance, Evaluation, Reporting Guidance, 1840 and Results Reporting Capabilities. 1842 o Repositories (e.g., Enterprise Repository) store information items 1843 that are input to or output from Capabilities, Producers, and 1844 Consumers. For this model we refer to generic Enterprise and 1845 Guidance Repositories. 1847 Information that needs to be communicated by or made available to any 1848 of these components will be specified in each of the business process 1849 areas. 1851 In the most trivial example, illustrated in Figure 3, Consumers 1852 either request information from, or are notified by, Producers. 1854 +----------+ Request +----------+ 1855 | <-----------------+ | 1856 | Producer | | Consumer | 1857 | +-----------------> | 1858 +----------+ Response +----------+ 1860 +----------+ +----------+ 1861 | | Notify | | 1862 | Producer +-----------------> Consumer | 1863 | | | | 1864 +----------+ +----------+ 1866 Figure 3: Example Producer/Consumer Interactions 1868 As illustrated in Figure 4, writing and querying from data 1869 repositories are a way in which this interaction can occur in an 1870 asynchronous fashion. 1872 +----------+ +----------+ 1873 | | | | 1874 | Producer | | Consumer | 1875 | | | | 1876 +-----+----+ +----^-----+ 1877 | | 1878 Write | +------------+ | Query 1879 | | | | 1880 +-----> Repository +-------+ 1881 | | 1882 +------------+ 1884 Figure 4: Producer/Consumer Repository Interaction 1886 To perform an assessment, these elements are chained together. The 1887 diagram below is illustrative of this and process, and is meant to 1888 demonstrate WHAT basic information exchanges need to occur, while 1889 trying to maintain flexibility in HOW and WHERE they occur. 1891 For example: 1893 o the collection capability can reside on the endpoint or not. 1895 o the collection producer can be part of the collection capability 1896 or not. 1898 o a repository can be directly associated with a producer and/or an 1899 evaluator or stand on its own. 1901 o there can be multiple "levels" of producers and consumers. 1903 +-------------+ 1904 |Evaluation | 1905 +-------------+ |Guidance +--+ 1906 |Endpoint | |Capability | | 1907 +-------+ | +-------------+ | 1908 | | | | 1909 | +-------+-----+ +-----v-------+ 1910 | Collection | |Evaluation | 1911 +-> Capability +--+--------+ |Capability | 1912 | | |Collection | +-----------+ +----------+ 1913 | +------------+Producer | | |---| | 1914 | | | |Collection | |Evaluation| 1915 | | | |Consumer | |Producer | 1916 | +----+------+ +----^------+ +---+------+ 1917 ++---------+ | | | 1918 |Collection| +-----v------+ +---+--------+ | 1919 |Guidance | | | |Collection | | 1920 |Capability| |Collection | |Producer | | 1921 | | |Consumer |-----| | | 1922 +----------+ +------------+ +------------+ | 1923 | Collection | | 1924 | Repository | | 1925 +------------+ | 1926 | 1927 +--------------+ +---------------+ | 1928 |Evaluation | |Evaluation | | 1929 |Results | |Consumer <-----+ 1930 |Producer |-----------| | 1931 +-----+--------+ +---------------+ 1932 | |Results Reporting| 1933 | |Capability | 1934 | +------------^----+ 1935 | | 1936 +-----v--------+ +----+------+ 1937 |Evaluation | |Reporting | 1938 |Results | |Guidance | 1939 |Consumer | |Repository | 1940 +---+----------+ +-----------+ +-------------+ 1941 | | Results | 1942 +-----------------------------> Repository | 1943 | | 1944 +-------------+ 1946 Figure 5: Producer/Consumer Complex Example 1948 This illustrative example in Figure 5 provides a set of information 1949 exchanges that need to occur to perform a posture assessment. The 1950 rest of this information model is using this set of exchanges based 1951 on these core architectural components as the basis for determining 1952 information elements. 1954 Appendix D. Text for Possible Inclusion in the Requirements Draft 1956 D.1. Problem Statement 1958 Scalable and sustainable collection, expression, and evaluation of 1959 endpoint information is foundational to SACM's objectives. To secure 1960 and defend one's network one must reliably determine what devices are 1961 on the network, how those devices are configured from a hardware 1962 perspective, what software products are installed on those devices, 1963 and how those products are configured. We need to be able to 1964 determine, share, and use this information in a secure, timely, 1965 consistent, and automated manner to perform endpoint posture 1966 assessments. 1968 D.2. Problem Scope 1970 The goal of this iteration of the information model is to define the 1971 information needs for an organization to effectively monitor the 1972 endpoints operating on their network, the software installed on those 1973 endpoints, and the configuration of that software. Once we have 1974 those three business processes in place, we can identify vulnerable 1975 endpoints in a very efficient manner. 1977 The four business process areas represent a large set of tasks that 1978 support endpoint posture assessment. In an effort to address the 1979 most basic and foundational needs, we have also narrowed down the 1980 scope inside of each of the business processes to a set of defined 1981 tasks that strive to achieve specific results in the operational 1982 environment and the organization. These tasks are: 1984 1. Define the assets. This is what we want to know about an asset. 1985 For instance, organizations will want to know what software is 1986 installed and its many critical security attributes such as patch 1987 level. 1989 2. Resolve what assets compose an endpoint. This requires 1990 populating the data elements and attributes needed to exchange 1991 information pertaining to the assets composing an endpoint. 1993 3. Express what expected values for the data elements and attributes 1994 need to be evaluated against the actual collected instances of 1995 asset data. This is how an organization can express its policy 1996 for an acceptable data element or attribute value. A system 1997 administrator can also identify specific data elements and 1998 attributes that represent problems, such as vulnerabilities, that 1999 need to be detected on an endpoint. 2001 4. Evaluate the collected instances of the asset data against those 2002 expressed in the policy. 2004 5. Report the results of the evaluation. 2006 Appendix E. Text With No Clear Home Yet 2008 E.1. Operations 2010 Operations that may be carried out the proposed SACM Information 2011 Model are: 2013 o Publish data: Security information is made available in the 2014 information model when a component publishes data to it. 2016 o Subscribe to data: A component seeking to consume an on-going 2017 stream of security information "subscribes" to such data from the 2018 information model. 2020 o Query: This operation enables a component to request a specific 2021 set of security data regarding a specific asset (such as a 2022 specific user endpoint). 2024 The subscribe capability will allow SACM components to monitor for 2025 selected security-related changes in the graph data store without 2026 incurring the performance penalties associated with polling for such 2027 changes. 2029 E.1.1. Generalized Workflow 2031 The proposed SACM Information Model would be most commonly used with 2032 a suitable transport protocol for collecting and distributing 2033 security data across appropriate network platforms and endpoints. 2034 The information model is transport agnostic and can be used with its 2035 native transport provided by IF-MAP or by other data transport 2036 protocols such as the recently proposed XMPP-Grid. 2038 1. A Posture Assessment Information Consumer (Consumer) establishes 2039 connectivity and authorization with the transport fabric. 2041 2. A Posture Assessment Information Provider (Provider) with a 2042 source of security data requests connection to the transport 2043 fabric. 2045 3. Transport fabric authenticates and establishes authorized 2046 privileges (e.g. privilege to publish and/or subscribe to 2047 security data) for the requesting components. 2049 4. Components may either publish security data, subscribe to 2050 security data, query for security data, or any combination of 2051 these operations. 2053 Any component sharing information - either as Provider or Consumer - 2054 may do so on a one-to-one, one-to-many and/or many-to-many meshed 2055 basis. 2057 E.2. From Information Needs to Information Elements 2059 The previous sections highlighted information needs for a set of 2060 management process areas that use posture assessment to achieve 2061 organizational security goals. A single information need may be made 2062 up of multiple information elements. Some information elements may 2063 be required for two different process areas, resulting in two 2064 different requirements. In an effort to support the main idea of 2065 collect once and reuse the data to support multiple processes, we try 2066 to define a singular set of information elements that will support 2067 all the associated information needs. 2069 E.3. Information Model Elements 2071 TODO: Kim to pull up relevant content into section 4 / Elements 2073 Traditionally, one would use the SACM architecture to define 2074 interfaces that required information exchanges. Identified 2075 information elements would then be based on those exchanges. Because 2076 the SACM architecture document is still in the personal draft stage, 2077 this information model uses a different approach to the 2078 identification of information elements. First it lists the four main 2079 endpoint posture assessment activities. Then it identifies 2080 management process areas that use endpoint posture assessment to 2081 achieve organizational security objectives. These process areas were 2082 then broken down into operations that mirrored the typical workflow 2083 from the SACM Use Cases draft [I-D.ietf-sacm-use-cases]. These 2084 operations identify architectural components and their information 2085 needs. In this section, information elements derived from those 2086 information needs are mapped back to the four main activities listed 2087 above. 2089 The original liaison statement [IM-LIAISON-STATEMENT-NIST] requested 2090 contributions for the SACM information model in the four areas 2091 described below. Based on the capabilities defined previously in 2092 this document, the requested areas alone do not provide a sufficient 2093 enough categorization of the necessary information model elements. 2094 The following sub-sections directly address the requested areas as 2095 follows: 2097 1. Endpoint Identification 2099 A. Appendix E.3.1 Asset Identifiers: Describes identification of 2100 many different asset types including endpoints. 2102 2. Endpoint Characterization 2104 A. Appendix E.3.3 Endpoint characterization: This directly maps 2105 to the requested area. 2107 3. Endpoint Attribute Expression/Representation 2109 A. Appendix E.3.4 Posture Attribute Expression: This corresponds 2110 to the first part of "Endpoint Attribute Expression/ 2111 Representation." 2113 B. Appendix E.3.5 Actual Value Representation: This corresponds 2114 to the second part of "Endpoint Attribute Expression/ 2115 Representation." 2117 4. Policy evaluation expression and results reporting 2119 A. Appendix E.3.6 Evaluation Guidance: This corresponds to the 2120 first part of "Policy evaluation expression and results 2121 reporting." 2123 B. Appendix E.3.7 Evaluation Result Reporting: corresponds to 2124 the second part of "Policy evaluation expression and results 2125 reporting." 2127 Additionally, Appendix E.3.2 Other Identifiers: describes other 2128 important identification concepts that were not directly requested by 2129 the liaison statement. 2131 Per the liaison statement, each subsection references related work 2132 that provides a basis for potential data models. Some analysis is 2133 also included for each area of related work on how directly 2134 applicable the work is to the SACM efforts. In general, much of the 2135 related work does not fully address the general or use case-based 2136 requirements for SACM, but they do contain some parts that can be 2137 used as the basis for data models that correspond to the information 2138 model elements. In these cases additional work will be required by 2139 the WG to adapt the specification. In some cases, existing work can 2140 largely be used in an unmodified fashion. This is also indicated in 2141 the analysis. Due to time constraints, the work in this section is 2142 very biased to previous work supported by the authors and does not 2143 reflect a comprehensive listing. An attempt has been made where 2144 possible to reference existing IETF work. Additional research and 2145 discussion is needed to include other related work in standards and 2146 technology communities that could and should be listed here. The 2147 authors intend to continue this work in subsequent revisions of this 2148 draft. 2150 Where possible when selecting and developing data models in support 2151 of these information model elements, extension points and IANA 2152 registries SHOULD be used to provide for extensibility which will 2153 allow for future data models to be addressed. 2155 E.3.1. Asset Identifiers 2157 In this context an "asset" refers to "anything that has value to an 2158 organization" (see [NISTIR-7693]). This use of the term "asset" is 2159 broader than the current definition in [I-D.ietf-sacm-terminology]. 2160 To support SACM use cases, a number of different asset types will 2161 need to addressed. For each type of asset, one or more type of asset 2162 identifier will be needed for use in establishing contextual 2163 relationships within the SACM information model. The following asset 2164 types are referenced or implied by the SACM use cases: 2166 Endpoint: Identifies an individual endpoint for which posture is 2167 collected and evaluated. 2169 Hardware: Identifies a given type of hardware that may be installed 2170 within an endpoint. 2172 Software: Identifies a given type of software that may be installed 2173 within an endpoint. 2175 Network: Identifies a network for which a given endpoint may be 2176 connected or request a connection to. 2178 Organization: Identifies an organizational unit. 2180 Person: Identifies an individual, often within an organizational 2181 context. 2183 E.3.1.1. Related Work 2184 E.3.1.1.1. Asset Identification 2186 The Asset Identification specification [NISTIR-7693] is an XML-based 2187 data model that "provides the necessary constructs to uniquely 2188 identify assets based on known identifiers and/or known information 2189 about the assets." Asset identification plays an important role in 2190 an organization's ability to quickly correlate different sets of 2191 information about assets. The Asset Identification specification 2192 provides the necessary constructs to uniquely identify assets based 2193 on known identifiers and/or known information about the assets. 2194 Asset Identification provides a relatively flat and extensible model 2195 for capturing the identifying information about a one or more assets, 2196 and also provides a way to represent relationships between assets. 2198 The model is organized using an inheritance hierarchy of specialized 2199 asset types/classes (see Figure 6), providing for extension at any 2200 level of abstraction. For a given asset type, a number of properties 2201 are defined that provide for capturing identifying characteristics 2202 and the referencing of namespace qualified asset identifiers, called 2203 "synthetic IDs." 2205 The following figure illustrates the class hierarchy defined by the 2206 Asset Identification specification. 2208 asset 2209 +-it-asset 2210 | +-circuit 2211 | +-computing-device 2212 | +-database 2213 | +-network 2214 | +-service 2215 | +-software 2216 | +-system 2217 | +-website 2218 +-data 2219 +-organization 2220 +-person 2222 Figure 6: Asset Identification Class Hierarchy 2224 This table presents a mapping of notional SACM asset types to those 2225 asset types provided by the Asset Identification specification. 2227 +--------------+------------------+---------------------------------+ 2228 | SACM Asset | Asset | Notes | 2229 | Type | Identification | | 2230 | | Type | | 2231 +--------------+------------------+---------------------------------+ 2232 | Endpoint | computing-device | This is not a direct mapping | 2233 | | | since a computing device is not | 2234 | | | required to have network- | 2235 | | | connectivity. Extension will be | 2236 | | | needed to define a directly | 2237 | | | aligned endpoint asset type. | 2238 +--------------+------------------+---------------------------------+ 2239 | Hardware | Not Applicable | The concept of hardware is not | 2240 | | | addressed by the asset | 2241 | | | identification specification. | 2242 | | | An extension can be created | 2243 | | | based on the it-asset class to | 2244 | | | address this concept. | 2245 +--------------+------------------+---------------------------------+ 2246 | Software | software | Direct mapping. | 2247 +--------------+------------------+---------------------------------+ 2248 | Network | network | Direct mapping. | 2249 +--------------+------------------+---------------------------------+ 2250 | Organization | organization | Direct mapping. | 2251 +--------------+------------------+---------------------------------+ 2252 | Person | person | Direct mapping. | 2253 +--------------+------------------+---------------------------------+ 2255 Table 1: Mapping of SACM to Asset Identification Asset Types 2257 This specification has been adopted by a number of SCAP validated 2258 products. It can be used to address asset identification and 2259 categorization needs within SACM with minor modification. 2261 E.3.1.2. Endpoint Identification 2263 An unique name for an endpoint. This is a foundational piece of 2264 information that will enable collected posture attributes to be 2265 related to the endpoint from which they were collected. It is 2266 important that this name either be created from, provide, or be 2267 associated with operational information (e.g., MAC address, hardware 2268 certificate) that is discoverable from the endpoint or its 2269 communications on the network. It is also important to have a method 2270 of endpoint identification that can persist across network sessions 2271 to allow for correlation of collected data over time. 2273 E.3.1.2.1. Related Work 2275 The previously introduced asset identification specification (see 2276 Appendix E.3.1.1.1 provides a basis for endpoint identification using 2277 the "computing-device" class. While the meaning of this class is 2278 broader than the current definition of an endpoint in the SACM 2279 terminology [I-D.ietf-sacm-terminology], either that class or an 2280 appropriate sub-class extension can be used to capture identification 2281 information for various endpoint types. 2283 E.3.1.3. Software Identification 2285 A unique name for a unit of installable software. Software names 2286 should generally represent a unique release or installable version of 2287 software. Identification approaches should allow for identification 2288 of commercially available, open source, and organizationally 2289 developed custom software. As new software releases are created, a 2290 new software identifier should be created by the releasing party 2291 (e.g., software creator, publisher, licensor). Such an identifier is 2292 useful to: 2294 o Relate metadata that describes the characteristics of the unit of 2295 software, potentially stored in a repository of software 2296 information. Typically, the software identifier would be used as 2297 an index into such a repository. 2299 o Indicate the presence of the software unit on a given endpoint. 2301 o To determine what endpoints are the targets for an assessment 2302 based on what software is installed on that endpoint. 2304 o Define guidance related to a software unit that represents 2305 collection, evaluation, or other automatable policies. 2307 In general, an extensible method of software identification is needed 2308 to provide for adequate coverage and to address legacy identification 2309 approaches. Use of an IANA registry supporting multiple software 2310 identification methods would be an ideal way forward. 2312 E.3.1.3.1. Related Work 2314 While we are not aware of a one-size-fits-all solution for software 2315 identification, there are two existing specifications that should be 2316 considered as part of the solution set. They are described in the 2317 following subsections. 2319 E.3.1.3.1.1. Common Platform Enumeration 2321 E.3.1.3.1.1.1. Background 2323 The Common Platform Enumeration (CPE) [CPE-WEBSITE] is composed of a 2324 family of four specification that are layered to build on lower-level 2325 functionality. The following describes each specification: 2327 1. CPE Naming: A standard machine-readable format [NISTIR-7695] for 2328 encoding names of IT products and platforms. This defines the 2329 notation used to encode the vendor, software name, edition, 2330 version and other related information for each platform or 2331 product. With the 2.3 version of CPE, a second, more advanced 2332 notation was added to the original colon-delimited notation for 2333 CPE naming. 2335 2. CPE Matching: A set of procedures [NISTIR-7696] for comparing 2336 names. This describes how to compare two CPE names to one 2337 another. It describes a logical method that ensures that 2338 automated systems comparing two CPE names would arrive at the 2339 same conclusion. 2341 3. CPE Applicability Language: An XML-based language [NISTIR-7698] 2342 for constructing "applicability statements" that combine CPE 2343 names with simple logical operators. 2345 4. CPE Dictionary: An XML-based catalog format [NISTIR-7697] that 2346 enumerates CPE Names and associated metadata. It details how to 2347 encode the information found in a CPE Dictionary, thereby 2348 allowing multiple organizations to maintain compatible CPE 2349 Dictionaries. 2351 The primary use case of CPE is for exchanging software inventory 2352 data, as it allows the usage of unique names to identify software 2353 platforms and products present on an endpoint. The NIST currently 2354 maintains and updates a dictionary of all agreed upon CPE names, and 2355 is responsible for ongoing maintenance of the standard. Many of the 2356 names in the CPE dictionary have been provided by vendors and other 2357 3rd-parties. 2359 While the effort has seen wide adoption, most notably within the US 2360 Government, a number of critical flaws have been identified. The 2361 most critical issues associated with the effort are: 2363 o Because there is no requirement for vendors to publish their own, 2364 official CPE names, CPE necessarily requires one or more 2365 organizations for curation. This centralized curation requirement 2366 ensures that the effort has difficulty scaling. 2368 o Not enough primary source vendors provide platform and product 2369 naming information. As a result, this pushes too much of the 2370 effort out onto third-party groups and non-authoritative 2371 organizations. This exacerbates the ambiguity in names used for 2372 identical platforms and products and further reduces the utility 2373 of the effort. 2375 E.3.1.3.1.1.2. Applicability to Software Identification 2377 The Common Platform Enumeration (CPE) Naming specification version 2378 2.3 defines a scheme for human-readable standardized identifiers of 2379 hardware and software products. 2381 CPE names are the identifier format for software and hardware 2382 products used in SCAP 1.2 and is currently adopted by a number of 2383 SCAP product vendors. 2385 CPE names can be directly referenced in the asset identification 2386 software class (see Appendix E.3.1.1.1.) 2388 Although relevant, CPE has an unsustainable maintenance "tail" due to 2389 the need for centralized curation and naming-consistency enforcement. 2390 Its mention in this document is to support the historic inclusion of 2391 CPE as part of SCAP and implementation of this specification in a 2392 number of security processes and products. Going forward, software 2393 identification (SWID) tags are recommended as a replacement for CPE. 2394 To this end, work has been started to align both efforts to provide 2395 translation for software units identified using SWID tags to CPE 2396 Names. This translation would allow tools that currently use CPE- 2397 based identifiers to map to SWID identifiers during a transition 2398 period. 2400 E.3.1.3.1.2. Software Identification (SWID) Tags 2402 The software identification tag specification [ISO.19770-2] is an 2403 XML-based data model that is used to describe a unit of installable 2404 software. A SWID tag contains data elements that: 2406 o Identify a specific unit of installable software, 2408 o Enable categorization of the software (e.g., edition, bundle), 2410 o Identification and hashing of software artifacts (e.g., 2411 executables, shared libraries), 2413 o References to related software and dependencies, and 2415 o Inclusion of extensible metadata. 2417 SWID tags can be associated with software installation media, 2418 installed software, software updates (e.g., service packs, patches, 2419 hotfixes), and redistributable components. SWID tags also provide 2420 for a mechanism to relate these concepts to each other. For example, 2421 installed software can be related back to the original installation 2422 media, patches can be related to the software that they patch, and 2423 software dependencies can be described for required redistributable 2424 components. SWID tags are ideally created at build-time by the 2425 software creator, publisher or licensor; are bundled with software 2426 installers; and are deployed to an endpoint during software 2427 installation. 2429 SWID tags should be considered for two primary uses: 2431 1. As the data format for exchanging descriptive information about 2432 software products, and 2434 2. As the source of unique identifiers for installed software. 2436 In addition to usage for software identification, a SWID tag can 2437 provide the necessary data needed to target guidance based on 2438 included metadata, and to support verification of installed software 2439 and software media using cryptographic hashes. This added 2440 information increases the value of using SWID tags as part of the 2441 larger security automation and continuous monitoring solution space. 2443 E.3.1.4. Hardware Identification 2445 Due to the time constraints, research into information elements and 2446 related work for identifying hardware is not included in this 2447 revision of the information model. 2449 E.3.2. Other Identifiers 2451 In addition to identifying core asset types, it is also necessary to 2452 have stable, globally unique identifiers to represent other core 2453 concepts pertaining to posture attribute collection and evaluation. 2454 The concept of "global uniqueness" ensures that identifiers provided 2455 by multiple organization do not collide. This may be handled by a 2456 number of different mechanisms (e.g., use of namespaces). 2458 E.3.2.1. Platform Configuration Item Identifier 2460 A name for a low-level, platform-dependent configuration mechanism as 2461 determined by the authoritative primary source vendor. New 2462 identifiers will be created when the source vendor makes changes to 2463 the underlying platform capabilities (e.g., adding new settings, 2464 replacing old settings with new settings). When created each 2465 identifier should remain consistent with regards to what it 2466 represents. Generally, a change in meaning would constitute the 2467 creation of a new identifier. 2469 For example, if the configuration item is for "automatic execution of 2470 code", then the platform vendor would name the low-level mechanism 2471 for their platform (e.g., autorun for mounted media). 2473 E.3.2.1.1. Related Work 2475 E.3.2.1.1.1. Common Configuration Enumeration 2477 The Common Configuration Enumeration (CCE) [CCE] is an effort managed 2478 by NIST. CCE provides a unique identifier for platform-specific 2479 configuration items that facilitates fast and accurate correlation of 2480 configuration items across multiple information sources and tools. 2481 CCE does this by providing an identifier, a human readable 2482 description of the configuration control, parameters needed to 2483 implement the configuration control, various technical mechanisms 2484 that can be used to implement the configuration control, and 2485 references to documentation that describe the configuration control 2486 in more detail. 2488 By vendor request, NIST issues new blocks of CCE identifiers. 2489 Vendors then populate the required fields and provided the details 2490 back to NIST for publication in the "CCE List", a consolidated 2491 listing of assigned CCE identifiers and associated data. Many 2492 vendors also include references to these identifiers in web pages, 2493 SCAP content, and prose configuration guides they produce. 2495 CCE the identifier format for platform specific configuration items 2496 in SCAP and is currently adopted by a number of SCAP product vendors. 2498 While CCE is largely supported as a crowd-sourced effort, it does 2499 rely on a central point of coordination for assignment of new CCE 2500 identifiers. This approach to assignment requires a single 2501 organization, currently NIST, to manage allocations of CCE 2502 identifiers which doesn't scale well and introduces sustainability 2503 challenges for large volumes of identifier assignment. If this 2504 approach is used going forward by SACM, a namespaced approach is 2505 recommended for identifier assignment that allows vendors to manage 2506 their own namespace of CCE identifiers. This change would require 2507 additional work to specify and implement. 2509 E.3.2.1.1.2. Open Vulnerability and Assessment Language 2511 E.3.2.1.1.2.1. Background 2513 The Open Vulnerability and Assessment Language (OVAL(R)) is an XML 2514 schema-based data model developed as part of a public-private 2515 information security community effort to standardize how to assess 2516 and report upon the security posture of endpoints. OVAL provides an 2517 established framework for making assertions about an endpoint's 2518 posture by standardizing the three main steps of the assessment 2519 process: 2521 1. representing the current endpoint posture; 2523 2. analyzing the endpoint for the presence of the specified posture; 2524 and 2526 3. representing the results of the assessment. 2528 OVAL facilitates collaboration and information sharing among the 2529 information security community and interoperability among tools. 2530 OVAL is used internationally and has been implemented by a number of 2531 operating system and security tools vendors. 2533 The following figure illustrates the OVAL data model. 2535 +------------+ 2536 +-----------------+ | Variables | 2537 | Common <---+ | 2538 +--------> | +------------+ 2539 | | | +------------+ 2540 | | <---+ Directives | 2541 | +--------^----^---+ | | 2542 | | | +--------+---+ 2543 | | +-----+ | 2544 | | | | 2545 | +--------+--------+ | | 2546 | | System | | | 2547 | | Characteristics | | | 2548 +------+------+ | | | +--------v---+ 2549 | Definitions | | | | | Results | 2550 | | +--------^--------+ +-+ | 2551 | | | | | 2552 | | +------------+ | 2553 +------^------+ +-------+----+ 2554 | | 2555 +--------------------------------------+ 2557 Note: The direction of the arrows indicate a model dependency 2559 Figure 7: The OVAL Data Model 2561 The OVAL data model [OVAL-LANGUAGE], visualized in Figure 7, is 2562 composed of a number of different components. The components are: 2564 o Common: Constructs, enumerations, and identifier formats that are 2565 used throughout the other model components. 2567 o Definitions: Constructs that describe assertions about system 2568 state. This component also includes constructs for internal 2569 variable creation and manipulation through a variety of functions. 2570 The core elements are: 2572 * Definition: A collection of logical statements that are 2573 combined to form an assertion based on endpoint state. 2575 * Test(platform specific): A generalized construct that is 2576 extended in platform schema to describe the evaluation of 2577 expected against actual state. 2579 * Object(platform specific): A generalized construct that is 2580 extended in platform schema to describe a collectable aspect of 2581 endpoint posture. 2583 * State(platform specific): A generalized construct that is 2584 extended in platform schema to describe a set of criteria for 2585 evaluating posture attributes. 2587 o Variables: Constructs that allow for the parameterization of the 2588 elements used in the Definitions component based on externally 2589 provided values. 2591 o System Characteristics: Constructs that represent collected 2592 posture from one or more endpoints. This element may be embedded 2593 with the Results component, or may be exchanged separately to 2594 allow for separate collection and evaluation. The core elements 2595 of this component are: 2597 * CollectedObject: Provides a mapping of collected Items to 2598 elements defined in the Definitions component. 2600 * Item(platform specific): A generalized construct that is 2601 extended in platform schema to describe specific posture 2602 attributes pertaining to an aspect of endpoint state. 2604 o Results: Constructs that represent the result of evaluating 2605 expected state (state elements) against actual state (item 2606 elements). It includes the true/false evaluation result for each 2607 evaluated Definition and Test. Systems characteristics are 2608 embedded as well to provide low-level posture details. 2610 o Directives: Constructs that enable result reporting detail to be 2611 declared, allowing for result production to customized. 2613 End-user organizations and vendors create assessment guidance using 2614 OVAL by creating XML instances based on the XML schema implementation 2615 of the OVAL Definitions model. The OVAL Definitions model defines a 2616 structured identifier format for each of the Definition, Test, 2617 Object, State, and Item elements. Each instantiation of these 2618 elements in OVAL XML instances are assigned a unique identifier based 2619 on the specific elements identifier syntax. These XML instances are 2620 used by tools that support OVAL to drive collection and evaluation of 2621 endpoint posture. When posture collection is performed, an OVAL 2622 Systems Characteristics XML instance is generated based on the 2623 collected posture attributes. When this collected posture is 2624 evaluated, an OVAL Result XML instance is generated that contains the 2625 results of the evaluation. In most implementations, the collection 2626 and evaluation is performed at the same time. 2628 Many of the elements in the OVAL model (i.e., Test, Object, State, 2629 Item) are abstract, requiring a platform-specific schema 2630 implementation, called a "Component Model" in OVAL. These platform 2631 schema implementations are where platform specific posture attributes 2632 are defined. For each aspect of platform posture a specialized OVAL 2633 Object, which appears in the OVAL Definitions model, provides a 2634 format for expressing what posture attribute data to collect from an 2635 endpoint through the specification of a datatype, operation, and 2636 value(s) on entities that uniquely identify a platform configuration 2637 item. For example, a hive, key, and name is used to identify a 2638 registry key on a Windows endpoint. Each specialized OVAL Object has 2639 a corresponding specialized State, which represents the posture 2640 attributes that can be evaluated, and an Item which represents the 2641 specific posture attributes that can be collected. Additionally, a 2642 specialized Test exists that allows collected Items corresponding to 2643 a CollectedObject to be evaluated against one or more specialized 2644 States of the same posture type. 2646 The OVAL language provides a generalized approach suitable for 2647 posture collection and evaluation. While this approach does provide 2648 for a degree of extensibility, there are some concerns that should be 2649 addressed in order to make OVAL a viable basis for SACM's use. These 2650 concerns include: 2652 o Platform Schema Creation and Maintenance: In OVAL platform schema, 2653 the OVAL data model maintains a tight binding between the Test, 2654 Object, State, and Item elements used to assess an aspect of 2655 endpoint posture. Creating a new platform schema or adding a new 2656 posture aspect to an existing platform schema can be a very labor 2657 intensive process. Doing so often involves researching and 2658 understanding system APIs and can be prone to issues with 2659 inconsistency within and between platforms. To simplify platform 2660 schema creation and maintenance, the model needs to be evolved to 2661 generalize the Test, Object, and State elements, requiring only 2662 the definition of an Item representation. 2664 o Given an XML instance based on the Definitions model, it is not 2665 clear in the specification how incremental collection and 2666 evaluation can occur. Because of this, typically, OVAL 2667 assessments are performed on a periodic basis. The OVAL 2668 specification needs to be enhanced to include specifications for 2669 performing event-based and incremental assessment in addition to 2670 full periodic collection. 2672 o Defining new functions for manipulating variable values is current 2673 handled in the Definitions schema. This requires revision to the 2674 core language to add new functions. The OVAL specification needs 2675 to be evolved to provide for greater extensibility in this area, 2676 allowing extension schema to define new functions. 2678 o The current process for releasing a new version of OVAL, bundle 2679 releases of the core language with release of community recognized 2680 platform schema. The revision processes for the core and platform 2681 schema need to be decoupled. Each platform schema should use some 2682 mechanism to declare which core language version it relies on. 2684 If adopted by SCAM, these issues will need to be addressed as part of 2685 the SCAM engineering work to make OVAL more broadly adoptable as a 2686 general purpose data model for posture collection and evaluation. 2688 E.3.2.1.1.2.2. Applicability to Platform Configuration Item 2689 Identification 2691 Each OVAL Object is identified by a globally unique identifier. This 2692 globally unique identifier could be used by the SACM community to 2693 identify platform-specific configuration items and at the same time 2694 serve as collection guidance. If used in this manner, OVAL Objects 2695 would likely need to undergo changes in order to decouple it from 2696 evaluation guidance and to provide more robust collection 2697 capabilities to support the needs of the SACM community. 2699 E.3.2.2. Configuration Item Identifier 2701 An identifier for a high-level, platform-independent configuration 2702 control. This identification concept is necessary to allow similar 2703 configuration item concepts to be comparable across platforms. For 2704 example, a configuration item might be created for the minimum 2705 password length configuration control, which may then have a number 2706 of different platform-specific configuration settings. Without this 2707 type of identification, it will be difficult to perform evaluation of 2708 expected versus actual state in a platform-neutral way. 2710 High-level configuration items tend to change much less frequently 2711 than the platform-specific configuration items (see Appendix E.3.2.1) 2712 that might be associated with them. To provide for the greatest 2713 amount of sustainability, collections of configuration item 2714 identifiers are best defined by specific communities of interest, 2715 while platform-specific identifiers are best defined by the source 2716 vendor of the platform. Under this model, the primary source vendors 2717 would map their platform-specific configuration controls to the 2718 appropriate platform-independent item allowing end-user organizations 2719 to make use of these relationships. 2721 To support different communities of interest, it may be necessary to 2722 support multiple methods for identification of configuration items 2723 and for associating related metadata. Use of an IANA registry 2724 supporting multiple configuration item identification methods would 2725 be an ideal way forward. To the extent possible, a few number of 2726 configuration item identification approaches is desirable, to 2727 maximize the update by vendors who would be maintain mapping of 2728 platform-specific configuration identifiers to the more general 2729 platform-neutral configuration identifiers. 2731 E.3.2.2.1. Related Work 2733 E.3.2.2.1.1. Control Correlation Identifier 2735 The Control Correlation Identifier (CCI) [CCI] is developed and 2736 managed by the United States Department of Defense (US-DoD) Defense 2737 Information Systems Agency (DISA). According to their website, CCI 2738 "provides a standard identifier and description for each of the 2739 singular, actionable statements that comprise an information 2740 assurance (IA) control or IA best practice. CCI bridges the gap 2741 between high-level policy expressions and low-level technical 2742 implementations. CCI allows a security requirement that is expressed 2743 in a high-level policy framework to be decomposed and explicitly 2744 associated with the low-level security setting(s) that must be 2745 assessed to determine compliance with the objectives of that specific 2746 security control. This ability to trace security requirements from 2747 their origin (e.g., regulations, IA frameworks) to their low-level 2748 implementation allows organizations to readily demonstrate compliance 2749 to multiple IA compliance frameworks. CCI also provides a means to 2750 objectively roll-up and compare related compliance assessment results 2751 across disparate technologies." 2753 It is recommended that this approach be analysed as a potential 2754 candidate for use as a configuration item identifier method. 2756 Note: This reference to CCI is for informational purposes. Since the 2757 editors do not represent DISA's interests, its inclusion in this 2758 document does not indicate the presence or lack of desire to 2759 contribute aspects of this effort to SACM. 2761 E.3.2.2.1.2. A Potential Alternate Approach 2763 There will likely be a desire by different communities to create 2764 different collections of configuration item identifiers. This 2765 fracturing may be caused by: 2767 o Different requirements for levels of abstraction, 2769 o Varying needs for timely maintenance of the collection, and 2770 o Differing scopes of technological needs. 2772 Due to these and other potential needs, it will be difficult to 2773 standardize around a single collection of configuration identifiers. 2774 A workable solution will be one that is scalable and usable for a 2775 broad population of end-user organizations. An alternate approach 2776 that should be considered is the definition of data model that 2777 contains a common set of metadata attributes, perhaps supported by an 2778 extensible taxonomy, that can be assigned to platform-specific 2779 configuration items. If defined at a necessary level of granularity, 2780 it may be possible to query collections of platform-specific 2781 configuration items provided by vendors to create groupings at 2782 various levels of abstractions. By utilizing data provided by 2783 vendors, technological needs and the timeliness of information can be 2784 addressed based on customer requirements. 2786 SACM should consider this and other approaches to satisfy the need 2787 for configuration item roll-up in a way that provides the broadest 2788 benefit, while achieving a sensible degree of scalability and 2789 sustainability. 2791 E.3.2.3. Vulnerability Identifier 2793 An unique name for a known software flaw that exists in specific 2794 versions of one or more units of software. One use of a 2795 vulnerability identifier in the SACM context is to associate a given 2796 flaw with the vulnerable software using software identifiers. For 2797 this reason at minimum, software identifiers should identify a 2798 software product to the patch or version level, and not just to the 2799 level that the product is licensed. 2801 E.3.2.3.1. Related Work 2803 E.3.2.3.1.1. Common Vulnerabilities and Exposures 2805 Common Vulnerabilities and Exposures (CVE) [CVE-WEBSITE] is a MITRE 2806 led effort to assign common identifiers to publicly known security 2807 vulnerabilities in software to facilitate the sharing of information 2808 related to the vulnerabilities. CVE is the industry standard by 2809 which software vendors, tools, and security professionals identify 2810 vulnerabilities and could be used to address SACM's need for a 2811 vulnerability identifier. 2813 E.3.3. Endpoint characterization 2815 Target when policies (collection, evaluated, guidance) apply 2817 Collection can be used to further characterize 2818 Also human input 2820 Information required to characterize an endpoint is used to determine 2821 what endpoints are the target of a posture assessment. It is also 2822 used to determine the collection, evaluation, and/or reporting 2823 policies and the associated guidance that apply to the assessment. 2824 Endpoint characterization information may be populated by: 2826 o A manual input process and entered into records associated with 2827 the endpoint, or 2829 o Using information collected and evaluated by an assessment. 2831 Regardless of the method of collection, it will be necessary to query 2832 and exchange endpoint characterization information as part of the 2833 assessment planning workflow. 2835 E.3.3.1. Related Work 2837 E.3.3.1.1. Extensible Configuration Checklist Description Format 2839 E.3.3.1.1.1. Background 2841 The Extensible Configuration Checklist Description Format (XCCDF) is 2842 a specification that provides an XML-based format for expressing 2843 security checklists. The XCCDF 1.2 specification is published by 2844 International Organization for Standardization (ISO) [ISO.18180]. 2845 XCCDF contains multiple components and capabilities, and various 2846 components align with different elements of this information model. 2848 This specification was originally published by NIST [NISTIR-7275]. 2849 When contributed to ISO Joint Technical Committee 1 (JTC 1), a 2850 comment was introduced indicating an interest in the IETF becoming 2851 the maintenance organization for this standard. If the SACM working 2852 group is interested in taking on engineering work pertaining to 2853 XCCDF, a contribution through a national body can be made to create a 2854 ballot resolution for transition of this standard to the IETF for 2855 maintenance. 2857 E.3.3.1.1.2. Applicability to Endpoint characterization 2859 The target component of XCCDF provides a mechanism for capturing 2860 characteristics about an endpoint including the fully qualified 2861 domain name, network address, references to external identification 2862 information (e.g. Asset Identification), and is extensible to 2863 support other useful information (e.g. MAC address, globally unique 2864 identifier, certificate, etc.). XCCDF may serve as a good starting 2865 point for understanding the types of information that should be used 2866 to identify an endpoint. 2868 E.3.3.1.2. Asset Reporting Format 2870 E.3.3.1.2.1. Background 2872 The Asset Reporting Format (ARF) [NISTIR-7694] is a data model to 2873 express information about assets, and the relationships between 2874 assets and reports. It facilitates the reporting, correlating, and 2875 fusing of asset information within and between organizations. ARF is 2876 vendor and technology neutral, flexible, and suited for a wide 2877 variety of reporting applications. 2879 There are four major sub-components of ARF: 2881 o Asset: The asset component element includes asset identification 2882 information for one or more assets. It simply houses assets 2883 independent of their relationships to reports. The relationship 2884 section can then link the report section to specific assets. 2886 o Report: The report component element contains one or more asset 2887 reports. An asset report is composed of content (or a link to 2888 content) about one or more assets. 2890 o Report-Request: The report-request component element contains the 2891 asset report requests, which can give context to asset reports 2892 captured in the report section. The report-request section simply 2893 houses asset report requests independent of the report which was 2894 subsequently generated. 2896 o Relationship: The relationship component element links assets, 2897 reports, and report requests together with well-defined 2898 relationships. Each relationship is defined as {subject} 2899 {predicate} {object}, where {subject} is the asset, report 2900 request, or report of interest, {predicate} is the relationship 2901 type being established, and {object} is one or more assets, report 2902 requests, or reports. 2904 E.3.3.1.2.2. Relationship to Endpoint Characterization 2906 For Endpoint Characterization, ARF can be used in multiple ways due 2907 to its flexibility. ARF supports the use of the Asset Identification 2908 specification (more in Appendix E.3.3.1.2.3) to embed the 2909 representation of one or more assets as well as relationships between 2910 those assets. It also allows the inclusion of report-requests, which 2911 can provide details on what data was required for an assessment. 2913 ARF is agnostic to the data formats of the collected posture 2914 attributes and therefore can be used within the SACM Architecture to 2915 provide Endpoint Characterization without dictating data formats for 2916 the encoding of posture attributes. The embedded Asset 2917 Identification data model (see Appendix E.3.1.1.1) can be used to 2918 characterize one or more endpoints to allow targeting for collection, 2919 evaluation, etc. Additionally, the report-request model can dictate 2920 the type of reporting that has been requested, thereby providing 2921 context as to which endpoints the guidance applies. 2923 E.3.3.1.2.3. Asset Identification 2925 Described earlier 2927 In the context of Endpoint Characterization, the Asset Identification 2928 data model could be used to encode information that identifies 2929 specific endpoints and/or classes of endpoints to which a particular 2930 assessment is relevant. The flexibility in the Asset Identification 2931 specification allows usage of various endpoint identifiers as defined 2932 by the SACM engineering work. 2934 As stated in Appendix E.3.3.1.2.3, the Asset Identification 2935 specification is included within the Asset Reporting Framework (ARF) 2936 and therefore can be used in concert with that specification as well. 2938 E.3.3.1.3. The CPE Applicability Language 2940 CPE described earlier 2942 Applicability in CPE is defined as an XML language [NISTIR-7698] for 2943 using CPE names to create applicability statements using logical 2944 expressions. These expressions can be used to applicability 2945 statements that can drive decisions about assets, whether or not to 2946 do things like collect data, report data, and execute policy 2947 compliance checks. 2949 It is recommended that SACM evolve the CPE Applicability Language 2950 through engineering work to allow it to better fit into the security 2951 automation vision laid out by the Use Cases and Architecture for 2952 SACM. This should include de-coupling the identification part of the 2953 language from the logical expressions, making it such that the 2954 language is agnostic to the method by which assets are identified. 2955 This will allow use of SWID, CPE Names, or other identifiers to be 2956 used, perhaps supported by an IANA registry of identifier types. 2958 The other key aspect that should be evolved is the ability to make 2959 use of the Applicability Language against a centralized repository of 2960 collected posture attributes. The language should be able to make 2961 applicability statements against previously collected posture 2962 attributes, such that an enterprise can quickly query the correct set 2963 of applicable endpoints in an automated and scalable manner. 2965 E.3.4. Posture Attribute Expression 2967 Discuss the catalog concept. Listing of things that can be chosen 2968 from. Things we can know about. Vendors define catalogs. Ways for 2969 users to get vendor-provided catalogs. 2971 To support the collection of posture attributes, there needs to be a 2972 way for operators to identify and select from a set of platform- 2973 specific attribute(s) to collect. The same identified attributes 2974 will also need to be identified post-collection to associate the 2975 actual value of that attribute pertaining to an endpoint as it was 2976 configured at the time of the collection. To provide for 2977 extensibility, the need exists to support a variety of possible 2978 identification approaches. It is also necessary to enable vendors of 2979 software to provide a listing, or catalog, of the available posture 2980 attributes to operators that can be collected. Ideally, a federated 2981 approach will be used to allow organizations to identify the location 2982 for a repository containing catalogs of posture attributes provided 2983 by authoritative primary source vendors. By querying these 2984 repositories, operators will be able to acquire the appropriate 2985 listings of available posture attributes for their deployed assets. 2986 One or more posture attribute expressions are needed to support these 2987 exchanges. 2989 E.3.4.1. Related Work 2991 The ATOM Syndication Format [RFC4287] provides an extensible, 2992 flexible XML-based expression for organizing a collection of data 2993 feeds consisting of entries. This standard can be used to express 2994 one or more catalogs of posture attributes represented as data feeds. 2995 Groupings of posture attributes would be represented as entries. 2996 These entries could be defined using the data models described in the 2997 "Related Work" sections below. Additionally, this approach can also 2998 be used more generally for guidance repositories allowing other forms 2999 of security automation guidance to be exchanged using the same 3000 format. 3002 E.3.4.2. Platform Configuration Attributes 3004 A low-level, platform-dependent posture attribute as determined by 3005 the authoritative primary source vendor. Collection guidance will be 3006 derived from catalogs of platform specific posture attributes. 3008 For example, a primary source vendor would create a platform-specific 3009 posture attribute that best models the posture attribute data for 3010 their platform. 3012 E.3.4.2.1. Related Work 3014 E.3.4.2.1.1. Open Vulnerability and Assessment Language 3016 A general overview of OVAL was provided previously in 3017 Appendix E.3.2.1.1.2.1. The OVAL System Characteristics platform 3018 extension models provide a catalog of the posture attributes that can 3019 be collected from an endpoint. In OVAL these posture attributes are 3020 further grouped into logical constructs called OVAL Items. For 3021 example, the passwordpolicy_item that is part of the Windows platform 3022 extension groups together all the posture attributes related to 3023 passwords for an endpoint running Windows (e.g. maximum password age, 3024 minimum password length, password complexity, etc.). The various 3025 OVAL Items defined in the OVAL System Characteristics may serve as a 3026 good starting for the types of posture attribute data that needs to 3027 be collected from endpoints. 3029 OVAL platform extension models may be shared using the ATOM 3030 Syndication Format. 3032 E.3.4.2.1.2. Network Configuration Protocol and YANG Data Modeling 3033 Language 3035 The Network Configuration Protocol (NETCONF) [RFC6241] defines a 3036 mechanism for managing and retrieving posture attribute data from 3037 network infrastructure endpoints. The posture attribute data that 3038 can be collected from a network infrastructure endpoint is highly 3039 extensible and can defined using the YANG modeling language 3040 [RFC6020]. Models exist for common datatypes, interfaces, and 3041 routing subsystem information among other subjects. The YANG 3042 modeling language may be useful in providing an extensible framework 3043 for the SACM community to define one or more catalogs of posture 3044 attribute data that can be collected from network infrastructure 3045 endpoints. 3047 Custom YANG modules may also be shared using the ATOM Syndication 3048 Format. 3050 E.3.4.2.1.3. Simple Network Management Protocol and Management 3051 Information Base Entry 3053 The Simple Network Protocol (SNMP) [RFC3411] defines a protocol for 3054 managing and retrieving posture attribute data from endpoints on a 3055 network . The posture attribute data that can be collected of an 3056 endpoint and retrieved by SNMP is defined by the Management 3057 Information Base (MIB) [RFC3418] which is hierarchical collection of 3058 information that is referenced using Object Identifiers . Given this, 3059 MIBs may provide an extensible way for the SACM community to define a 3060 catalog of posture attribute data that can be collected off of 3061 endpoints using SNMP. 3063 MIBs may be shared using the ATOM Syndication Format. 3065 E.3.5. Actual Value Representation 3067 Discuss instance concept. 3069 The actual value of a posture attribute is collected or published 3070 from an endpoint. The identifiers discussed previously provide names 3071 for the posture attributes (i.e., software or configuration item) 3072 that can be the subject of an assessment. The information items 3073 listed below are the actual values collected during the assessment 3074 and are all associated with a specific endpoint. 3076 E.3.5.1. Software Inventory 3078 A software inventory is a list of software identifiers (or content) 3079 associated with a specific endpoint. Software inventories are 3080 maintained in some organized fashion so that entities can interact 3081 with it. Just having software publish identifiers onto an endpoint 3082 is not enough, there needs to be an organized listing of all those 3083 identifiers associated with that endpoint. 3085 E.3.5.1.1. Related Work 3087 E.3.5.1.1.1. Asset Summary Reporting 3089 The Asset Summary Reporting (ASR) specification [NISTIR-7848] 3090 provides a format for capturing summary information about one or more 3091 assets. Specifically, it provides the ability to express a 3092 collection of records from some defined data source and map them to 3093 some set of assets. As a result, this specification may be useful 3094 for capturing the software installed on an endpoint, its relevant 3095 attributes, and associating it with a particular endpoint. 3097 E.3.5.1.1.2. Software Identification Tags 3099 SWID tag were previously introduced in Appendix E.3.1.3.1.2. As 3100 stated before, SWID tags are ideally deployed to an endpoint during 3101 software installation. In the less ideal case, they may also be 3102 generated based on information retrieved from a proprietary software 3103 installation data store. At minimum, SWID tag must contain an 3104 identifier for each unit of installed software. Given this, SWID 3105 tags may be a viable way for SACM to express detailed information 3106 about the software installed on an endpoint. 3108 E.3.5.2. Collected Platform Configuration Posture Attributes 3110 Configurations associated with a software instance associated with an 3111 endpoint 3113 A list of the configuration posture attributes associated with the 3114 actual values collected from the endpoint during the assessment as 3115 required/expressed by any related guidance. Additionally, each 3116 configuration posture attribute is associated with the installed 3117 software instance it pertains to. 3119 E.3.5.2.1. Related Work 3121 E.3.5.2.1.1. Open Vulnerability and Assessment Language 3123 A general overview of OVAL was provided previously in 3124 Appendix E.3.2.1.1.2.1. As mentioned earlier, the OVAL System 3125 Characteristics platform extensions provide a catalog of the posture 3126 attributes that can be collected and assessed in the form of OVAL 3127 Items. These OVAL Items also serve as a model for representing 3128 posture attribute data and associated values that are collected off 3129 an endpoint. Furthermore, the OVAL System Characteristics model 3130 provides a system_info construct that captures information that 3131 identifies and characterizes the endpoint from which the posture 3132 attribute data was collected. Specifically, it includes operating 3133 system name, operating system version, endpoint architecture, 3134 hostname, network interfaces, and an extensible construct to support 3135 arbitrary additional information that may be useful in identifying 3136 the endpoint in an enterprise such as information capture in Asset 3137 Identification constructs. The OVAL System Characteristics model 3138 could serve as a useful starting point for representing posture 3139 attribute data collected from an endpoint although it may need to 3140 undergo some changes to satisfy the needs of the SACM community. 3142 E.3.5.2.1.2. NETCONF-Based Collection 3144 Introduced earlier in Appendix E.3.4.2.1.2, NETCONF defines a 3145 protocol for managing and retrieving posture attribute data from 3146 network infrastructure endpoints. NETCONF provides the 3147 and operations to retrieve the configuration data, and 3148 configuration data and state data respectively from a network 3149 infrastructure endpoint. Upon successful completion of these 3150 operations, the current posture attribute data of the network 3151 infrastructure endpoint will be made available. NETCONF also 3152 provides a variety of filtering mechanisms (XPath, subtree, content 3153 matching, etc.) to trim down the posture attribute data that is 3154 collected from the endpoint. Given that NETCONF is widely adopted by 3155 network infrastructure vendors, it may useful to consider this 3156 protocol as a standardized mechanism for collecting posture attribute 3157 data from network infrastructure endpoints. 3159 As a side note, members of the OVAL Community have also developed a 3160 proposal to extend the OVAL Language to support the assessment of 3161 NETCONF configuration data [1]. The proposal leverages XPath to 3162 extract the posture attribute data of interest from the XML data 3163 returned by NETCONF. The collected posture attribute data can then 3164 be evaluated using OVAL Definitions and the results of the evaluation 3165 can be expressed as OVAL Results. While this proposal is not 3166 currently part of the OVAL Language, it may be worth considering. 3168 E.3.5.2.1.3. SNMP-Based Collection 3170 The SNMP, previously introduced in Appendix E.3.4.2.1.3, defines a 3171 protocol for managing and retrieving posture attribute data from 3172 endpoints on a network [RFC3411]. SNMP provides three protocol 3173 operations [RFC3416] (GetRequest, GetNextRequest, and GetBulkRequest) 3174 for retrieving posture attribute data defined by MIB objects. Upon 3175 successful completion of these operations, the requested posture 3176 attribute data of the endpoint will be made available to the 3177 requesting application. Given that SNMP is widely adopted by 3178 vendors, and the MIBs that define posture attribute data on an 3179 endpoint are highly extensible, it may useful to consider this 3180 protocol as a standardized mechanism for collecting posture attribute 3181 data from endpoints in an enterprise. 3183 E.3.6. Evaluation Guidance 3185 E.3.6.1. Configuration Evaluation Guidance 3187 The evaluation guidance is applied by evaluators during posture 3188 assessment of an endpoint. This guidance must be able to reference 3189 or be associated with the following previously defined information 3190 elements: 3192 o configuration item identifiers, 3194 o platform configuration identifiers, and 3196 o collected Platform Configuration Posture Attributes. 3198 E.3.6.1.1. Related Work 3200 E.3.6.1.1.1. Open Vulnerability and Assessment Language 3202 A general overview of OVAL was provided previously in 3203 Appendix E.3.2.1.1.2.1. The OVAL Definitions model provides an 3204 extensible framework for making assertions about the state of posture 3205 attribute data collected from an endpoint. Guidance written against 3206 this model consists of one or more OVAL Tests, that can be logically 3207 combined, where each OVAL Test defines what posture attributes should 3208 be collected from an endpoint (as OVAL Objects) and optionally 3209 defines the expected state of the posture attributes (as OVAL 3210 States). While the OVAL Definitions model may be a useful starting 3211 point for evaluation guidance, it will likely require some changes to 3212 decouple collection and evaluation concepts to satisfy the needs of 3213 the SACM community. 3215 E.3.6.1.1.2. XCCDF Rule 3217 A general description of XCCDF was provided in Appendix E.3.3.1.1.1. 3218 As noted there, an XCCDF document represents a checklist of items 3219 against which a given endpoint's state is compared and evaluated. An 3220 XCCDF Rule represents one assessed item in this checklist. A Rule 3221 contains both a prose description of the assessed item (either for 3222 presentation to the user in a tool's user interface, or for rendering 3223 into a prose checklist for human consumption) and can also contain 3224 instructions to support automated evaluation of the assessed item, if 3225 such automated assessment is possible. Automated assessment 3226 instructions can be provided either within the XCCDF Rule itself, or 3227 by providing a reference to instructions expressed in other 3228 languages, such as OVAL. 3230 In order to support greater flexibility in XCCDF, checklists can be 3231 tailored to meet certain needs. One way to do this is to enable or 3232 disable certain rules that are appropriate or inappropriate to a 3233 given endpoint, respectively. For example, a single XCCDF checklist 3234 might contain check items to evaluate the configuration of an 3235 endpoint's operating system. An endpoint deployed in an enterprise's 3236 DMZ might need to be locked down more than a common internal 3237 endpoint, due to the greater exposure to attack. In this case, some 3238 operating system configuration requirements for the DMZ endpoint 3239 might be unnecessary for the internal endpoint. Nonetheless, most 3240 configuration requirements would probably remain applicable to both 3241 environments (providing a common baseline for configuration of the 3242 given operating system) and thus be common to the checking 3243 instructions for both types of endpoints. XCCDF supports this by 3244 allowing a single checklist to be defined, but then tailored to the 3245 needs of the assessed endpoint. In the previous example, some Rules 3246 that apply only to the DMZ endpoint would be disabled during the 3247 assessment of an internal endpoint and would not be exercised during 3248 the assessment or count towards the assessment results. To 3249 accomplish this, XCCDF uses the CPE Applicability Language. By 3250 enhancing this applicability language to support other aspects of 3251 endpoint characterization (see Appendix E.3.3.1.3), XCCDF will also 3252 benefit from these enhancements. 3254 In addition, XCCDF Rules also support parameterization, allowing 3255 customization of the expected value for a given check item. For 3256 example, the DMZ endpoint might require a password of at least 12 3257 characters, while an internal endpoint may only need 8 or more 3258 characters in its password. By employing parameterization of the 3259 XCCDF Rule, the same Rule can be used when assessing either type of 3260 endpoint, and simply be provided with a different target parameter 3261 each time to reflect the different role-based requirements. Sets of 3262 customizations can be stored within the XCCDF document itself: XCCDF 3263 Values store parameters values that can be used in tailoring, while 3264 XCCDF Profiles store sets of tailoring instructions, including 3265 selection of certain Values as parameters and the enabling and 3266 disabling of certain Rules. The tailoring capabilities supported by 3267 XCCDF allow a single XCCDF document to encapsulate configuration 3268 evaluation guidance that applies to a broad range of endpoint roles. 3270 E.3.7. Evaluation Result Reporting 3272 E.3.7.1. Configuration Evaluation Results 3274 The evaluation guidance applied during posture assessment of an 3275 endpoint to customize the behavior of evaluators. Guidance can be 3276 used to define specific result output formats or to select the level- 3277 of-detail for the generated results. This guidance must be able to 3278 reference or be associated with the following previously defined 3279 information elements: 3281 o configuration item identifiers, 3283 o platform configuration identifiers, and 3285 o collected Platform Configuration Posture Attributes. 3287 E.3.7.1.1. Related Work 3289 E.3.7.1.1.1. XCCDF TestResults 3291 A general description of the eXtensible Configuration Checklist 3292 Description Format (XCCDF) was provided in section 3293 Appendix E.3.3.1.1.1. The XCCDF TestResult structure captures the 3294 outcome of assessing a single endpoint against the assessed items 3295 (i.e., XCCDF Rules) contained in an XCCDF instance document. XCCDF 3296 TestResults capture a number of important pieces of information about 3297 the assessment including: 3299 o The identity of the assessed endpoint. See Appendix E.3.3.1.1.2 3300 for more about XCCDF structures used for endpoint identification. 3302 o Any tailoring of the checklist that might have been employed. See 3303 Appendix E.3.6.1.1.2 for more on how XCCDF supports tailoring. 3305 o The individual results of the assessment of each enabled XCCDF 3306 Rule in the checklist. See Appendix E.3.6.1.1.2 for more on XCCDF 3307 Rules. 3309 The individual results for a given XCCDF Rule capture only whether 3310 the rule "passed", "failed", or experienced some exceptional 3311 condition, such as if an error was encountered during assessment. 3312 XCCDF 1.2 Rule results do not capture the actual state of the 3313 endpoint. For example, an XCCDF Rule result might indicate that an 3314 endpoint failed to pass requirement that passwords be of a length 3315 greater than or equal to 8, but it would not capture that the 3316 endpoint was, in fact, only requiring passwords of 4 or more 3317 characters. It may, however, be possible for a user to discover this 3318 information via other means. For example, if the XCCDF Rule uses an 3319 OVAL Definition to effect the Rule's evaluation, then the actual 3320 endpoint state may be captured in the corresponding OVAL System 3321 Characteristics file. 3323 The XCCDF TestResult structure does provide a useful structure for 3324 understanding the overall assessment that was conducted and the 3325 results thereof. The ability to quickly determine the Rules that are 3326 not complied with on a given endpoint allow administrators to quickly 3327 identify where remediation needs to occur. 3329 E.3.7.1.1.2. Open Vulnerability and Assessment Language 3331 A general overview of OVAL was provided previously in 3332 Appendix E.3.2.1.1.2.1. OVAL Results provides a model for expressing 3333 the results of the assessment of the actual state of the posture 3334 attribute values collected of an endpoint (represented as an OVAL 3335 System Characteristics document) against the expected posture 3336 attribute values (defined in an OVAL Definitions document. Using 3337 OVAL Directives, the granularity of OVAL Results can also be 3338 specified. The OVAL Results model may be useful in providing a 3339 format for capturing the results of an assessment. 3341 E.3.7.1.1.3. Asset Summary Reporting 3343 A general overview of ASR was provided previously in 3344 Appendix E.3.5.1.1.1. As ASR provides a way to report summary 3345 information about assets, it can be used within the SACM Architecture 3346 to provide a way to aggregate asset information for later use. It 3347 makes no assertions about the data formats used by the assessment, 3348 but rather provides an XML, record-based way to collect aggregated 3349 information about assets. 3351 By using ASR to collect this summary information within the SACM 3352 Architecture, one can provide a way to encode the details used by 3353 various reporting requirements, including user-definable reports. 3355 E.3.7.1.1.4. ARF 3357 A general overview of ARF was provided previously in 3358 Appendix E.3.3.1.2.1. Because ARF is data model agnostic, it can 3359 provide a flexible format for exchanging collection and evaluation 3360 information from endpoints. It additionally provides a way to encode 3361 relationships between guidance and assets, and as such, can be used 3362 to associate assessment results with guidance. This could be the 3363 guidance that directly triggered the assessment, or for guidance that 3364 is run against collected posture attributes located in a central 3365 repository. 3367 E.3.7.2. Software Inventory Evaluation Results 3369 The results of an evaluation of an endpoint's software inventory 3370 against an authorized software list. The authorized software list 3371 represents the policy for what software units are allowed, 3372 prohibited, and mandatory for an endpoint. 3374 Authors' Addresses 3376 David Waltermire (editor) 3377 National Institute of Standards and Technology 3378 100 Bureau Drive 3379 Gaithersburg, Maryland 20877 3380 USA 3382 Email: david.waltermire@nist.gov 3383 Kim Watson 3384 United States Department of Homeland Security 3385 DHS/CS&C/FNR 3386 245 Murray Ln. SW, Bldg 410 3387 MS0613 3388 Washington, DC 20528 3389 USA 3391 Email: kimberly.watson@hq.dhs.gov 3393 Clifford Kahn 3394 Juniper Networks, Inc. 3395 10 Technology Park Drive 3396 Westford, MA 01886 3397 USA 3399 Email: cliffordk@juniper.net 3401 Lisa Lorenzin 3402 Juniper Networks, Inc. 3403 3614 Laurel Creek Way 3404 Durham, NC 27712 3405 USA 3407 Email: llorenzin@juniper.net