idnits 2.17.1 draft-waltermire-sacm-use-cases-05.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 (July 15, 2013) is 3932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-nea-pt-eap' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nea-pt-tls' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-interfaces-cfg' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-system-mgmt' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-savi-framework' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC5792' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC5793' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 882, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-06 == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-12 == Outdated reference: A later version (-16) exists of draft-ietf-netmod-system-mgmt-08 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). 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 A. Montville 5 Expires: January 16, 2014 TW 6 D. Harrington 7 Effective Software 8 July 15, 2013 10 Using Security Posture Assessment to Grant Access to Enterprise Network 11 Resources 12 draft-waltermire-sacm-use-cases-05 14 Abstract 16 This memo documents a sampling of use cases for securely aggregating 17 configuration and operational data and assessing that data to 18 determine an organization's security posture. From these operational 19 use cases, we can derive common functional capabilities and 20 requirements to guide development of vendor-neutral, interoperable 21 standards for aggregating and assessing data relevant to security 22 posture. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 16, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 3. Endpoint Posture Assessment . . . . . . . . . . . . . . . . . 6 62 3.1. Example - Departmental Software Policy Compliance . . . . 6 63 3.2. Main Success Scenario . . . . . . . . . . . . . . . . . . 6 64 4. Functional Capabilities and Requirements . . . . . . . . . . 7 65 4.1. Asset Management . . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. Example - Asset Discovery within a subnet . . . . . . 7 67 4.1.2. Example - Asset Discovery by IP Address . . . . . . . 7 68 4.1.3. Example - Asset Characterization using system 69 information . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.4. Example - Asset Characterization using the ENTITY-MIB 8 71 4.1.5. Example - Asset Characterization using the HOST- 72 RESOURCES-MIB . . . . . . . . . . . . . . . . . . . . 8 73 4.1.6. Concepts . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.7. Requirements . . . . . . . . . . . . . . . . . . . . 9 75 4.2. Security Configuration Management . . . . . . . . . . . . 9 76 4.2.1. Example - ENTITY-MIB . . . . . . . . . . . . . . . . 10 77 4.2.2. Example - HOST-RESOURCES-MIB . . . . . . . . . . . . 10 78 4.2.3. Example - YANG module ietf-interfaces . . . . . . . . 10 79 4.2.4. Concepts . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2.5. Requirements . . . . . . . . . . . . . . . . . . . . 10 81 4.3. Security Change Management . . . . . . . . . . . . . . . 10 82 4.3.1. Example - DHCP addressing . . . . . . . . . . . . . . 10 83 4.3.2. Example - RADIUS network access . . . . . . . . . . . 10 84 4.3.3. Example - NAT logging . . . . . . . . . . . . . . . . 10 85 4.3.4. Example - SYSLOG Authorization messages . . . . . . . 10 86 4.3.5. Concepts . . . . . . . . . . . . . . . . . . . . . . 10 87 4.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 11 88 4.4. Security Vulnerability Management . . . . . . . . . . . . 11 89 4.4.1. Example - NIDS response . . . . . . . . . . . . . . . 11 90 4.4.2. Example - Historical vulnerability analysis . . . . . 11 91 4.4.3. Source Address Validation . . . . . . . . . . . . . . 12 92 4.4.4. Concepts . . . . . . . . . . . . . . . . . . . . . . 12 93 4.4.5. Requirements . . . . . . . . . . . . . . . . . . . . 12 94 4.5. Data Collection . . . . . . . . . . . . . . . . . . . . . 12 95 4.5.1. Concepts . . . . . . . . . . . . . . . . . . . . . . 12 96 4.5.2. Requirements . . . . . . . . . . . . . . . . . . . . 12 98 4.6. Assessment Result Analysis . . . . . . . . . . . . . . . 14 99 4.6.1. Concepts . . . . . . . . . . . . . . . . . . . . . . 14 100 4.6.2. Requirements . . . . . . . . . . . . . . . . . . . . 14 101 4.7. Content Management . . . . . . . . . . . . . . . . . . . 15 102 4.7.1. Concepts . . . . . . . . . . . . . . . . . . . . . . 15 103 4.7.2. Requirements . . . . . . . . . . . . . . . . . . . . 15 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 107 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 8.1. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 16 109 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 110 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 111 9.2. Informative References . . . . . . . . . . . . . . . . . 17 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 114 1. Introduction 116 Our goal with this document is to improve our agreement on which 117 problems we're trying to solve. We need to start with short, simple 118 problem statements and discuss those by email and in person. Once we 119 agree on which problems we're trying to solve, we can move on to 120 propose various solutions and decide which ones to use. 122 This document describes example use cases for endpoint posture 123 assessment for enterprises. It provides a sampling of use cases for 124 securely aggregating configuration and operational data and assessing 125 that data to determine the security posture of individual endpoints, 126 and, in the aggregate, the security posture of an enterprise. 128 These use cases cross many IT security information domains. From 129 these operational use cases, we can derive common concepts, common 130 information expressions, functional capabilities and requirements to 131 guide development of vendor-neutral, interoperable standards for 132 aggregating and assessing data relevant to security posture. 134 Using this standard data, tools can analyse the state of endpoints, 135 user activities and behaviour, and assess the security posture of an 136 organization. Common expression of information should enable 137 interoperability between tools (whether customized, commercial, or 138 freely available), and the ability to automate portions of security 139 processes to gain efficiency, react to new threats in a timely 140 manner, and free up security personnel to work on more advanced 141 problems. 143 The goal is to enable organizations to make informed decisions that 144 support organizational objectives, to enforce policies for hardening 145 systems, to prevent network misuse, to quantify business risk, and to 146 collaborate with partners to identify and mitigate threats. 148 It is expected that use cases for enterprises and for service 149 providers will largely overlap, but there are additional 150 complications for service providers, especially in handling 151 information that crosses administrative domains. 153 The output of endpoint posture assessment is expected to feed into 154 additional processes, such as policy-based enforcement of acceptable 155 state, verification and monitoring of security controls, and 156 compliance to regulatory requirements. 158 2. Terms and Definitions 160 assessment 162 Defined in [RFC5209] as "the process of collecting posture for a 163 set of capabilities on the endpoint (e.g., host-based firewall) 164 such that the appropriate validators may evaluate the posture 165 against compliance policy." 167 Within this document the use of the term is expanded to support 168 other uses of collected posture (e.g. reporting, network 169 enforcement, vulnerability detection, license management). The 170 phrase "set of capabilities on the endpoint" includes: hardware 171 and software installed on the endpoint." 173 asset 175 Defined in [RFC4949] as "a system resource that is (a) required to 176 be protected by an information system's security policy, (b) 177 intended to be protect by a countermeasure, or (c) required for a 178 system's mission. 180 attribute 182 Defined in [RFC5209] as "data element including any requisite 183 meta-data describing an observed, expected, or the operational 184 status of an endpoint feature (e.g., anti-virus software is 185 currently in use)." 187 endpoint 189 Defined in [RFC5209] as "any computing device that can be 190 connected to a network. Such devices normally are associated with 191 a particular link layer address before joining the network and 192 potentially an IP address once on the network. This includes: 193 laptops, desktops, servers, cell phones, or any device that may 194 have an IP address." 196 Network infrastructure devices (e.g. switches, routers, 197 firewalls), which fit the definition, are also considered to be 198 endpoints within this document. 200 Based on the previous definition of an asset, an endpoint is a 201 type of asset. 203 posture 205 Defined in [RFC5209] as "configuration and/or status of hardware 206 or software on an endpoint as it pertains to an organization's 207 security policy." 209 This term is used within the scope of this document to represent 210 the state information that is collected from an endpoint (e.g. 211 software/hardware inventory, configuration settings). 213 posture attributes 215 Defined in [RFC5209] as "attributes describing the configuration 216 or status (posture) of a feature of the endpoint. For example, a 217 Posture Attribute might describe the version of the operating 218 system installed on the system." 220 Within this document this term represents a specific assertion 221 about endpoint state (e.g. configuration setting, installed 222 software, hardware). The phrase "features of the endpoint" refers 223 to installed software or software components. 225 system resource 227 Defined in [RFC4949] as "data contained in an information system; 228 or a service provided by a system; or a system capacity, such as 229 processing power or communication bandwidth; or an item of system 230 equipment (i.e., hardware, firmware, software, or documentation); 231 or a facility that houses system operations and equipment. 233 2.1. Requirements Language 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 3. Endpoint Posture Assessment 241 Endpoint posture assessment involves collecting information about the 242 posture of a given endpoint. This posture information is gathered 243 and then published to appropriate data repositories to make collected 244 information available for further analysis supporting organizational 245 security processes. 247 Endpoint posture assessment typically includes: 249 o Collecting the posture of a given endpoint; 251 o Making that posture available to the enterprise for further 252 analysis and action; and 254 o Assessing that the endpoint's posture is in compliance with 255 enterprise standards and policy. 257 3.1. Example - Departmental Software Policy Compliance 259 In order to meet compliance requirements and ensure that corporate 260 finance information is not revealed improperly, all computers in the 261 finance department of Example Corporation are required to run only 262 software contained on an approved list and to be configured to 263 download and install software patches every night. Each computer is 264 checked to make sure it complies with this policy whenever it 265 connects to the network and at least once a day thereafter. These 266 daily compliance checks assess the posture of each computer and 267 report on its compliance with policy. 269 3.2. Main Success Scenario 271 1. Define a target endpoint to be assessed 273 2. Select acceptable state policies to apply to the defined target 275 3. Identify the endpoint being assessed 277 4. Collect posture attributes from the target 279 5. Communicate target identity and collected posture to external 280 system for evaluation 282 6. Compare collected posture attributes from the target endpoint 283 with expected state values as expressed in acceptable state 284 policies 286 4. Functional Capabilities and Requirements 288 The capabilities in this section support assessing endpoint posture 289 in an automated manner as described in Section Section 3. 291 4.1. Asset Management 293 Organizations manage a variety of assets within their enterprise 294 including: endpoints, the hardware they are composed of, installed 295 software, hardware/software licenses used, and configurations. 297 Managing endpoints and the different types of assets that compose 298 them involves initially discovering and characterizing each asset 299 instance, and then identify them in a common way. Characterization 300 may take the form of logical characterization or security 301 characterization, where logical characterization may include business 302 context not otherwise related to security, but which may be used as 303 information in support of decision making later in risk management. 305 4.1.1. Example - Asset Discovery within a subnet 307 Many network management systems detect the presence of assets in a 308 subnet, such as an Ethernet subnet, by monitoring the MAC addresses 309 bradcast within the subnet to determine who responds to broadcasts, 310 and determing the location of the endpoint relative to a bridge. 311 This information is useful for initally discovering and 312 characterizing endpoints belonging to a particular type of network 313 (e.g. Ethernet), and for detecting new nodes in the subnet. This 314 type of information may be accessible by accessing ARP tables 315 [RFC0826], Etherlike-MIB [RFC3535], the Link Layer Discovery Protocol 316 MIB [RFC2922], the Interfaces MIB (IF-MIB) [RFC2863], the YANG module 317 ietf-interfaces , and others. 319 4.1.2. Example - Asset Discovery by IP Address 321 Many network management systems periodically test for the presence of 322 endpoints or interfaces in a network by broadcasting ICMP echo 323 commands (pings) to a range of IP addresses and recording the 324 addresses of nodes that respond. This helps discover the endpoints 325 in the network, including endpoints that have suddenly appeared in a 326 network tha are not authorized to be part of the network. 328 4.1.3. Example - Asset Characterization using system information 330 The SYSTEM-MIB [RFC1213] contains information to help characterize an 331 endpoint, including a description of the endpoint, an authoritative 332 identifier of the type of endpoint assigned by the vendor of the 333 endpoint, an administrative name for the endpoint, plus the 334 endpoint's contact person, the location of the endpoint, system time, 335 and an enumerator that identifies the layer of services provided by 336 the endpoint. The system decription includes the vendor, product 337 type, model number, OS version, and networking software version. 338 This is a key MIB module mandated for all SNMP-managed endpoints. 340 Similar information is available via the YANG module ietf-system . 341 This module includes data node definitions for system identification, 342 time-of-day management, user management, DNS resolver configuration, 343 and some protocol operations for system management. 345 4.1.4. Example - Asset Characterization using the ENTITY-MIB 347 The ENTITY-MIB [RFC6933] contains information to describe the 348 components of an endpoint, including physical and logical components, 349 and the relationships between the components. The information about 350 the physical entities includes manufacturer-assigned serial number, 351 manufacture date, administratively-assigned AssetID, and UUID. 352 Logical entities may be defined, and associated with the physical 353 entities using a mapping table. 355 4.1.5. Example - Asset Characterization using the HOST-RESOURCES-MIB 357 The HOST-RESOURCES-MIB [RFC2790] contains information to describe the 358 resources of an endpoint, including storage, memory, installed 359 software, running software, software versions, processes, user 360 sessions, devices (processors, disks, printers, network interfaces, 361 etc.). This MIB module also provides monitoring of performance and 362 error states. 364 4.1.6. Concepts 366 Managing endpoints and the different types of assets that compose 367 them involves initially discovering and characterizing each asset 368 instance, and then identify them in a common way. Characterization 369 may take the form of logical characterization or security 370 characterization, where logical characterization may include business 371 context not otherwise related to security, but which may be used as 372 information in support of decision making later in risk management. 374 Coverage involves understanding what and how many assets are under 375 control. Assessing 80% of the enterprise assets is better than 376 assessing 50% of the enterprise assets. 378 Getting asset details can be comparatively subtle - if an enterprise 379 does not have a precise understanding of its assets, then all 380 acquired data and consequent actions taken based on the data are 381 considered suspect. 383 Assessing assets (managed and unmanaged) requires that we have 384 visibility into the posture of endpoints, the ability to understand 385 the composition and relationships between different assets types, and 386 the ability to properly characterize them at the outset and over 387 time. 389 The following list details some requisite Asset Management 390 capabilities: 392 o Discover assets in the enterprise 394 o For a given endpoint, understand the composition and relationship 395 of its constituent assets 397 o Characterize assets according to security and non-security asset 398 properties 400 o Identify and describe assets using a common vocabulary between 401 implementations 403 o Reconcile asset representations originating from disparate tools 405 o Manage asset information throughout the asset's life cycle 407 4.1.7. Requirements 409 A method MUST be provided for identifying an endpoint (asset 410 identification) as a unique entity within the its administrative 411 domain. 413 The endpoint identifier SHOULD be able to be determined in an 414 automated manner. 416 The endpoint identifier, as communicated between entities, SHOULD 417 be held to a minimal size. 419 A method MUST be provided for defining an endpoint (asset 420 classification) based on a set of organizationally relevant 421 properties (e.g. organizational affiliation, criticality, 422 function). 424 4.2. Security Configuration Management 426 Organizations manage a variety of configurations within their 427 enterprise including: endpoints, the hardware they are composed of, 428 installed software, hardware/software licenses used, and 429 configurations. 431 4.2.1. Example - ENTITY-MIB 433 4.2.2. Example - HOST-RESOURCES-MIB 435 4.2.3. Example - YANG module ietf-interfaces 437 4.2.4. Concepts 439 Security configuration management (SCM) deals with the configuration 440 of endpoints, including networking infrastructure devices and 441 computing hosts. Data will include installed hardware and software, 442 its configuration, and its use on the endpoint. 444 The following list details some requisite Configuration Management 445 capabilities: 447 o [todo] 449 4.2.5. Requirements 451 [todo] 453 4.3. Security Change Management 455 Organizations manage a variety of changes within their enterprise 456 including: [todo] 458 4.3.1. Example - DHCP addressing 460 4.3.2. Example - RADIUS network access 462 4.3.3. Example - NAT logging 464 4.3.4. Example - SYSLOG Authorization messages 466 SYSLOG [RFC5424] includes facilities for security authorization 467 messages. These messages can be used to alert an analysts that an 468 authorization attempt failed, and the analyst might choose to follow 469 up and assess potential attacks on the relevant endpoint. 471 4.3.5. Concepts 473 [todo] 475 The following list details some requisite Change Management 476 capabilities: 478 o [todo] 480 4.3.6. Requirements 482 [todo] 484 4.4. Security Vulnerability Management 486 Vulnerability management involves identifying the patch level of 487 software installed on the device and the identification of insecure 488 custom code (e.g. web vulnerabilities). All vulnerabilities need to 489 be addressed as part of a comprehensive risk management program, 490 which is a superset of software vulnerabilities. Thus, the 491 capability of assessing non-software vulnerabilities applicable to 492 the system is required. Additionally, it may be necessary to support 493 non-technical assessment of data relating to assets such as aspects 494 related to operational and management controls. 496 policy attribute collection 498 4.4.1. Example - NIDS response 500 1. An organization's Network Intrusion Detection System detects a 501 suspect packet received by an endpoint and sends an alert to an 502 analyst. The analyst looks up the endpoint in the asset inventory 503 database, looks up the configuration policy associtaed with that 504 endpoint, and initates an endpoint assessment of installed software 505 and patches on the endpoint to determine if the endpoint is compliant 506 with policy. 508 The analyst reviews the results of the assessment and takes action 509 according to organization policy and procedures. 511 4.4.2. Example - Historical vulnerability analysis 513 When a serious vulnerability or a zero-day attack is discovered, one 514 of the first priorities in any organization is to determine which 515 endpoints may have been affected and assess those endpoints to try to 516 determine whether they were compromised. Checking current endpoint 517 state is not sufficient because an endpoint may have been temporarily 518 compromised due to this vulnerability and then the infection may have 519 removed itself. In fact, the vulnerable software may have been 520 removed or upgraded since the compromise took place. And if the 521 endpoint is still compromised, the malware on the endpoint may cause 522 it to lie about its configuration. In this environment, maintaining 523 historical information about endpoint configuration is essential. 524 Such information can be used to find endpoints that had the 525 vulnerable software installed at some point in time. Those endpoints 526 can be checked for current or past indicators of compromise such as 527 files or behavior linked to a known exploit for this vulnerability. 529 Endpoints found to be vulnerable can be isolated to prevent infection 530 while remediation is done. Endpoints believed to be compromised can 531 be isolated for analysis and to limit the spread of infection. 533 4.4.3. Source Address Validation 535 Source Address Validation Improvement methods were developed to 536 prevent nodes attached to the same IP link from spoofing each other's 537 IP addresses, so as to complement ingress filtering with finer- 538 grained, standardized IP source address validation. The framework 539 document describes and motivates the design of the SAVI methods. 540 Particular SAVI methods are described in other documents. 542 4.4.4. Concepts 544 The following list details some requisite Vulnerability Management 545 capabilities: 547 o Collect the state of non-technical controls commonly called 548 administrative controls (i.e. policy, process, procedure) 550 o Collect the state of technical controls including, but not 551 necessarily limited to: 553 * Software inventory (e.g. operating system, applications, 554 patches) 556 * Configuration settings 558 4.4.5. Requirements 560 [todo] 562 4.5. Data Collection 564 Central to any automated assessment solution is the ability to 565 collect data from, or related to, an endpoint, such as the security 566 state of the endpoint and its constituent assets. 568 4.5.1. Concepts 570 The following assessment capabilities support SCM: 572 o [todo] 574 4.5.2. Requirements 575 One or more data formats MUST be identified to describe instructions, 576 data collection methods, to drive data collection (e.g. technical, 577 interrogative). 579 One or more data formats MUST be identified to instruct what posture 580 attributes need to be collected for a specific set of endpoints. 582 A method MUST be provided to include OPTIONAL instructions on 583 describing what content must be run on the endpoint. 585 A method MUST be provided to include OPTIONAL instructions that 586 determine how to collect data supporting any particular test for 587 that endpoint. 589 A method MUST be provided for retrieving data collection instructions 590 from a remote host (see Section Section 4.7). 592 One or more data formats MUST be identified to capture the results of 593 data collection. 595 This expression MUST be capable of supporting the characterization 596 of assets and any related configuration settings that together 597 compose an endpoint. 599 A mechanism MUST be provided to identify the software and 600 hardware asset instances that compose an endpoint. 602 An asset identifier SHOULD be able to be determined in an 603 automated manner 605 An asset identifier, as communicated between entities, 606 SHOULD be held to a minimal size. 608 An asset identifier SHOULD be able to represented in a 609 simple unambiguous manner, such as a reference, so that its 610 embedded use in places like applicability clauses for 611 individual benchmark tests can be kept from making their 612 usage unwieldy. 614 A mechanism MUST be provided to associate configuration 615 settings values to the installed software. 617 A mechanism MUST be provided to identify additional collected 618 posture attribute/value pairs related to an endpoint. 620 A mechanism MUST be provided to identify the endpoint the results 621 pertain to (see Section Section 4.1. 623 A mechanism MUST be provided to associate the data collection 624 method with the collected value. 626 A mechanism MUST be provided to include provenance information 627 describing what sensor of software collected the data. 629 A mechanism MUST be provided to include entailment information, 630 perhaps by reference, describing the methodology used to collect 631 the data. 633 A method of communicating data collection results to another system 634 for further analysis MUST be identified. 636 TODO: Communicate, unambiguously and to the necessary level of 637 detail**, the asset details between software components 639 4.6. Assessment Result Analysis 641 The data collected needs to be analyzed for compliance to a standard 642 stipulated by the enterprise. Analysis methods may vary between 643 enterprises, but commonly take a similar form. 645 4.6.1. Concepts 647 The following capabilities support the analysis of assessment 648 results: 650 o Comparing actual state to expected state 652 o Scoring/weighting individual comparison results 654 o Relating specific comparisons to benchmark-level requirements 656 o Relating benchmark-level requirements to one or more control 657 frameworks 659 4.6.2. Requirements 661 A method MUST be provided for selecting acceptable state policy, 662 describing how to evaluate collected information, based on 663 characteristics of the endpoint and organizational policy. 665 A method MUST be provided for comparing collected data to expected 666 state values (test evaluation). 668 Any results produced by analysis processes MUST be capable of being 669 transformed into a human-readable format. 671 4.7. Content Management 673 The capabilities required to support risk management state 674 measurement will yield volumes of content. The efficacy of risk 675 management state measurement depends directly on the stability of the 676 driving content, and, subsequently, the ability to change content 677 according to enterprise needs. 679 4.7.1. Concepts 681 Capabilities supporting Content Management should provide the ability 682 to create/define or modify content, as well as store and retrieve 683 said content of at least the following types: 685 o Configuration checklists 687 o Assessment rules 689 o Data collection rules and methods 691 o Scoring models 693 o Vulnerability information 695 o Patch information 697 o Asset characterization data and rules 699 Note that the ability to modify content is in direct support of 700 tailoring content for enterprise-specific needs. 702 4.7.2. Requirements 704 A protocol MUST be identified for retrieving SACM content from a 705 content repository 707 A protocol MUST be identified for querying SACM content held in a 708 content repository. The protocol MUST support querying content by 709 applicability to asset characteristics. 711 TODO: Determine what content can or must be run on the endpoint 713 A protocol MUST be identified for curating SACM content in a content 714 repository. Note: This might be an area where we can limit the scope 715 of work relative to the initial SACM charter. 717 5. IANA Considerations 718 This memo includes no request to IANA. 720 6. Security Considerations 722 This memo documents, for Informational purposes, use cases for 723 security automation. While it is about security, it does not affect 724 security. 726 7. Acknowledgements 728 The National Institute of Standards and Technology (NIST) and/or the 729 MITRE Corporation have developed specifications under the general 730 term "Security Automation" including languages, protocols, 731 enumerations, and metrics. 733 The authors would like to thank Kathleen Moriarty and Stephen Hanna 734 for contributing text to this document. The author would also like 735 to acknowledge the members of the SACM mailing list for their keen 736 and insightful feedback on the concepts and text within this 737 document. 739 8. Change Log 741 8.1. -04- to -05- 743 o Are we including user activities and behavior in the scope of this 744 work? That seems to be layer 8 stuff, appropriate to an IDS/IPS 745 application, not Internet stuff. 747 o I removed the references to what the WG will do because this 748 belongs in the charter, not the (potentially long-lived) use cases 749 document. I removed mention of charter objectives because the 750 charter may go through multiple iterations over time; there is a 751 website for hosting the charter; this document is not the correct 752 place for that discussion. 754 o I moved the discussion of NIST specifications to the 755 acknowledgements section. 757 o Removed the portion of the introduction that describes the 758 chapters; we have a table of concepts, and the existing text 759 seemed redundant. 761 o Removed marketing claims, to focus on technical concepts and 762 technical analysis, that would enable subsequent engineering 763 effort. 765 o Removed (commented out in XML) UC2 and UC3, and eliminated some 766 text that referred to these use cases. 768 o Modified IANA and Security Consideration sections. 770 o Moved Terms to the front, so we can use them in the subsequent 771 text. 773 o Removed the "Key Concepts" section, since the concepts of ORM and 774 IRM were not otherwise mentioned in the document. This would seem 775 more appropriate to the arch doc rather than use cases. 777 o Removed role=editor from David Waltmire's info, since there are 778 three editors on the document. The editor is most important when 779 one person writes the document that represents the work of 780 multiple people. When there are three editors, this role marking 781 isn't necessary. 783 o Modified text to describe that this was specific to enterprises, 784 and that it was expected to overlap with service provider use 785 cases, and described the context of this scoped work within a 786 larger context of policy enforcement, and verification. 788 o The document had asset management, but the charter mentioned 789 asset, change, configuration, and vulnerability management, so I 790 added sections for each of those categories. 792 o Added text to Introduction explaining goal of the document. 794 o Added sections on various example use cases for asset management, 795 config management, change management, and vulnerability 796 management. 798 9. References 800 9.1. Normative References 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, March 1997. 805 9.2. Informative References 807 [I-D.ietf-nea-pt-eap] 808 Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 809 (PT) Protocol For EAP Tunnel Methods", draft-ietf-nea-pt- 810 eap-06 (work in progress), December 2012. 812 [I-D.ietf-nea-pt-tls] 813 Sangster, P., Cam-Winget, N., and J. Salowey, "PT-TLS: A 814 TLS-based Posture Transport (PT) Protocol", draft-ietf- 815 nea-pt-tls-08 (work in progress), October 2012. 817 [I-D.ietf-netmod-interfaces-cfg] 818 Bjorklund, M., "A YANG Data Model for Interface 819 Management", draft-ietf-netmod-interfaces-cfg-12 (work in 820 progress), July 2013. 822 [I-D.ietf-netmod-system-mgmt] 823 Bierman, A. and M. Bjorklund, "YANG Data Model for System 824 Management", draft-ietf-netmod-system-mgmt-08 (work in 825 progress), July 2013. 827 [I-D.ietf-savi-framework] 828 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 829 "Source Address Validation Improvement Framework", draft- 830 ietf-savi-framework-06 (work in progress), January 2012. 832 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 833 converting network protocol addresses to 48.bit Ethernet 834 address for transmission on Ethernet hardware", STD 37, 835 RFC 826, November 1982. 837 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 838 for Network Management of TCP/IP-based internets:MIB-II", 839 STD 17, RFC 1213, March 1991. 841 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 842 2790, March 2000. 844 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 845 MIB", RFC 2863, June 2000. 847 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 848 "Remote Authentication Dial In User Service (RADIUS)", RFC 849 2865, June 2000. 851 [RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB", RFC 852 2922, September 2000. 854 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 855 Management Workshop", RFC 3535, May 2003. 857 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 858 Text on Security Considerations", BCP 72, RFC 3552, July 859 2003. 861 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 862 4949, August 2007. 864 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 865 Tardo, "Network Endpoint Assessment (NEA): Overview and 866 Requirements", RFC 5209, June 2008. 868 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 869 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 870 May 2008. 872 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 874 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 875 (PA) Protocol Compatible with Trusted Network Connect 876 (TNC)", RFC 5792, March 2010. 878 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 879 A Posture Broker (PB) Protocol Compatible with Trusted 880 Network Connect (TNC)", RFC 5793, March 2010. 882 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 883 "Diameter Base Protocol", RFC 6733, October 2012. 885 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 886 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 887 2013. 889 Authors' Addresses 891 David Waltermire 892 National Institute of Standards and Technology 893 100 Bureau Drive 894 Gaithersburg, Maryland 20877 895 USA 897 Email: david.waltermire@nist.gov 899 Adam W. Montville 900 Tripwire, Inc. 901 101 SW Main Street, Suite 1500 902 Portland, Oregon 97204 903 USA 905 Email: amontville@tripwire.com 906 David Harrington 907 Effective Software 908 50 Harding Rd 909 Portsmouth, NH 03801 910 USA 912 Email: ietfdbh@comcast.net