idnits 2.17.1 draft-ietf-sacm-terminology-02.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 (January 13, 2014) is 3756 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 A. Montville 5 Expires: July 17, 2014 CIS 6 D. Harrington 7 Effective Software 8 January 13, 2014 10 Terminology for Security Assessment 11 draft-ietf-sacm-terminology-02 13 Abstract 15 This memo documents terminology used in the documents produced by the 16 SACM WG (Security Automation and Continuous Monitoring). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 17, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Terms Extracted from UC -05 Draft . . . . . . . . . . . . 2 55 2.2. Terms from -01 Terminology Draft . . . . . . . . . . . . 12 56 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 15 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 60 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 61 6.1. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 16 62 6.2. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 16 63 6.3. -00- draft . . . . . . . . . . . . . . . . . . . . . . . 16 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 66 7.2. Informative References . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 Our goal with this document is to improve our agreement on the 72 terminology used in documents produced by the IETF Working Group for 73 Security Automation and Continuous Monitoring. Agreeing on 74 terminology should help reach consensus on which problems we're 75 trying to solve, and propose solutions and decide which ones to use. 77 This document is expected to be temorary work product, and will 78 probably be incorporated into the architecture or other document. 80 2. Terms and Definitions 82 2.1. Terms Extracted from UC -05 Draft 84 The following terms were extracted from: http://tools.ietf.org/html/ 85 draft-ietf-sacm-use-cases-05 87 acquisition method 89 actor 91 actual endpoint state 93 ad hoc collection task 95 ad hoc evaluation task 97 applicable data collection content 98 application 100 appropriate actor 102 appropriate application 104 appropriate operator 106 approved configuration 108 approved endpoint configuration 110 approved hardware list 112 approved software list 114 artifact 116 artifact age 118 assessment criteria 120 assessment cycle 122 assessment planning 124 assessment subset 126 assessment trigger 128 asset characteristics 130 asset management 132 asset management data 134 asset management system 136 asynchronous compliance assessment 138 asynchronous vulnerability assessment 140 attack condition 142 attribute 144 automatable configuration guide 145 automatable configuration guide definition 147 automatable configuration guide publication 149 automated checklist verification 151 automated endpoint compliance monitoring 153 baseline 155 baseline compliance 157 building block 159 business logic 161 candidate endpoint target 163 capability 165 change detection 167 change event 169 change event monitoring 171 change filter 173 change management 175 change management program 177 checklist 179 checklist identification 181 checklist verification 183 client endpoint 185 collected posture attribute value 187 collection content acquisition 189 collection process 191 collection request 192 collection task 194 complete assessment cycle 196 compliance 198 compliance level 200 compliance monitoring 202 computing platform endpoint 204 configuration baseline 206 configuration data 208 configuration item 210 configuration item change 212 configuration management 214 content 216 content change detection 218 content data store 220 content definition 222 content instance 224 content publication 226 content query 228 content repository 230 content retrieval 232 criteria 234 critical vulnerability 236 current sign of malware infection 238 data analysis 239 data collection 241 data collection content 243 data collection path 245 data store query 247 database mining 249 define content 251 desired state 253 desired state identification 255 detection timeliness 257 deviation notification 259 discovery 261 endpoint 263 endpoint attribute 265 endpoint compliance monitoring 267 endpoint component inventory 269 endpoint discovery 271 endpoint event 273 endpoint identification 275 endpoint information analysis and reporting 277 endpoint metadata 279 endpoint posture 281 endpoint posture assessment 283 endpoint posture attribute 285 endpoint posture attribute value 286 endpoint posture attribute value collection 288 endpoint posture change monitoring 290 endpoint posture compliance 292 endpoint posture deviation 294 endpoint posture deviation detection 296 endpoint posture monitoring 298 endpoint state 300 endpoint target 302 endpoint target identification 304 endpoint type 306 enterprise 308 enterprise function 310 enterprise function definition 312 enterprise policy 314 enterprise standards 316 evaluating data 318 evaluation content acquisition 320 evaluation task 322 evaulation result 324 event-driven notification 326 expected function 328 expected state 330 expected state criteria 332 function 333 functional capability 335 immediate detection 337 indicator of compromise 339 industry group 341 information expression 343 information model 345 malicious activity 347 malicious configuration item 349 malicious hardware 351 malicious software 353 malware infection 355 manual endpoint compliance monitoring 357 mobile endpoint 359 monitoring 361 network access control 363 network access control decision 365 network event 367 network infrastructure endpoint 369 network location 371 network-connection-driven data collection 373 new vulnerability 375 on-demand detection 377 ongoing change-event monitoring 379 ongoing-event-driven endpoint-posture-change monitoring 380 ongoing-event-driven monitoring 382 operational data 384 operations 386 organizational policy 388 organizational policy compliance 390 organizational security posture 392 patch 394 patch change 396 patch management 398 performance condition 400 periodic collection request 402 periodic data collection 404 policy 406 posture aspect 408 posture aspect change 410 posture attribute 412 posture attribute evaluation 414 posture attribute identification 416 posture attribute value 418 posture attribute value collection 420 posture attribute value query 422 posture change 424 posture deviation 426 posture deviation detection 427 posture evaluation 429 previously collected information 431 previously collected posture attribute value 433 previously collected posture attribute value analysis 435 process 437 public content repository 439 publication metadata 441 publication operations 443 publish content 445 query 447 regulatory authority 449 repository 451 repository content identification 453 repository content retrieval 455 result 457 result set 459 retrieve content 461 risk 463 risk management 465 risk management program 467 scheduled task 469 search criteria 471 secure configuration baseline 473 security administrator 474 security automation 476 security posture 478 security process 480 server endpoint 482 significant endpoint event 484 significant event 486 signs of infection 488 state criteria 490 supporting content 492 target 494 target endpoint 496 task 498 trigger 500 unauthorized configuration item 502 unauthorized hardware 504 unauthorized software 506 vulnerability 508 vulnerability artifact 510 vulnerability artifact age 512 vulnerability condition 514 vulnerability exposure 516 vulnerability management 518 vulnerability mitigation 520 vulnerability remediation 521 whole assessment 523 workflow trigger 525 2.2. Terms from -01 Terminology Draft 527 assessment 529 Defined in [RFC5209] as "the process of collecting posture for a 530 set of capabilities on the endpoint (e.g., host-based firewall) 531 such that the appropriate validators may evaluate the posture 532 against compliance policy." 534 Within this document the use of the term is expanded to support 535 other uses of collected posture (e.g. reporting, network 536 enforcement, vulnerability detection, license management). The 537 phrase "set of capabilities on the endpoint" includes: hardware 538 and software installed on the endpoint." 540 asset 542 Defined in [RFC4949] as "a system resource that is (a) required to 543 be protected by an information system's security policy, (b) 544 intended to be protected by a countermeasure, or (c) required for 545 a system's mission. 547 asset characterization 549 Asset characterization is the process of defining attributes that 550 describe properties of an identified asset. 552 asset targeting 554 Asset targeting is the use of asset identification and 555 categorization information to drive human-directed, automated 556 decision making for data collection and analysis in support of 557 endpoint posture assessment. 559 attribute 561 Defined in [RFC5209] as "data element including any requisite 562 meta-data describing an observed, expected, or the operational 563 status of an endpoint feature (e.g., anti-virus software is 564 currently in use)." 566 endpoint 567 Defined in [RFC5209] as "any computing device that can be 568 connected to a network. Such devices normally are associated with 569 a particular link layer address before joining the network and 570 potentially an IP address once on the network. This includes: 571 laptops, desktops, servers, cell phones, or any device that may 572 have an IP address." 574 Network infrastructure devices (e.g. switches, routers, 575 firewalls), which fit the definition, are also considered to be 576 endpoints within this document. 578 Based on the previous definition of an asset, an endpoint is a 579 type of asset. 581 Exposure 583 An endpoint misconfiguration or software flaw that allows access 584 to information or capabilities that can be used by an attacker as 585 a means to compromise an endpoint or network. (derived from CVE 586 exposure definition) 588 From RFC4949: (I) A type of threat action whereby sensitive data 589 is directly released to an unauthorized entity. (See: 590 unauthorized disclosure.) Usage: This type of threat action 591 includes the following subtypes: - "Deliberate Exposure": 592 Intentional release of sensitive data to an unauthorized entity. 593 - "Scavenging": Searching through data residue in a system to gain 594 unauthorized knowledge of sensitive data. - "Human error": / 595 exposure/ Human action or inaction that unintentionally results in 596 an entity gaining unauthorized knowledge of sensitive data. 597 (Compare: corruption, incapacitation.) - "Hardware or software 598 error": /exposure/ System failure that unintentionally results in 599 an entity gaining unauthorized knowledge of sensitive data. 600 (Compare: corruption, incapacitation.) 602 Misconfiguration 604 A misconfiguration is a configuration setting that violates 605 organizational security policies, introduces a possible security 606 weakness in a system, or permits or causes unintended behavior 607 that may impact the security posture of a system. (from NIST IR 608 7670) The misalignment of a unit of endpoint configuration posture 609 relative to organizational expectations that is subject to 610 exploitation or misuse. 612 posture 613 Defined in [RFC5209] as "configuration and/or status of hardware 614 or software on an endpoint as it pertains to an organization's 615 security policy." 617 This term is used within the scope of this document to represent 618 the state information that is collected from an endpoint (e.g. 619 software/hardware inventory, configuration settings). 621 posture attributes 623 Defined in [RFC5209] as "attributes describing the configuration 624 or status (posture) of a feature of the endpoint. For example, a 625 Posture Attribute might describe the version of the operating 626 system installed on the system." 628 Within this document this term represents a specific assertion 629 about endpoint state (e.g. configuration setting, installed 630 software, hardware). The phrase "features of the endpoint" refers 631 to installed software or software components. 633 Remediation 635 A remediation is defined as a security-related set of actions that 636 results in a change to a computer's state and may consist of 637 changes motivated by the need to enforce organizational security 638 policies, address discovered vulnerabilities, or correct 639 misconfigurations. (from NIST IR 7670) 641 software flaw 643 A weakness in software that is subject to exploitation or misuse. 644 A software flaw can be used by an attacker to gain access to a 645 system or network, and/or materially affect the confidentiality, 646 integrity or availability of information hosted by an endpoint or 647 exchanged over a network. Such a flaw may allow an attacker to 648 execute commands as another user, access data that is contrary to 649 specified access controls, pose as another entity, or to conduct a 650 denial of service. (derived from CVE vulnerability definition) 652 system resource 654 Defined in [RFC4949] as "data contained in an information system; 655 or a service provided by a system; or a system capacity, such as 656 processing power or communication bandwidth; or an item of system 657 equipment (i.e., hardware, firmware, software, or documentation); 658 or a facility that houses system operations and equipment. 660 Vulnerability 661 A vulnerability is a state of configuration or defect in a system 662 which allows an unintended and unauthorized party to violate the 663 security or policies of the system. 665 A weakness in an information system, system security procedures, 666 internal controls, or implementation that is subject to 667 exploitation or misuse. This includes flaws in software and 668 processes, and misconfiguration of hardware or software. (derived 669 from NIST definitions) 671 From RFC4949: (I) A flaw or weakness in a system's design, 672 implementation, or operation and management that could be 673 exploited to violate the system's security policy. (See: harden.) 674 Tutorial: A system can have three types of vulnerabilities: (a) 675 vulnerabilities in design or specification; (b) vulnerabilities in 676 implementation; and (c) vulnerabilities in operation and 677 management. Most systems have one or more vulnerabilities, but 678 this does not mean that the systems are too flawed to use. Not 679 every threat results in an attack, and not every attack succeeds. 680 Success depends on the degree of vulnerability, the strength of 681 attacks, and the effectiveness of any countermeasures in use. If 682 the attacks needed to exploit a vulnerability are very difficult 683 to carry out, then the vulnerability may be tolerable. If the 684 perceived benefit to an attacker is small, then even an easily 685 exploited vulnerability may be tolerable. However, if the attacks 686 are well understood and easily made, and if the vulnerable system 687 is employed by a wide range of users, then it is likely that there 688 will be enough motivation for someone to launch an attack. 690 Vulnerability Management 692 The process of mitigating the ability to exploit a vulnerability, 693 via defect removal or protective measures such that exploitation 694 becomes impossible or highly unlikely. (from Chris Inacio) 696 2.3. Requirements Language 698 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 699 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 700 document are to be interpreted as described in RFC 2119 [RFC2119]. 702 3. IANA Considerations 704 This memo includes no request to IANA. 706 4. Security Considerations 708 This memo documents terminology for security automation. While it is 709 about security, it does not affect security. 711 5. Acknowledgements 713 6. Change Log 715 6.1. ietf-sacm-terminology-01- to -02- 717 Added simple list of terms extracted from UC draft -05. It is 718 expected that comments will be received on this list of terms as to 719 whether they should be kept in this document. Those that are kept 720 will be appropriately defined or cited. 722 6.2. ietf-sacm-terminology-01- to -02- 724 Added Vulnerability, Vulnerability Management, xposure, 725 Misconfiguration, and Software flaw. 727 6.3. -00- draft 729 o 731 7. References 733 7.1. Normative References 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, March 1997. 738 7.2. Informative References 740 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 741 4949, August 2007. 743 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 744 Tardo, "Network Endpoint Assessment (NEA): Overview and 745 Requirements", RFC 5209, June 2008. 747 Authors' Addresses 748 David Waltermire 749 National Institute of Standards and Technology 750 100 Bureau Drive 751 Gaithersburg, Maryland 20877 752 USA 754 Email: david.waltermire@nist.gov 756 Adam W. Montville 757 Center for Internet Security 758 31 Tech Valley Drive 759 East Greenbush, New York 12061 760 USA 762 Email: adam.montville@cisecurity.org 764 David Harrington 765 Effective Software 766 50 Harding Rd 767 Portsmouth, NH 03801 768 USA 770 Email: ietfdbh@comcast.net