idnits 2.17.1 draft-ietf-sacm-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 22, 2013) is 3899 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: February 23, 2014 Effective Software 6 August 22, 2013 8 Using Security Posture Assessment to Grant Access to Enterprise Network 9 Resources 10 draft-ietf-sacm-use-cases-00 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 February 23, 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. Example - Departmental Software Policy Compliance . . . . 4 60 3.2. Main Success Scenario . . . . . . . . . . . . . . . . . . 4 61 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Asset Management . . . . . . . . . . . . . . . . . . . . 5 63 4.1.1. Asset Discovery . . . . . . . . . . . . . . . . . . . 6 64 4.1.2. Asset Identification . . . . . . . . . . . . . . . . 6 65 4.1.3. Endpoint Components and Asset Composition . . . . . . 7 66 4.1.4. Asset Characterization . . . . . . . . . . . . . . . 7 67 4.1.5. Asset Resources . . . . . . . . . . . . . . . . . . . 9 68 4.1.6. Asset Representation Reconciliation . . . . . . . . . 9 69 4.1.7. Asset Life Cycle . . . . . . . . . . . . . . . . . . 9 70 4.2. Endpoint Configuration Management . . . . . . . . . . . . 9 71 4.2.1. Organizing Configuration Metadata . . . . . . . . . . 10 72 4.2.2. Publishing Recommended Configuration Posture . . . . 10 73 4.2.3. Defining Organizationally Expected Configuration 74 Posture . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.4. Collecting Endpoint Configuration Posture . . . . . . 10 76 4.2.5. Comparing Expected and Actual Configuration Posture . 10 77 4.2.6. Examining configuration of logical to physical 78 mappings . . . . . . . . . . . . . . . . . . . . . . 11 79 4.2.7. Configuring Endpoint Interfaces . . . . . . . . . . . 11 80 4.3. Endpoint Posture Change Management . . . . . . . . . . . 11 81 4.3.1. Defining and Exchanging Baselines . . . . . . . . . . 11 82 4.3.2. Detecting Unauthorized Changes . . . . . . . . . . . 11 83 4.3.2.1. Endpoint Addressing Changes . . . . . . . . . . . 11 84 4.3.2.2. Service Authorization Changes . . . . . . . . . . 11 85 4.3.2.3. Dynamic Resource Assignment Changes . . . . . . . 11 86 4.3.2.4. Security Authorization Status Changes . . . . . . 12 87 4.4. Security Vulnerability Management . . . . . . . . . . . . 12 88 4.4.1. Example - NIDS response . . . . . . . . . . . . . . . 12 89 4.4.2. Example - Historical vulnerability analysis . . . . . 13 90 4.4.3. Source Address Validation . . . . . . . . . . . . . . 13 91 4.5. Data Collection . . . . . . . . . . . . . . . . . . . . . 13 92 4.6. Assessment Result Analysis . . . . . . . . . . . . . . . 13 93 4.7. Content Management . . . . . . . . . . . . . . . . . . . 14 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 97 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 8.1. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm- 99 use-cases-00 . . . . . . . . . . . . . . . . . . . . . . 15 100 8.2. -04- to -05- . . . . . . . . . . . . . . . . . . . . . . 16 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 103 9.2. Informative References . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 Our goal with this document is to improve our agreement on which 109 problems we're trying to solve. We need to start with short, simple 110 problem statements and discuss those by email and in person. Once we 111 agree on which problems we're trying to solve, we can move on to 112 propose various solutions and decide which ones to use. 114 This document describes example use cases for endpoint posture 115 assessment for enterprises. It provides a sampling of use cases for 116 securely aggregating configuration and operational data and assessing 117 that data to determine the security posture of individual endpoints, 118 and, in the aggregate, the security posture of an enterprise. 120 These use cases cross many IT security information domains. From 121 these operational use cases, we can derive common concepts, common 122 information expressions, functional capabilities and requirements to 123 guide development of vendor-neutral, interoperable standards for 124 aggregating and assessing data relevant to security posture. 126 Using this standard data, tools can analyze the state of endpoints, 127 user activities and behaviour, and assess the security posture of an 128 organization. Common expression of information should enable 129 interoperability between tools (whether customized, commercial, or 130 freely available), and the ability to automate portions of security 131 processes to gain efficiency, react to new threats in a timely 132 manner, and free up security personnel to work on more advanced 133 problems. 135 The goal is to enable organizations to make informed decisions that 136 support organizational objectives, to enforce policies for hardening 137 systems, to prevent network misuse, to quantify business risk, and to 138 collaborate with partners to identify and mitigate threats. 140 It is expected that use cases for enterprises and for service 141 providers will largely overlap, but there are additional 142 complications for service providers, especially in handling 143 information that crosses administrative domains. 145 The output of endpoint posture assessment is expected to feed into 146 additional processes, such as policy-based enforcement of acceptable 147 state, verification and monitoring of security controls, and 148 compliance to regulatory requirements. 150 2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 3. Endpoint Posture Assessment 158 Endpoint posture assessment involves collecting information about the 159 posture of a given endpoint. This posture information is gathered 160 and then published to appropriate data repositories to make collected 161 information available for further analysis supporting organizational 162 security processes. 164 Endpoint posture assessment typically includes: 166 o Collecting the posture of a given endpoint; 168 o Making that posture available to the enterprise for further 169 analysis and action; and 171 o Assessing that the endpoint's posture is in compliance with 172 enterprise standards and policy. 174 3.1. Example - Departmental Software Policy Compliance 176 In order to meet compliance requirements and ensure that corporate 177 finance information is not revealed improperly, all computers in the 178 finance department of Example Corporation are required to run only 179 software contained on an approved list and to be configured to 180 download and install software patches every night. Each computer is 181 checked to make sure it complies with this policy whenever it 182 connects to the network and at least once a day thereafter. These 183 daily compliance checks assess the posture of each computer and 184 report on its compliance with policy. 186 3.2. Main Success Scenario 188 1. Define a target endpoint to be assessed 190 2. Select acceptable state policies to apply to the defined target 192 3. Identify the endpoint being assessed 193 4. Collect posture attributes from the target 195 5. Communicate target identity and collected posture to external 196 system for evaluation 198 6. Compare collected posture attributes from the target endpoint 199 with expected state values as expressed in acceptable state 200 policies 202 4. Use Cases 204 The use cases defined in this section support assessing endpoint 205 posture in an automated manner as described in Section Section 3. 206 The following sub-sections describe use cases broken out by their 207 corresponding IT decipline. 209 4.1. Asset Management 211 Organizations manage a variety of assets within their enterprise 212 including: endpoints, the hardware they are composed of, installed 213 software, hardware/software licenses used, and configurations. 215 Managing endpoints and the different types of assets that compose 216 them involves initially discovering and characterizing each asset 217 instance, and then identify them in a common way. Characterization 218 may take the form of logical characterization or security 219 characterization, where logical characterization may include business 220 context not otherwise related to security, but which may be used as 221 information in support of decision making later in risk management. 223 Coverage involves understanding what and how many assets are under 224 control. Assessing 80% of the enterprise assets is better than 225 assessing 50% of the enterprise assets. 227 Getting asset details can be comparatively subtle - if an enterprise 228 does not have a precise understanding of its assets, then all 229 acquired data and consequent actions taken based on the data are 230 considered suspect. 232 Assessing assets (managed and unmanaged) requires that we have 233 visibility into the posture of endpoints, the ability to understand 234 the composition and relationships between different assets types, and 235 the ability to properly characterize them at the outset and over 236 time. 238 The following list details some requisite Asset Management 239 capabilities: 241 o Discover assets in the enterprise 243 o Identify and describe assets using a common vocabulary between 244 implementations 246 o For a given endpoint, understand the composition and relationship 247 of its constituent assets 249 o Characterize assets according to security and non-security asset 250 properties 252 o Reconcile asset representations originating from disparate tools 254 o Manage asset information throughout the asset's life cycle 256 4.1.1. Asset Discovery 258 Many network management systems periodically test for the presence of 259 endpoints or interfaces in a network, including discovering endpoints 260 that have suddenly appeared in a network that are not authorized to 261 be part of the network. Other approaches can be used to identify new 262 endpoints as they connect to the network alowing for authentication 263 and authorization to occur dynamically as part of a network access 264 control decision. There are many layers of endpoints, and many 265 standardized information models for determining endpoints in a 266 network. 268 These standardized collections include ARP tables [RFC0826], 269 Interface tables such as the Interfaces MIB (IF-MIB) [RFC2863] or the 270 YANG module ietf-interfaces , Link Layer Discovery tables [RFC2922], 271 DHCP tables (Ref:???), and so on. 273 4.1.2. Asset Identification 275 Identifying assets is critical for managing information provided 276 about and collected from endpoints. It is important to have stable 277 mechanisms for identifying assets over time to allow asset 278 information to be correlated. It is often possible to use 279 standardized and proprietary identification mechanisms provided by 280 hardware and software asset vendors (e.g., CPU identifiers, product 281 tags). In some cases these identifiers may be stable for the life of 282 the hardware component. In other cases (e.g., MAC addresses), the 283 identifier may be mutable within software. Organizationally provided 284 identifiers can also be used to identify assets such as those 285 provided by hardware and software certificates, and configurable 286 identification sources. In other cases it may only be possible to 287 identify an asset by the network addressing information it is 288 currently using, requiring additional context to correlate asset 289 information across multiple network connection sessions. In an 290 enterprise context it is often necessary to use multiple 291 identification viewpoints for an asset to correlate data generated 292 from endpoint, network, and human sources. 294 Some standards focus on identifying the hardware and the system 295 software. For example, the SYSTEM-MIB [RFC1213] contains a 296 description of the endpoint, an authoritative identifier of the type 297 of endpoint assigned by the vendor of the endpoint, an administrative 298 name for the endpoint, plus the endpoint's contact person, the 299 location of the endpoint, system time, and an enumerator that 300 identifies the layer of services provided by the endpoint. The 301 system description includes the vendor, product type, model number, 302 OS version, and networking software version. 304 Similar information is available via the YANG module ietf-system . 305 This module includes data node definitions for system identification, 306 time-of-day management, user management, DNS resolver configuration, 307 and some protocol operations for system management. 309 4.1.3. Endpoint Components and Asset Composition 311 It can be important to characterize the components of an endpoint, 312 including physical and logical components, and the relationships 313 between the components, such as containment of components within 314 other components, or mappings between logical entities and the 315 physical entities used to instantiate them. The information about 316 the physical entities might include manufacturer-assigned serial 317 number, manufacture date, an asset identifier for the component, and 318 so. Logical entities may be defined, and associated with the 319 physical entities using a mapping table. 321 Example standardized data models include the ENTITY-MIB [RFC6933] the 322 Q-BRIDGE-MIB MIB [RFC4363] and the MIB for Virtual Machines 323 Controlled by a Hypervisor . 325 4.1.4. Asset Characterization 327 It is necessary to collect, store, manage, and exchange a variety of 328 different asset characteristics that provide additional context that 329 is useful to support automated and human decision making as part of 330 operational and security processes. Often this information helps to 331 bridge automated and human-oriented processes. In many cases it is 332 impractical or infeasible to collect specific asset details using 333 technical data collection mechanisms. 335 Asset characteristics can take many forms depending on the asset 336 type. 338 For hardware assets the following are often useful characteristics: 340 o Manufacturer 342 o Production version 344 o Hardware characteristics (e.g., memory, storage, network 345 interfaces) 347 o End-of-support dates 349 For software assets the following are often useful characteristics: 351 o Software version 353 o Supported hardware platforms 355 o Metadata identifying: product family, software function, edition, 356 licensing 358 o Other software dependencies 360 o End-of-support dates 362 For managed endpoints, hardware, and software the following are often 363 useful characteristics: 365 o Owning organization 367 o Responsible organizations and individuals (e.g., operations, 368 security, inventory management) 370 o Assigned location for physical devices 372 o Location within network(s) 374 This information is important to provide additional context for 375 supporting management of assets using human and automated processes. 376 For example, it may be possible to automate assessing that an 377 endpoint is out of compliance with organizational configuration 378 guidelines, but additional information is needed to determine who to 379 notify to correct the configuration. Information provided by asset 380 characterization will enable notifications to be sent, trouble 381 tickets to be generated, or specific reports to be generated at a 382 dashboard for a systems administrator. 384 [TODO: Do we need more document characteristics or more examples?.] 386 4.1.5. Asset Resources 388 This type of asset characterization describes the resources of an 389 endpoint, such as installed software, running software, software 390 versions, processes, user sessions, devices (processors, disks, 391 printers, network interfaces, etc.). This might also provides 392 monitoring of performance and error states for the related resources. 394 [TODO: Its not clear if this is asset characterization or data 395 collection. One way to look at asset characterization is that it is 396 metadata that is provided by humans. Endpoint data collection is 397 information provided by machines. The previous list looks like it is 398 better oriented in the "machine" category. Do we want to move these 399 examples to a different sub-section?] 401 An example is the HOST-RESOURCES-MIB [RFC2790] 403 4.1.6. Asset Representation Reconciliation 405 [TODO: We need to describe here how different asset identification 406 viewpoints are reconciled (e.g., endpoint vs. network, passive vs. 407 active] 409 4.1.7. Asset Life Cycle 411 [TODO: What do we want to say here?] 413 4.2. Endpoint Configuration Management 415 Organizations manage a variety of configurations within their 416 enterprise including: endpoints, the hardware they are composed of, 417 installed software, hardware/software licenses used, and 418 configurations. 420 Security configuration management (SCM) deals with the configuration 421 of endpoints, including networking infrastructure devices and 422 computing hosts. Data will include installed hardware and software, 423 its configuration, and its use on the endpoint. 425 [TODO: While some configuration settings might not be considered 426 security relevant, it is not always possible to draw a clear 427 distinction between security and non-security settings (e.g., power 428 saving features). Do we want to make a distinction between security 429 and non-security configuration settings?] 431 The following list details some requisite Configuration Management 432 capabilities: 434 o [todo] 436 4.2.1. Organizing Configuration Metadata 438 Configuration metadata supports tooling helping organizations 439 understand what configuration they should implement, using specific 440 configuration values. 442 Enable data repositories containing machine-represtations of: 444 Configuration scoring: Characterizations of the relative security 445 value of dsscrete configuration settings and specific values 447 Configuration dependencies (e.g., lists of settings, associated 448 software, pre-requisite configurations) 450 Control catalog mappings supporting compliance [todo: in scope?] 452 4.2.2. Publishing Recommended Configuration Posture 454 Provide a mechanism for vendors and organizations to exchange 455 machine-oriented descriptions of recommended configuration setting 456 for software products. Enable organizations to apply recommended 457 settings as expected configuration posture. Enable association of 458 data-driven collection instructions using appropriate formats. 460 4.2.3. Defining Organizationally Expected Configuration Posture 462 Provide a mechanism for organizations to define and exchange expected 463 configuration posture including: authorized software and associated 464 configuration settings. 466 [TODO: Should software installation posture be defined seperately?] 468 4.2.4. Collecting Endpoint Configuration Posture 470 Enable collection and exchange of actual configuration posture 471 including: installed software and values for configured settings. 473 [TODO: Should collecting software installation posture be defined 474 seperately?] 476 4.2.5. Comparing Expected and Actual Configuration Posture 478 Enable evaluation of actual configuration posture against expected 479 configuration posture. Generate a machine-oriented description of 480 conformant and non-conformat posture including software inventory and 481 configuration values. 483 [TODO: Should collecting software installation posture be defined 484 seperately?] 486 [TODO: Examining software version configuration - Example - HOST- 487 RESOURCES-MIB 489 4.2.6. Examining configuration of logical to physical mappings 491 [TODO: not sure what this is? Is it in scope?] 493 Example - ENTITY-MIB 495 4.2.7. Configuring Endpoint Interfaces 497 [TODO: not sure what this is? Is it in scope?] 499 Example - YANG module ietf-interfaces 501 4.3. Endpoint Posture Change Management 503 Organizations manage a variety of changes within their enterprise 504 including: [todo] 506 The following list details some requisite Change Management 507 capabilities: 509 o [todo] 511 4.3.1. Defining and Exchanging Baselines 513 [todo] 515 4.3.2. Detecting Unauthorized Changes 517 [todo] 519 [todo: figure out where these need to go] 521 4.3.2.1. Endpoint Addressing Changes 523 Example - DHCP addressing 525 4.3.2.2. Service Authorization Changes 527 Example - RADIUS network access 529 4.3.2.3. Dynamic Resource Assignment Changes 530 Example - NAT logging 532 4.3.2.4. Security Authorization Status Changes 534 Example - SYSLOG Authorization messages. SYSLOG [RFC5424] includes 535 facilities for security authorization messages. These messages can 536 be used to alert an analysts that an authorization attempt failed, 537 and the analyst might choose to follow up and assess potential 538 attacks on the relevant endpoint. 540 4.4. Security Vulnerability Management 542 Vulnerability management involves identifying the patch level of 543 software installed on the device and the identification of insecure 544 custom code (e.g. web vulnerabilities). All vulnerabilities need to 545 be addressed as part of a comprehensive risk management program, 546 which is a superset of software vulnerabilities. Thus, the 547 capability of assessing non-software vulnerabilities applicable to 548 the system is required. Additionally, it may be necessary to support 549 non-technical assessment of data relating to assets such as aspects 550 related to operational and management controls. 552 policy attribute collection 554 The following list details some requisite Vulnerability Management 555 capabilities: 557 o Collect the state of non-technical controls commonly called 558 administrative controls (i.e. policy, process, procedure) 560 o Collect the state of technical controls including, but not 561 necessarily limited to: 563 * Software inventory (e.g. operating system, applications, 564 patches) 566 * Configuration settings 568 4.4.1. Example - NIDS response 570 1. An organization's Network Intrusion Detection System detects a 571 suspect packet received by an endpoint and sends an alert to an 572 analyst. The analyst looks up the endpoint in the asset inventory 573 database, looks up the configuration policy associated with that 574 endpoint, and initiates an endpoint assessment of installed software 575 and patches on the endpoint to determine if the endpoint is compliant 576 with policy. 578 The analyst reviews the results of the assessment and takes action 579 according to organization policy and procedures. 581 4.4.2. Example - Historical vulnerability analysis 583 When a serious vulnerability or a zero-day attack is discovered, one 584 of the first priorities in any organization is to determine which 585 endpoints may have been affected and assess those endpoints to try to 586 determine whether they were compromised. Checking current endpoint 587 state is not sufficient because an endpoint may have been temporarily 588 compromised due to this vulnerability and then the infection may have 589 removed itself. In fact, the vulnerable software may have been 590 removed or upgraded since the compromise took place. And if the 591 endpoint is still compromised, the malware on the endpoint may cause 592 it to lie about its configuration. In this environment, maintaining 593 historical information about endpoint configuration is essential. 594 Such information can be used to find endpoints that had the 595 vulnerable software installed at some point in time. Those endpoints 596 can be checked for current or past indicators of compromise such as 597 files or behavior linked to a known exploit for this vulnerability. 598 Endpoints found to be vulnerable can be isolated to prevent infection 599 while remediation is done. Endpoints believed to be compromised can 600 be isolated for analysis and to limit the spread of infection. 602 4.4.3. Source Address Validation 604 Source Address Validation Improvement methods were developed to 605 prevent nodes attached to the same IP link from spoofing each other's 606 IP addresses, so as to complement ingress filtering with finer- 607 grained, standardized IP source address validation. The framework 608 document describes and motivates the design of the SAVI methods. 609 Particular SAVI methods are described in other documents. 611 4.5. Data Collection 613 Central to any automated assessment solution is the ability to 614 collect data from, or related to, an endpoint, such as the security 615 state of the endpoint and its constituent assets. 617 So, is data collection a requirement or an architectural concept 618 rather than a use case? 620 QUESTION: Understand more about what is meant by non-software 621 vulnerabilities 623 4.6. Assessment Result Analysis 624 The data collected needs to be analyzed for compliance to a standard 625 stipulated by the enterprise. Analysis methods may vary between 626 enterprises, but commonly take a similar form. 628 The following capabilities support the analysis of assessment 629 results: 631 o Comparing actual state to expected state 633 o Scoring/weighting individual comparison results 635 o Relating specific comparisons to benchmark-level requirements 637 o Relating benchmark-level requirements to one or more control 638 frameworks 640 4.7. Content Management 642 The capabilities required to support risk management state 643 measurement will yield volumes of content. The efficacy of risk 644 management state measurement depends directly on the stability of the 645 driving content, and, subsequently, the ability to change content 646 according to enterprise needs. 648 Capabilities supporting Content Management should provide the ability 649 to create/define or modify content, as well as store and retrieve 650 said content of at least the following types: 652 o Configuration checklists 654 o Assessment rules 656 o Data collection rules and methods 658 o Scoring models 660 o Vulnerability information 662 o Patch information 664 o Asset characterization data and rules 666 Note that the ability to modify content is in direct support of 667 tailoring content for enterprise-specific needs. 669 5. IANA Considerations 671 This memo includes no request to IANA. 673 6. Security Considerations 675 This memo documents, for Informational purposes, use cases for 676 security automation. While it is about security, it does not affect 677 security. 679 7. Acknowledgements 681 The National Institute of Standards and Technology (NIST) and/or the 682 MITRE Corporation have developed specifications under the general 683 term "Security Automation" including languages, protocols, 684 enumerations, and metrics. 686 The authors would like to recognize and thank Adam Montville for his 687 work on early edits of this draft. Additionally, the authors would 688 like to thank Kathleen Moriarty and Stephen Hanna for contributing 689 text to this document. The authors would also like to acknowledge 690 the members of the SACM mailing list for their keen and insightful 691 feedback on the concepts and text within this document. 693 8. Change Log 695 8.1. draft-waltermire-sacm-use-cases-05 to draft-ietf-sacm-use-cases-00 697 o Transitioned from individual I/D to WG I/D based on WG consensus 698 call. 700 o Fixed a number of spelling errors. Thank you Erik! 702 o Added keywords to the front matter. 704 o Removed the terminology section from the draft. Terms have been 705 moved to: draft-dbh-sacm-terminology-00 707 o Removed requirements to be moved into a new I/D. 709 o Extracted the functionality from the examples and made the 710 examples less prominent. 712 o Renamed "Functional Capabilities and Requirements" section to "Use 713 Cases". 715 Reorganized the "Asset Management" sub-section. Added new text 716 throughout. 718 + Renamed a few sub-section headings. 720 + Added text to the "Asset Characterization" sub-section. 722 o Renamed "Security Configuration Management" to "Endpoint 723 Configuration Management". Not sure if the "security" distinction 724 is important. 726 * Added new sections, partially integrated existing content. 728 * Additional text is needed in all of the sub-sections. 730 o Changed "Security Change Management" to "Endpoint Posture Change 731 Management". Added new skeletal outline sections for future 732 updates. 734 8.2. -04- to -05- 736 o Are we including user activities and behavior in the scope of this 737 work? That seems to be layer 8 stuff, appropriate to an IDS/IPS 738 application, not Internet stuff. 740 o I removed the references to what the WG will do because this 741 belongs in the charter, not the (potentially long-lived) use cases 742 document. I removed mention of charter objectives because the 743 charter may go through multiple iterations over time; there is a 744 website for hosting the charter; this document is not the correct 745 place for that discussion. 747 o I moved the discussion of NIST specifications to the 748 acknowledgements section. 750 o Removed the portion of the introduction that describes the 751 chapters; we have a table of concepts, and the existing text 752 seemed redundant. 754 o Removed marketing claims, to focus on technical concepts and 755 technical analysis, that would enable subsequent engineering 756 effort. 758 o Removed (commented out in XML) UC2 and UC3, and eliminated some 759 text that referred to these use cases. 761 o Modified IANA and Security Consideration sections. 763 o Moved Terms to the front, so we can use them in the subsequent 764 text. 766 o Removed the "Key Concepts" section, since the concepts of ORM and 767 IRM were not otherwise mentioned in the document. This would seem 768 more appropriate to the arch doc rather than use cases. 770 o Removed role=editor from David Waltermire's info, since there are 771 three editors on the document. The editor is most important when 772 one person writes the document that represents the work of 773 multiple people. When there are three editors, this role marking 774 isn't necessary. 776 o Modified text to describe that this was specific to enterprises, 777 and that it was expected to overlap with service provider use 778 cases, and described the context of this scoped work within a 779 larger context of policy enforcement, and verification. 781 o The document had asset management, but the charter mentioned 782 asset, change, configuration, and vulnerability management, so I 783 added sections for each of those categories. 785 o Added text to Introduction explaining goal of the document. 787 o Added sections on various example use cases for asset management, 788 config management, change management, and vulnerability 789 management. 791 9. References 793 9.1. Normative References 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, March 1997. 798 9.2. Informative References 800 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 801 converting network protocol addresses to 48.bit Ethernet 802 address for transmission on Ethernet hardware", STD 37, 803 RFC 826, November 1982. 805 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 806 for Network Management of TCP/IP-based internets:MIB-II", 807 STD 17, RFC 1213, March 1991. 809 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 810 2790, March 2000. 812 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 813 MIB", RFC 2863, June 2000. 815 [RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB", RFC 816 2922, September 2000. 818 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed 819 Objects for Bridges with Traffic Classes, Multicast 820 Filtering, and Virtual LAN Extensions", RFC 4363, January 821 2006. 823 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 825 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 826 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 827 2013. 829 Authors' Addresses 831 David Waltermire 832 National Institute of Standards and Technology 833 100 Bureau Drive 834 Gaithersburg, Maryland 20877 835 USA 837 Email: david.waltermire@nist.gov 839 David Harrington 840 Effective Software 841 50 Harding Rd 842 Portsmouth, NH 03801 843 USA 845 Email: ietfdbh@comcast.net