idnits 2.17.1 draft-ietf-sacm-use-cases-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2013) is 3880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0826' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'RFC2922' is defined on line 1130, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Automation and Continuous Monitoring WG D. Waltermire 3 Internet-Draft NIST 4 Intended status: Informational D. Harrington 5 Expires: March 16, 2014 Effective Software 6 September 12, 2013 8 Using Security Posture Assessment to Grant Access to Enterprise Network 9 Resources 10 draft-ietf-sacm-use-cases-01 12 Abstract 14 This memo documents a sampling of use cases for securely aggregating 15 configuration and operational data and assessing that data to 16 determine an organization's security posture. From these operational 17 use cases, we can derive common functional capabilities and 18 requirements to guide development of vendor-neutral, interoperable 19 standards for aggregating and assessing data relevant to security 20 posture. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 16, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 4 59 3.1. Definition and Publication of Automatable Configuration 60 Guides . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Automated Checklist Verification . . . . . . . . . . . . 6 62 3.3. Organizational Software Policy Compliance . . . . . . . . 7 63 3.4. Detection of Posture Deviations . . . . . . . . . . . . . 7 64 3.5. Others... . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Functional Capabilities . . . . . . . . . . . . . . . . . . . 7 66 4.1. Asset Identification . . . . . . . . . . . . . . . . . . 8 67 4.1.1. Asset Class Identification . . . . . . . . . . . . . 8 68 4.1.2. Asset Instance Identification . . . . . . . . . . . . 9 69 4.2. Asset Characterization . . . . . . . . . . . . . . . . . 10 70 4.3. Deconfliction of Asset Identities . . . . . . . . . . . . 13 71 4.4. Asset Targeting . . . . . . . . . . . . . . . . . . . . . 13 72 4.5. Other Unedited Content . . . . . . . . . . . . . . . . . 15 73 4.5.1. Endpoint Configuration Management . . . . . . . . . . 15 74 4.5.1.1. Organizing Configuration Metadata . . . . . . . . 15 75 4.5.1.2. Publishing Recommended Configuration Posture . . 16 76 4.5.1.3. Defining Organizationally Expected Configuration 77 Posture . . . . . . . . . . . . . . . . . . . . . 16 78 4.5.1.4. Collecting Endpoint Configuration Posture . . . . 16 79 4.5.1.5. Comparing Expected and Actual Configuration 80 Posture . . . . . . . . . . . . . . . . . . . . . 16 81 4.5.1.6. Examining configuration of logical to physical 82 mappings . . . . . . . . . . . . . . . . . . . . 17 83 4.5.1.7. Configuring Endpoint Interfaces . . . . . . . . . 17 84 4.5.2. Endpoint Posture Change Management . . . . . . . . . 17 85 4.5.2.1. Defining and Exchanging Baselines . . . . . . . . 17 86 4.5.2.2. Detecting Unauthorized Changes . . . . . . . . . 17 87 4.5.3. Security Vulnerability Management . . . . . . . . . . 18 88 4.5.3.1. Example - NIDS response . . . . . . . . . . . . . 18 89 4.5.3.2. Example - Historical vulnerability analysis . . . 19 90 4.5.3.3. Source Address Validation . . . . . . . . . . . . 19 91 4.5.4. Data Collection . . . . . . . . . . . . . . . . . . . 19 92 4.5.5. Assessment Result Analysis . . . . . . . . . . . . . 20 93 4.5.6. Content Management . . . . . . . . . . . . . . . . . 20 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 8.1. -00- to -01- . . . . . . . . . . . . . . . . . . . . . . 21 99 8.2. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 100 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 22 101 8.3. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 23 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 104 9.2. Informative References . . . . . . . . . . . . . . . . . 24 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 107 1. Introduction 109 Our goal with this document is to improve our agreement on which 110 problems we're trying to solve. We need to start with short, simple 111 problem statements and discuss those by email and in person. Once we 112 agree on which problems we're trying to solve, we can move on to 113 propose various solutions and decide which ones to use. 115 This document describes example use cases for endpoint posture 116 assessment for enterprises. It provides a sampling of use cases for 117 securely aggregating configuration and operational data and assessing 118 that data to determine the security posture of individual endpoints, 119 and, in the aggregate, the security posture of an enterprise. 121 These use cases cross many IT security information domains. From 122 these operational use cases, we can derive common concepts, common 123 information expressions, functional capabilities and requirements to 124 guide development of vendor-neutral, interoperable standards for 125 aggregating and assessing data relevant to security posture. 127 Using this standard data, tools can analyze the state of endpoints, 128 user activities and behaviour, and assess the security posture of an 129 organization. Common expression of information should enable 130 interoperability between tools (whether customized, commercial, or 131 freely available), and the ability to automate portions of security 132 processes to gain efficiency, react to new threats in a timely 133 manner, and free up security personnel to work on more advanced 134 problems. 136 The goal is to enable organizations to make informed decisions that 137 support organizational objectives, to enforce policies for hardening 138 systems, to prevent network misuse, to quantify business risk, and to 139 collaborate with partners to identify and mitigate threats. 141 It is expected that use cases for enterprises and for service 142 providers will largely overlap, but there are additional 143 complications for service providers, especially in handling 144 information that crosses administrative domains. 146 The output of endpoint posture assessment is expected to feed into 147 additional processes, such as policy-based enforcement of acceptable 148 state, verification and monitoring of security controls, and 149 compliance to regulatory requirements. 151 2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 3. Endpoint Posture Assessment 159 Endpoint posture assessment involves orchestrating and performing 160 data collection and analysis pertaining to the posture of a given 161 endpoint. Typically, endpoint posture information is gathered and 162 then published to appropriate data repositories to make collected 163 information available for further analysis supporting organizational 164 security processes. 166 Endpoint posture assessment typically includes: 168 o Collecting the posture of a given endpoint; 170 o Making that posture available to the enterprise for further 171 analysis and action; and 173 o Performing analysis to assess that the endpoint's posture is in 174 compliance with enterprise standards and policy. 176 As part of these activities it is often necessary to identify and 177 acquire any supporting content that is needed to drive data 178 collection and analysis. 180 The following is a typical success scenario for endpoint posture 181 assessment: 183 1. Define a target endpoint to be assessed 185 2. Select acceptable state policies to apply to the defined target 187 3. Identify the endpoint being assessed 189 4. Collect posture attributes from the target 191 5. Communicate target identity and collected posture to external 192 system for evaluation 194 6. Compare collected posture attributes from the target endpoint 195 with expected state values as expressed in acceptable state 196 policies 198 The following subsections detail specific use cases for data 199 collection, analysis, and related operations pertaining to the 200 publication and use of supporting content. 202 3.1. Definition and Publication of Automatable Configuration Guides 204 QUESTION: This use case applies equally to vendors representing other 205 endpoint types. Should this be generalized to capture this notion? 207 A network device vendor manufactures a number of enterprise grade 208 routers and other network devices. The also develop and maintain an 209 operating system for these devices that enables end-user 210 organizations to configure a number of security and operational 211 settings for these devices. As part of their customer support 212 activities, they publish a number of secure configuration guides that 213 provide minimum security guidelines for configuring their devices. 215 Each guide they produce applies to a specific model of device and 216 version of the operating system and provides a number of specialized 217 configurations depending on the devices intended function and what 218 add-on hardware modules and software licenses are installed on the 219 device. To enable their customers to assess the security posture of 220 their devices to ensure that all appropriate minimal security 221 settings are enabled, they publish an automatable configuration 222 checklist using a popular data format that defines what settings to 223 check using a network management protocol and appropriate values for 224 each setting. They publish these guides to a public content 225 repository that customers can query to retrieve applicable guides for 226 their deployed enterprise network infrastructure endpoints. 228 To support this use case, the following capabilities will be 229 utilized: 231 o Asset Identification (see section 4.1) - Hardware and software 232 class-level asset identities will be used to identify the 233 applicable targets for each configuration guide and within the 234 guide specialized targets for licensed features and hardware 235 modules. 237 o Asset Characterization - Asset characteristics will be used to 238 identify the target endpoint functions addressed by each 239 configuration guide. 241 o Asset Targeting - Applicability expressions will be described 242 using asset identification and characterization attributes to 243 scope the checklist and specific groupings of configurations to 244 associated hardware and software products, features, and asset 245 functions. 247 o [TODO: Need to list other functions here as the sections 248 stabilize.] 250 QUESTION: Is providing traceability to functional capabilities 251 useful? If so, we need to replicate this for the other use cases. 253 3.2. Automated Checklist Verification 255 A financial services company operates a heterogeneous IT environment. 256 In support of their risk management program, they utilize vendor 257 provided automatable security configuration checklists for each 258 operating system and application used within their IT environment. 259 Multiple checklists are used from different vendors to insure 260 adequate coverage of all IT assets. 262 To identify what checklists are needed, they use automation to gather 263 an inventory of the software versions utilized by all IT assets in 264 the enterprise. This data gathering will involve querying existing 265 data stores of previously collected endpoint software inventory 266 posture data and actively collecting data from reachable endpoints as 267 needed utilizing network and systems management protocols. 268 Previously collected data may be provided by periodic data 269 collection, network connection-driven data collection, or ongoing 270 event-driven monitoring of endpoint posture changes. 272 Using the gathered software inventory data and associated asset 273 management data indicating the organizational defined functions of 274 each endpoint, they locate and query each vendors content repository 275 for the appropriate checklists. These checklists are cached locally 276 to reduce the need to download the checklist multiple times. 278 Driven by the setting data provided in the checklist, a combination 279 of existing configuration data stores and data collection methods are 280 used to gather the appropriate posture information from each 281 endpoint. Specific data is gathered based on the defined enterprise 282 function and software inventory of each endpoint. The data 283 collection paths used to collect software inventory posture will be 284 used again for this purpose. Once the data is gathered, the actual 285 state is evaluated against the expected state criteria in each 286 applicable checklist. Deficiencies are identified and reported to 287 the appropriate endpoint operators for remedy. 289 3.3. Organizational Software Policy Compliance 291 Example Corporation, in support of compliance requirements, has 292 identified a number of secure baselines for different endpoint types 293 that exist across their enterprise IT environment. Determining which 294 baseline applies to a given endpoint is based on the organizationally 295 defined function of the device. 297 Each baseline, defined using an automatable standardized data format, 298 identifies the expected hardware, software and patch inventory, and 299 software configuration item values for each endpoint type. As part 300 of their compliance activities, they require that all endpoints 301 connecting to their network meet the appropriate baselines. Each 302 endpoint is checked to make sure it complies with the appropriate 303 baseline whenever it connects to the network and at least once a day 304 thereafter. These daily compliance checks assess the posture of each 305 endpoint and report on its compliance with the appropriate baseline. 307 [TODO: Need to speak to how the baselines are identified for a given 308 endpoint connecting to the network.] 310 3.4. Detection of Posture Deviations 312 Example corporation has established secure configuration baselines 313 for each different type of endpoint within their enterprise 314 including: network infrastructure, mobile, client, and server 315 computing platforms. These baselines define an approved list of 316 hardware, software (i.e., operating system, applications, and 317 patches), and associated required configurations. When an endpoint 318 connects to the network, the appropriate baseline configuration is 319 communicated to the endpoint based on its location in the network, 320 the expected function of the device, and other asset management data. 321 It is checked for compliance with the baseline indicating any 322 deviations to the device's operators. Once the baseline has been 323 established, the endpoint is monitored for any change events 324 pertaining to the baseline on an ongoing basis. When a change occurs 325 to posture defined in the baseline, updated posture information is 326 exchanged allowing operators to be notified and/or automated action 327 to be taken. 329 3.5. Others... 331 Additional use cases will be identified as we work through other 332 domains. 334 4. Functional Capabilities 335 The use cases defined in the previous section highlight various uses 336 of endpoint posture assessment to support a variety of IT security 337 business processes. The following subsections address derived 338 functional capabilities that are needed to support these use cases. 340 4.1. Asset Identification 342 Organizations manage a variety of assets within their enterprise 343 including: endpoints, the hardware they are composed of, installed 344 software, hardware/software licenses used, and configurations. 345 Identifying assets is critical for managing information provided 346 about and collected from endpoints. In order to manage these assets 347 over time it is necessary to uniquely identify them and to use this 348 identification to express asset properties and to establish 349 relationships between different assets. 351 When possible, stable identification mechanisms should be used that 352 will allow the asset to be identified over time enabling information 353 pertaining to the asset to be correlated. In some cases stable asset 354 identifiers may not be available or they may change over time due to 355 operational conditions. For example, identifiers may be stable for 356 the life of a hardware component. In other cases (e.g., MAC 357 addresses), the identifier may be mutable within software. In an 358 enterprise context it is often necessary to use multiple 359 identification viewpoints for an asset to correlate data generated 360 from endpoint, network, and human sources. To deal with these 361 scenarios, it is important to use multiple forms of asset 362 identification concurrently to allow asset data to be deconflicted 363 (see section Section 4.3. 365 REQUIREMENT: Many standard and proprietary forms of asset 366 identification exist today. To provide adequate coverage, use of any 367 identification mechanism, both standardized and proprietary, SHOULD 368 be allowed. 370 Object-oriented programming introduces two different concepts when 371 dealing with data: classes and instances. A class represents a data 372 type which can be varied in a number of ways, while an instance 373 represents a realized variation of a class. This distinction can be 374 applied to identifying assets as described in the following 375 subsections. 377 4.1.1. Asset Class Identification 378 An asset class identifies a distinct type of asset. Assets 379 identified at the class level are useful for describing things that 380 can be instantiated or duplicated. Having the ability to associate 381 data with asset classes enable common properties and relationships to 382 be expressed that apply to all copies. 384 Examples of class-level asset identities include: 386 o Software releases and patches - Identifiers that represent 387 distinct software revision releases for firmware, operating 388 systems, applications, software suites, and patches and other 389 forms of software updates. 391 o Hardware components - Identifiers that distinguish specific parts 392 and production runs for hardware devices and components. 394 o Organizational endpoint types - Identifiers that represent 395 distinct endpoint configurations associated with a specific 396 organizational IT function. 398 o Others? - Please suggest any additional examples on the list 400 By identifying different types of assets at the class-level, common 401 characteristics (see section 4.2) and content (see section 4.4) can 402 be associated. Using class identification it is possible to define 403 relationships between assets and other data including: software 404 dependencies, associated patches, supported hardware architectures, 405 associated vulnerabilities, and related configuration items. 407 In many object-oriented languages classes can exist in hierarchies. 408 This enables association of data at different levels of abstraction. 409 This is also a useful concept for asset identification. For example, 410 a class may exist for router endpoint types, with subclasses 411 representing different vendor product releases. This enables 412 characteristics and content to be associated at various levels of 413 abstraction reducing data management challenges. 415 A variety of asset identification schemes exist for asset classes, 416 including some that can be exposed within an operating environment 417 for data collection. These may include: part numbers and revisions 418 for hardware and software product identifiers. [TODO: We need 419 examples of existing standardized asset class identification schemes? 421 REQUIREMENT: When available these asset identifiers SHOULD be used to 422 identify asset classes in collected and analyzed data. 424 4.1.2. Asset Instance Identification 425 An asset instance identifies a specific copy or variation of an asset 426 identification class. Identification of asset instances is necessary 427 for expressing specific properties and relationships within an 428 installed context. For example a network interface card installed in 429 a specific router in branch office's network closet, or a word 430 processing application release installed on Bob's desktop. 432 Identification of asset instances can be supported using a variety of 433 identification schemes. Hardware vendors often expose asset instance 434 identification data to the operating system including: product tags, 435 CPU identifiers, etc. In some cases, such as for software, it may be 436 necessary to express instance information as a relation to the 437 installed device. For example, using a software class identifier 438 with a hardware identifier to establish the software instance on a 439 specific endpoint. Organizationally provided identifiers can also be 440 used to identify assets such as those provided by hardware and 441 software certificates, and other configurable identification sources. 443 Accessing specific identifiers on an endpoint may require privileges 444 on the device. When identifying an endpoint from a network context, 445 or if other forms of device identification are not available or 446 access is not authorized, it may be necessary to identify an endpoint 447 using network addressing information (e.g., MAC addresses, IP 448 addresses). If only network data is used, additional analysis will 449 be needed to correlate an endpoint's identity across multiple 450 connection sessions often resulting in partial confidence of the 451 assets identity over time. 453 Some existing standards support the identification of the hardware 454 and the system software on a given endpoint. For example, the 455 SYSTEM-MIB [RFC1213] contains a description of the endpoint, an 456 authoritative identifier of the type of endpoint assigned by the 457 vendor of the endpoint, an administrative name for the endpoint, plus 458 the endpoint's contact person, the location of the endpoint, system 459 time, and an enumerator that identifies the layer of services 460 provided by the endpoint. The system description includes the 461 vendor, product type, model number, OS version, and networking 462 software version. 464 Similar information is available via the YANG module ietf-system . 465 This module includes data node definitions for system identification, 466 time-of-day management, user management, DNS resolver configuration, 467 and some protocol operations for system management. 469 4.2. Asset Characterization 471 TERM: Asset characterization is the process of defining attributes 472 that describe properties of an identified asset. 474 Asset characterization provides additional context that is useful to 475 support automated and human decision making as part of operational 476 and security processes. It is necessary to gather, organize, store, 477 manage, and exchange a variety of different asset characteristics. 478 Often this information helps to bridge automated and human-oriented 479 processes. To assess assets (managed and unmanaged), we need to 480 understand the composition and relationships between different assets 481 types. We need the ability to properly characterize assets at the 482 outset and over time. 484 Managing endpoints, and the different types of assets that compose 485 them, involves initially identifying and characterizing each asset. 486 This information is important to provide additional context for 487 supporting management of assets using human and automated processes. 488 Characterization may include business context not otherwise related 489 to security, but which may be used as information in support of 490 security decision making. For example, it may be possible to 491 automate assessing that an endpoint is out of compliance with 492 organizational configuration guidelines, but additional information 493 is needed to determine who to notify to correct the configuration. 494 Information provided by asset characterization will enable 495 notifications to be sent, trouble tickets to be generated, or 496 specific reports to be generated at a dashboard for a systems 497 administrator. 499 The following are examples of useful asset characteristics that may 500 be provided: 502 For asset classes: 504 o Information pertaining to the developer, manufacturer, and/or 505 publisher of hardware and software 507 o The composition, dependencies, and function of hardware and 508 software 510 o Production version 512 o Hardware characteristics and software operational requirements 513 (e.g., processor architecture, memory, storage, network 514 interfaces) 516 o Metadata identifying: product family, edition, licensing 518 o End-of-support dates 520 For asset instances: 522 o The business and operational context (e.g., required function/ 523 role, owning organization, responsible parties) 525 o The composition and relationship of its constituent and containing 526 assets (e.g., installed hardware and software versions 528 o Assigned location for physical devices 530 o The current location within network(s) 532 o Current/historic operational state (e.g., running software, 533 processes, user sessions) 535 It can be important to characterize the components of an endpoint, 536 including physical and logical components, and the relationships 537 between the components, such as containment of components within 538 other components, or mappings between logical entities and the 539 physical entities used to instantiate them. The information about 540 the physical entities might include manufacturer-assigned serial 541 number, manufacture date, an asset identifier for the component, and 542 so. Logical entities may be defined, and associated with the 543 physical entities using a mapping table. 545 Assets may be characterized based on data collected directly from 546 endpoints (see section 4.5.4) or by data provided by humans. While 547 machnine-oriented sources of asset characterization data may be 548 preferred, in many cases it is impractical or infeasible to collect 549 specific asset details using technical data collection mechanisms. 550 This is often true for asset characterization details that relate to 551 the business, operational, or security context of the asset. In 552 these cases human data entry is required to provide the necessary 553 data. 555 Asset characterization data may be made available to tools from a 556 variety of sources. Asset data that is human-oriented and that 557 infrequently changes may be provided as records in a content 558 repository. Other sources of asset characterization data may 559 include: asset management, configuration management, and other 560 enterprise data stores. 562 Example standardized data models include the ENTITY-MIB [RFC6933] the 563 Q-BRIDGE-MIB MIB [RFC4363] and the MIB for Virtual Machines 564 Controlled by a Hypervisor . 566 Another example is the HOST-RESOURCES-MIB [RFC2790]. 568 [QUESTION: Do we need to document more examples?.] 570 [QUESTION: Are these examples appropriate for this section? They 571 seem to be more about data collection.] 573 [QUESTION: It's not clear if aspects of endpoint posture should be 574 included in this category. One way to look at asset characterization 575 is that it is metadata that is provided by humans only. Do we want 576 to move concepts that pertain to posture collected from endpoints to 577 a different sub-section?] 579 4.3. Deconfliction of Asset Identities 581 Different tools and data sources will use varying methods for asset 582 identification. These methods should be standardized as much as 583 possible to reduce the need for deconfliction. In reality, it will 584 not be possible to standardize all forms of asset identification due 585 to legacy, authorization, or network visibility concerns. In these 586 cases, multiple forms of asset identity will need to be collected to 587 enable tools to perform correlation of provided asset identification 588 data. 590 For class-level asset identities, it may be necessary for vendors and 591 end-user organizations to provide mapping data enabling translations 592 between different representations. Maintaining mappings between 593 asset identification representations is often a labor-intensive, 594 manual process that should be avoided by encouraging use of 595 standardized asset identifiers. 597 For instance-level asset identities, multiple forms of asset 598 identification should be provided when collecting data from 599 endpoints. Algorithms can then be used to weight and reconcile 600 different types asset identities, and collected characteristics to 601 correlate new data collected with historic information pertaining to 602 an asset and/or endpoint. In many cases where insufficient 603 identification information is available, it may only be possible to 604 associate data collected from different points of view at a minimum 605 level of confidence. 607 4.4. Asset Targeting 609 TERM: Asset targeting is the use of asset identification and 610 categorization information to drive human-directed, automated 611 decision making for data collection and analysis in support of 612 endpoint posture assessment. 614 Endpoints, and the assets that compose them, contain a wealth of 615 posture information. It is impractical to collect the full posture 616 of all endpoints managed by and accessing resources within an 617 organization. To support practical assessment of endpoint posture, 618 it is necessary to collect specific posture information from 619 endpoints based on an anticipated or actual need for the data. This 620 collection may be performed by polling the endpoint for specific 621 posture information on an ad-hoc basis or at regular intervals, or by 622 communicating to the endpoint what posture information it should 623 monitor and provide when changes occur. To support both methods, it 624 will be necessary to associate what posture details need to be 625 collected with asset identification and categorization information 626 that describe what types of endpoints and assets that may provide 627 these details. Furthermore, it will be necessary to use asset 628 identification and categorization information to identify what assets 629 should be evaluated for specific assessments. 631 When defining content that drives data collection and analysis 632 activities, or that provides information that enriches analysis of 633 collected data, the need exists to relate this data to identified 634 assets or to categories of assets described by asset characteristics. 635 These associations, often called "statements of applicability" are 636 critical to exposing information for machine processing. 638 Statements of applicability enable digital policies (e.g., 639 checklists, baselines, access control rules), data records (e.g., 640 vulnerability data, associations of patches to software) to be 641 associated with asset, security, operational, and business contexts. 642 Using these associations, applicable content can be queried in 643 content repositories and made available at the points where the data 644 needs to be used. They also enable humans to query and (re)use 645 content provided by other individuals in their organization, by 646 vendors, and 3rd parties in constructing policies and configuring 647 data collection and analysis tools. 649 For example, in order to establish an understanding of the security 650 state of endpoints managed by an organization, the security system 651 needs to be able to make use of various asset management data. It 652 needs to: 654 o Determine what is the expected state for those endpoints. To do 655 this it will need to identify what expected state criteria is 656 associated with the endpoint based on the identification and 657 characterization of the endpoint, and any assets that compose the 658 endpoint. 660 o Once the criteria is identified, it will need to determine what 661 actual state data is needed to feed the analysis. This data will 662 need to be retrieved from existing data stores and from the 663 endpoints directly if necessary. Data collection rules may be 664 associated with specific asset identifiers or characteristics that 665 indicate what data sources or collectors to use to acquire the 666 data. 668 o Once the necessary actual state information is acquired, the 669 evaluator may need additional content to perform the analysis. 670 Based on the collected information, specific records will be 671 queried from a content repository based on asset identifiers and 672 characteristics. 674 o Finally, the appropriate assessment can be performed. 676 4.5. Other Unedited Content 678 The current editorial focus has been on the old asset management 679 subsection. The content in these subsections needs to be reworked 680 next. 682 4.5.1. Endpoint Configuration Management 684 Organizations manage a variety of configurations within their 685 enterprise including: endpoints, the hardware they are composed of, 686 installed software, hardware/software licenses used, and 687 configurations. 689 Security configuration management (SCM) deals with the configuration 690 of endpoints, including networking infrastructure devices and 691 computing hosts. Data will include installed hardware and software, 692 its configuration, and its use on the endpoint. 694 [TODO: While some configuration settings might not be considered 695 security relevant, it is not always possible to draw a clear 696 distinction between security and non-security settings (e.g., power 697 saving features). Do we want to make a distinction between security 698 and non-security configuration settings?] 700 The following list details some requisite Configuration Management 701 capabilities: 703 o [todo] 705 4.5.1.1. Organizing Configuration Metadata 706 Configuration metadata supports tooling helping organizations 707 understand what configuration they should implement, using specific 708 configuration values. 710 Enable data repositories containing machine-readable representations 711 of: 713 Configuration scoring: Characterizations of the relative security 714 value of discrete configuration settings and specific values 716 Configuration dependencies (e.g., lists of settings, associated 717 software, pre-requisite configurations) 719 Control catalog mappings supporting compliance [todo: in scope?] 721 4.5.1.2. Publishing Recommended Configuration Posture 723 Provide a mechanism for vendors and organizations to exchange 724 machine-oriented descriptions of recommended configuration setting 725 for software products. Enable organizations to apply recommended 726 settings as expected configuration posture. Enable association of 727 data-driven collection instructions using appropriate formats. 729 4.5.1.3. Defining Organizationally Expected Configuration Posture 731 Provide a mechanism for organizations to define and exchange expected 732 configuration posture including: authorized software and associated 733 configuration settings. 735 [TODO: Should software installation posture be defined separately?] 737 4.5.1.4. Collecting Endpoint Configuration Posture 739 Enable collection and exchange of actual configuration posture 740 including: installed software and values for configured settings. 742 [TODO: Should collecting software installation posture be defined 743 separately?] 745 4.5.1.5. Comparing Expected and Actual Configuration Posture 747 Enable evaluation of actual configuration posture against expected 748 configuration posture. Generate a machine-oriented description of 749 conformant and non-conformant posture including software inventory 750 and configuration values. 752 [TODO: Should collecting software installation posture be defined 753 separately?] 755 [TODO: Examining software version configuration - Example - HOST- 756 RESOURCES-MIB 758 4.5.1.6. Examining configuration of logical to physical mappings 760 [TODO: not sure what this is? Is it in scope?] 762 Example - ENTITY-MIB 764 4.5.1.7. Configuring Endpoint Interfaces 766 [TODO: not sure what this is? Is it in scope?] 768 Example - YANG module ietf-interfaces 770 4.5.2. Endpoint Posture Change Management 772 Organizations manage a variety of changes within their enterprise 773 including: [todo] 775 The following list details some requisite Change Management 776 capabilities: 778 o [todo] 780 4.5.2.1. Defining and Exchanging Baselines 782 [todo] 784 4.5.2.2. Detecting Unauthorized Changes 786 [todo] 788 [todo: figure out where these need to go] 790 4.5.2.2.1. Endpoint Addressing Changes 792 Example - DHCP addressing 794 4.5.2.2.2. Service Authorization Changes 796 Example - RADIUS network access 798 4.5.2.2.3. Dynamic Resource Assignment Changes 800 Example - NAT logging 802 4.5.2.2.4. Security Authorization Status Changes 804 Example - SYSLOG Authorization messages. SYSLOG [RFC5424] includes 805 facilities for security authorization messages. These messages can 806 be used to alert an analysts that an authorization attempt failed, 807 and the analyst might choose to follow up and assess potential 808 attacks on the relevant endpoint. 810 4.5.3. Security Vulnerability Management 812 Vulnerability management involves identifying the patch level of 813 software installed on the device and the identification of insecure 814 custom code (e.g. web vulnerabilities). All vulnerabilities need to 815 be addressed as part of a comprehensive risk management program, 816 which is a superset of software vulnerabilities. Thus, the 817 capability of assessing non-software vulnerabilities applicable to 818 the system is required. Additionally, it may be necessary to support 819 non-technical assessment of data relating to assets such as aspects 820 related to operational and management controls. 822 policy attribute collection 824 The following list details some requisite Vulnerability Management 825 capabilities: 827 o Collect the state of non-technical controls commonly called 828 administrative controls (i.e. policy, process, procedure) 830 o Collect the state of technical controls including, but not 831 necessarily limited to: 833 * Software inventory (e.g. operating system, applications, 834 patches) 836 * Configuration settings 838 4.5.3.1. Example - NIDS response 839 1. An organization's Network Intrusion Detection System detects a 840 suspect packet received by an endpoint and sends an alert to an 841 analyst. The analyst looks up the endpoint in the asset inventory 842 database, looks up the configuration policy associated with that 843 endpoint, and initiates an endpoint assessment of installed software 844 and patches on the endpoint to determine if the endpoint is compliant 845 with policy. 847 The analyst reviews the results of the assessment and takes action 848 according to organization policy and procedures. 850 4.5.3.2. Example - Historical vulnerability analysis 852 When a serious vulnerability or a zero-day attack is discovered, one 853 of the first priorities in any organization is to determine which 854 endpoints may have been affected and assess those endpoints to try to 855 determine whether they were compromised. Checking current endpoint 856 state is not sufficient because an endpoint may have been temporarily 857 compromised due to this vulnerability and then the infection may have 858 removed itself. In fact, the vulnerable software may have been 859 removed or upgraded since the compromise took place. And if the 860 endpoint is still compromised, the malware on the endpoint may cause 861 it to lie about its configuration. In this environment, maintaining 862 historical information about endpoint configuration is essential. 863 Such information can be used to find endpoints that had the 864 vulnerable software installed at some point in time. Those endpoints 865 can be checked for current or past indicators of compromise such as 866 files or behavior linked to a known exploit for this vulnerability. 867 Endpoints found to be vulnerable can be isolated to prevent infection 868 while remediation is done. Endpoints believed to be compromised can 869 be isolated for analysis and to limit the spread of infection. 871 4.5.3.3. Source Address Validation 873 Source Address Validation Improvement methods were developed to 874 prevent nodes attached to the same IP link from spoofing each other's 875 IP addresses, so as to complement ingress filtering with finer- 876 grained, standardized IP source address validation. The framework 877 document describes and motivates the design of the SAVI methods. 878 Particular SAVI methods are described in other documents. 880 4.5.4. Data Collection 882 Central to any automated assessment solution is the ability to 883 collect data from, or related to, an endpoint, such as the security 884 state of the endpoint and its constituent assets. 886 So, is data collection a requirement or an architectural concept 887 rather than a use case? 889 QUESTION: Understand more about what is meant by non-software 890 vulnerabilities 892 4.5.5. Assessment Result Analysis 894 The data collected needs to be analyzed for compliance to a standard 895 stipulated by the enterprise. Analysis methods may vary between 896 enterprises, but commonly take a similar form. 898 The following capabilities support the analysis of assessment 899 results: 901 o Comparing actual state to expected state 903 o Scoring/weighting individual comparison results 905 o Relating specific comparisons to benchmark-level requirements 907 o Relating benchmark-level requirements to one or more control 908 frameworks 910 4.5.6. Content Management 912 The capabilities required to support risk management state 913 measurement will yield volumes of content. The efficacy of risk 914 management state measurement depends directly on the stability of the 915 driving content, and, subsequently, the ability to change content 916 according to enterprise needs. 918 Capabilities supporting Content Management should provide the ability 919 to create/define or modify content, as well as store and retrieve 920 said content of at least the following types: 922 o Configuration checklists 924 o Assessment rules 926 o Data collection rules and methods 928 o Scoring models 930 o Vulnerability information 932 o Patch information 933 o Asset characterization data and rules 935 Note that the ability to modify content is in direct support of 936 tailoring content for enterprise-specific needs. 938 5. IANA Considerations 940 This memo includes no request to IANA. 942 6. Security Considerations 944 This memo documents, for Informational purposes, use cases for 945 security automation. While it is about security, it does not affect 946 security. 948 7. Acknowledgements 950 The National Institute of Standards and Technology (NIST) and/or the 951 MITRE Corporation have developed specifications under the general 952 term "Security Automation" including languages, protocols, 953 enumerations, and metrics. 955 The authors would like to recognize and thank Adam Montville for his 956 work on early edits of this draft. Additionally, the authors would 957 like to thank Kathleen Moriarty and Stephen Hanna for contributing 958 text to this document. The authors would also like to acknowledge 959 the members of the SACM mailing list for their keen and insightful 960 feedback on the concepts and text within this document. 962 8. Change Log 964 8.1. -00- to -01- 966 o Work on this revision has been focused on document content 967 relating primarily to use of asset management data and functions. 969 o Made significant updates to section 3 including: 971 * Reworked introductory text. 973 * Replaced the single example with multiple use cases that focus 974 on more discrete uses of asset management data to support 975 hardware and software inventory, and configuration management 976 use cases. 978 * For one of the use cases, added mapping to functional 979 capabilities used. If popular, this will be added to the other 980 use cases as well. 982 * Additional use cases will be added in the next revision 983 capturing additional discussion from the list. 985 o Made significant updates to section 4 including: 987 * Renamed the section heading from "Use Cases" to "Functional 988 Capabilities" since use cases are covered in section 3. This 989 section now extrapolates specific functions that are needed to 990 support the use cases. 992 * Started work to flatten the section, moving select subsections 993 up from under asset management. 995 * Removed the subsections for: Asset Discovery, Endpoint 996 Components and Asset Composition, Asset Resources, and Asset 997 Life Cycle. 999 * Renamed the subsection "Asset Representation Reconciliation" to 1000 "Deconfliction of Asset Identities". 1002 * Expanded the subsections for: Asset Identification, Asset 1003 Characterization, and Deconfliction of Asset Identities. 1005 * Added a new subsection for Asset Targeting. 1007 * Moved remaining sections to "Other Unedited Content" for future 1008 updating. 1010 8.2. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 1012 o Transitioned from individual I/D to WG I/D based on WG consensus 1013 call. 1015 o Fixed a number of spelling errors. Thank you Erik! 1017 o Added keywords to the front matter. 1019 o Removed the terminology section from the draft. Terms have been 1020 moved to: draft-dbh-sacm-terminology-00 1022 o Removed requirements to be moved into a new I/D. 1024 o Extracted the functionality from the examples and made the 1025 examples less prominent. 1027 o Renamed "Functional Capabilities and Requirements" section to "Use 1028 Cases". 1030 * Reorganized the "Asset Management" sub-section. Added new text 1031 throughout. 1033 + Renamed a few sub-section headings. 1035 + Added text to the "Asset Characterization" sub-section. 1037 o Renamed "Security Configuration Management" to "Endpoint 1038 Configuration Management". Not sure if the "security" distinction 1039 is important. 1041 * Added new sections, partially integrated existing content. 1043 * Additional text is needed in all of the sub-sections. 1045 o Changed "Security Change Management" to "Endpoint Posture Change 1046 Management". Added new skeletal outline sections for future 1047 updates. 1049 8.3. -04- to -05- 1051 o Are we including user activities and behavior in the scope of this 1052 work? That seems to be layer 8 stuff, appropriate to an IDS/IPS 1053 application, not Internet stuff. 1055 o I removed the references to what the WG will do because this 1056 belongs in the charter, not the (potentially long-lived) use cases 1057 document. I removed mention of charter objectives because the 1058 charter may go through multiple iterations over time; there is a 1059 website for hosting the charter; this document is not the correct 1060 place for that discussion. 1062 o I moved the discussion of NIST specifications to the 1063 acknowledgements section. 1065 o Removed the portion of the introduction that describes the 1066 chapters; we have a table of concepts, and the existing text 1067 seemed redundant. 1069 o Removed marketing claims, to focus on technical concepts and 1070 technical analysis, that would enable subsequent engineering 1071 effort. 1073 o Removed (commented out in XML) UC2 and UC3, and eliminated some 1074 text that referred to these use cases. 1076 o Modified IANA and Security Consideration sections. 1078 o Moved Terms to the front, so we can use them in the subsequent 1079 text. 1081 o Removed the "Key Concepts" section, since the concepts of ORM and 1082 IRM were not otherwise mentioned in the document. This would seem 1083 more appropriate to the arch doc rather than use cases. 1085 o Removed role=editor from David Waltermire's info, since there are 1086 three editors on the document. The editor is most important when 1087 one person writes the document that represents the work of 1088 multiple people. When there are three editors, this role marking 1089 isn't necessary. 1091 o Modified text to describe that this was specific to enterprises, 1092 and that it was expected to overlap with service provider use 1093 cases, and described the context of this scoped work within a 1094 larger context of policy enforcement, and verification. 1096 o The document had asset management, but the charter mentioned 1097 asset, change, configuration, and vulnerability management, so I 1098 added sections for each of those categories. 1100 o Added text to Introduction explaining goal of the document. 1102 o Added sections on various example use cases for asset management, 1103 config management, change management, and vulnerability 1104 management. 1106 9. References 1108 9.1. Normative References 1110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14, RFC 2119, March 1997. 1113 9.2. Informative References 1115 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1116 converting network protocol addresses to 48.bit Ethernet 1117 address for transmission on Ethernet hardware", STD 37, 1118 RFC 826, November 1982. 1120 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1121 for Network Management of TCP/IP-based internets:MIB-II", 1122 STD 17, RFC 1213, March 1991. 1124 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 1125 2790, March 2000. 1127 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1128 MIB", RFC 2863, June 2000. 1130 [RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB", RFC 1131 2922, September 2000. 1133 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed 1134 Objects for Bridges with Traffic Classes, Multicast 1135 Filtering, and Virtual LAN Extensions", RFC 4363, January 1136 2006. 1138 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1140 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1141 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 1142 2013. 1144 Authors' Addresses 1146 David Waltermire 1147 National Institute of Standards and Technology 1148 100 Bureau Drive 1149 Gaithersburg, Maryland 20877 1150 USA 1152 Email: david.waltermire@nist.gov 1154 David Harrington 1155 Effective Software 1156 50 Harding Rd 1157 Portsmouth, NH 03801 1158 USA 1160 Email: ietfdbh@comcast.net