idnits 2.17.1 draft-ietf-sacm-terminology-03.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 (March 21, 2014) is 3687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NCW' is mentioned on line 309, but not defined == Unused Reference: 'I-D.ietf-sacm-use-cases' is defined on line 378, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-sacm-use-cases-06 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 22, 2014 CIS 6 D. Harrington 7 Effective Software 8 N. Cam-Winget 9 Cisco Systems 10 March 21, 2014 12 Terminology for Security Assessment 13 draft-ietf-sacm-terminology-03 15 Abstract 17 This memo documents terminology used in the documents produced by 18 SACM (Security Automation and Continuous Monitoring). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 22, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Pre-defined Terms . . . . . . . . . . . . . . . . . . . . 2 57 2.2. New Terms and Definitions . . . . . . . . . . . . . . . . 6 58 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 8 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 8 64 6.2. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 8 65 6.3. ietf-sacm-terminology-02- to -03- . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Our goal with this document is to improve our agreement on the 74 terminology used in documents produced by the IETF Working Group for 75 Security Automation and Continuous Monitoring. Agreeing on 76 terminology should help reach consensus on which problems we're 77 trying to solve, and propose solutions and decide which ones to use. 79 This document is expected to be a temporary work product, and will 80 probably be incorporated into the architecture or other document. 82 2. Terms and Definitions 84 This section describes terms that have been defined by other RFC's 85 and defines new ones. The predefined terms will reference the RFC 86 and where appropriate will be annotated with the specific context by 87 which the term is used in SACM. 89 2.1. Pre-defined Terms 91 Assessment 93 Defined in [RFC5209] as "the process of collecting posture for a 94 set of capabilities on the endpoint (e.g., host-based firewall) 95 such that the appropriate validators may evaluate the posture 96 against compliance policy." 97 Within this document the use of the term is expanded to support 98 other uses of collected posture (e.g. reporting, network 99 enforcement, vulnerability detection, license management). The 100 phrase "set of capabilities on the endpoint" includes: hardware 101 and software installed on the endpoint." 103 Asset 105 Defined in [RFC4949] as "a system resource that is (a) required to 106 be protected by an information system's security policy, (b) 107 intended to be protected by a countermeasure, or (c) required for 108 a system's mission. 110 Attribute 112 Defined in [RFC5209] as "data element including any requisite 113 meta-data describing an observed, expected, or the operational 114 status of an endpoint feature (e.g., anti-virus software is 115 currently in use)." 117 Endpoint 119 Defined in [RFC5209] as "any computing device that can be 120 connected to a network. Such devices normally are associated with 121 a particular link layer address before joining the network and 122 potentially an IP address once on the network. This includes: 123 laptops, desktops, servers, cell phones, or any device that may 124 have an IP address." 126 To further clarify the [RFC5209] definition, an endpoint is any 127 physical or virtual device that may have a network address. Note 128 that, network infrastructure devices (e.g. switches, routers, 129 firewalls), which fit the definition, are also considered to be 130 endpoints within this document. 132 Based on the previous definition of an asset, an endpoint is a 133 type of asset. 135 Exposure 137 An endpoint misconfiguration or software flaw that allows an 138 attacker a means to compromise an endpoint or network. (derived 139 from CVE exposure definition) 141 From RFC4949: (I) A type of threat action whereby sensitive data 142 is directly released to an unauthorized entity. (See: 143 unauthorized disclosure.) Usage: This type of threat action 144 includes the following subtypes: - "Deliberate Exposure": 146 Intentional release of sensitive data to an unauthorized entity. 147 - "Scavenging": Searching through data residue in a system to gain 148 unauthorized knowledge of sensitive data. - "Human error": / 149 exposure/ Human action or inaction that unintentionally results in 150 an entity gaining unauthorized knowledge of sensitive data. 151 (Compare: corruption, incapacitation.) - "Hardware or software 152 error": /exposure/ System failure that unintentionally results in 153 an entity gaining unauthorized knowledge of sensitive data. 154 (Compare: corruption, incapacitation.) 156 Information Model 158 An information model is an abstract representation of data, their 159 properties, relationships between data and the operations that can 160 be performed on the data. While there is some overlap with a data 161 model, [RFC3444] distinguished an information model as being 162 protocol and implementation neutral whereas a data model would 163 provide such details. 165 Misconfiguration 167 A misconfiguration is a configuration setting that violates 168 organizational security policies, introduces a possible security 169 weakness in a system, or permits or causes unintended behavior 170 that may impact the security posture of a system. (from NIST IR 171 7670) The misalignment of a unit of endpoint configuration posture 172 relative to organizational expectations that is subject to 173 exploitation or misuse. 175 Posture 177 Defined in [RFC5209] as "configuration and/or status of hardware 178 or software on an endpoint as it pertains to an organization's 179 security policy." 181 This term is used within the scope of this document to represent 182 the state information that is collected from an endpoint (e.g. 183 software/hardware inventory, configuration settings). 185 Posture Attributes 187 Defined in [RFC5209] as "attributes describing the configuration 188 or status (posture) of a feature of the endpoint. For example, a 189 Posture Attribute might describe the version of the operating 190 system installed on the system." 192 Within this document this term represents a specific assertion 193 about endpoint state (e.g. configuration setting, installed 194 software, hardware). The phrase "features of the endpoint" refers 195 to installed software or software components. 197 Remediation 199 A remediation is defined as a security-related set of actions that 200 results in a change to a computer's state and may consist of 201 changes motivated by the need to enforce organizational security 202 policies, address discovered vulnerabilities, or correct 203 misconfigurations. (from NIST IR 7670) 205 System Resource 207 Defined in [RFC4949] as "data contained in an information system; 208 or a service provided by a system; or a system capacity, such as 209 processing power or communication bandwidth; or an item of system 210 equipment (i.e., hardware, firmware, software, or documentation); 211 or a facility that houses system operations and equipment. 213 Vulnerability 215 A vulnerability is a state of configuration or defect in a system 216 which allows an unintended and unauthorized party to violate the 217 security or policies of the system. 219 A weakness in an information system, system security procedures, 220 internal controls, or implementation that is subject to 221 exploitation or misuse. This includes flaws in software and 222 processes, and misconfiguration of hardware or software. (derived 223 from NIST definitions) 225 From RFC4949: (I) A flaw or weakness in a system's design, 226 implementation, or operation and management that could be 227 exploited to violate the system's security policy. (See: harden.) 228 Tutorial: A system can have three types of vulnerabilities: (a) 229 vulnerabilities in design or specification; (b) vulnerabilities in 230 implementation; and (c) vulnerabilities in operation and 231 management. Most systems have one or more vulnerabilities, but 232 this does not mean that the systems are too flawed to use. Not 233 every threat results in an attack, and not every attack succeeds. 234 Success depends on the degree of vulnerability, the strength of 235 attacks, and the effectiveness of any countermeasures in use. If 236 the attacks needed to exploit a vulnerability are very difficult 237 to carry out, then the vulnerability may be tolerable. If the 238 perceived benefit to an attacker is small, then even an easily 239 exploited vulnerability may be tolerable. However, if the attacks 240 are well understood and easily made, and if the vulnerable system 241 is employed by a wide range of users, then it is likely that there 242 will be enough motivation for someone to launch an attack. 244 2.2. New Terms and Definitions 246 This section defines terms that are not explictly defined in the 247 IETF. 249 Asset characterization 251 Asset characterization is the process of defining attributes that 252 describe properties of an identified asset. 254 Asset Management 256 The process by which assets are provisioned, updated, maintained 257 and deprecated. 259 Asset Targeting 261 Asset targeting is the use of asset identification and 262 categorization information to drive human-directed, automated 263 decision making for data collection and analysis in support of 264 endpoint posture assessment. 266 Building Block 268 For SACM, a building block is a unit of functionality that may 269 apply to more than one use case and can be supported by different 270 components of an architectural model. 272 Collection Task 274 The process by which posture attributes or values are collected. 276 Collection Guidance 278 [NCW] This is well defined in the Use Cases draft under 2.1.1 279 "Guidance". Suggest to remove it from this draft. 281 Evaluation Task 283 The process by which posture attributes are evaluated. 285 Evaluation Guidance 287 [NCW] This is well defined in the Use Cases draft under 2.1.1 288 "Guidance". Suggest to remove it from this draft. 290 Endpoint Target 292 The endpoint of interest. 294 Endpoint Discovery 296 The process by which an endpoint can be identified. 298 Evaluation Result 300 The resulting value from having evaluated a set of posture 301 attributes. 303 Expected Endpoint State 305 The required state of an endpoint that is to be compared against. 307 Processing Artifact 309 [NCW] This is well defined in the Use Cases draft. Suggest to 310 remove it from this draft. 312 Security Automation 314 The process of which security alerts can be automated through the 315 use of different tools to monitor, evaluate and analyze endpoint 316 and network traffic for the purposes of detecting 317 misconfigurations, misbehaviors or threats. 319 software flaw 321 A weakness in software that is subject to exploitation or misuse. 322 A software flaw can be used by an attacker to gain access to a 323 system or network, and/or materially affect the confidentiality, 324 integrity or availability of information hosted by an endpoint or 325 exchanged over a network. Such a flaw may allow an attacker to 326 execute commands as another user, access data that is contrary to 327 specified access controls, pose as another entity, or to conduct a 328 denial of service. (derived from CVE vulnerability definition) 330 Vulnerability Management 332 The process of mitigating the ability to exploit a vulnerability, 333 via defect removal or protective measures such that exploitation 334 becomes impossible or highly unlikely. (from Chris Inacio) 336 2.3. Requirements Language 338 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 339 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 340 document are to be interpreted as described in RFC 2119 [RFC2119]. 342 3. IANA Considerations 344 This memo includes no request to IANA. 346 4. Security Considerations 348 This memo documents terminology for security automation. While it is 349 about security, it does not affect security. 351 5. Acknowledgements 353 6. Change Log 355 6.1. ietf-sacm-terminology-01- to -02- 357 Added simple list of terms extracted from UC draft -05. It is 358 expected that comments will be received on this list of terms as to 359 whether they should be kept in this document. Those that are kept 360 will be appropriately defined or cited. 362 6.2. ietf-sacm-terminology-01- to -02- 364 Added Vulnerability, Vulnerability Management, xposure, 365 Misconfiguration, and Software flaw. 367 6.3. ietf-sacm-terminology-02- to -03- 369 Removed Section 2.1. Cleaned up some editing nits; broke terms into 370 2 sections (predefined and newly defined terms). Added some of the 371 relevant terms per the proposed list discussed in the IETF 89 372 meeting. 374 7. References 376 7.1. Normative References 378 [I-D.ietf-sacm-use-cases] 379 Waltermire, D. and D. Harrington, "Endpoint Security 380 Posture Assessment - Enterprise Use Cases", draft-ietf- 381 sacm-use-cases-06 (work in progress), March 2014. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 7.2. Informative References 388 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 389 Information Models and Data Models", RFC 3444, January 390 2003. 392 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 393 4949, August 2007. 395 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 396 Tardo, "Network Endpoint Assessment (NEA): Overview and 397 Requirements", RFC 5209, June 2008. 399 Authors' Addresses 401 David Waltermire 402 National Institute of Standards and Technology 403 100 Bureau Drive 404 Gaithersburg, Maryland 20877 405 USA 407 Email: david.waltermire@nist.gov 409 Adam W. Montville 410 Center for Internet Security 411 31 Tech Valley Drive 412 East Greenbush, New York 12061 413 USA 415 Email: adam.montville@cisecurity.org 417 David Harrington 418 Effective Software 419 50 Harding Rd 420 Portsmouth, NH 03801 421 USA 423 Email: ietfdbh@comcast.net 424 Nancy Cam-Winget 425 Cisco Systems 426 3550 Cisco Way 427 San Jose, CA 95134 428 US 430 Email: ncamwing@cisco.com