idnits 2.17.1 draft-ietf-sacm-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2013) is 3839 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: April 22, 2014 TW 6 D. Harrington 7 Effective Software 8 October 19, 2013 10 Terminology for Security Assessment 11 draft-ietf-sacm-terminology-01 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 April 22, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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. Requirements Language . . . . . . . . . . . . . . . . . . 6 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 6 60 6.2. -00- draft . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Our goal with this document is to improve our agreement on the 69 terminology used in documents produced by the IETF Working Group for 70 Security Automation and Continuous Monitoring. Agreeing on 71 terminology should help reach consensus on which problems we're 72 trying to solve, and propose solutions and decide which ones to use. 74 This document is expected to be temorary work product, and will 75 probably be incorporated into the architecture or other document. 77 2. Terms and Definitions 79 assessment 81 Defined in [RFC5209] as "the process of collecting posture for a 82 set of capabilities on the endpoint (e.g., host-based firewall) 83 such that the appropriate validators may evaluate the posture 84 against compliance policy." 86 Within this document the use of the term is expanded to support 87 other uses of collected posture (e.g. reporting, network 88 enforcement, vulnerability detection, license management). The 89 phrase "set of capabilities on the endpoint" includes: hardware 90 and software installed on the endpoint." 92 asset 94 Defined in [RFC4949] as "a system resource that is (a) required to 95 be protected by an information system's security policy, (b) 96 intended to be protected by a countermeasure, or (c) required for 97 a system's mission. 99 asset characterization 101 Asset characterization is the process of defining attributes that 102 describe properties of an identified asset. 104 asset targeting 106 Asset targeting is the use of asset identification and 107 categorization information to drive human-directed, automated 108 decision making for data collection and analysis in support of 109 endpoint posture assessment. 111 attribute 113 Defined in [RFC5209] as "data element including any requisite 114 meta-data describing an observed, expected, or the operational 115 status of an endpoint feature (e.g., anti-virus software is 116 currently in use)." 118 endpoint 120 Defined in [RFC5209] as "any computing device that can be 121 connected to a network. Such devices normally are associated with 122 a particular link layer address before joining the network and 123 potentially an IP address once on the network. This includes: 124 laptops, desktops, servers, cell phones, or any device that may 125 have an IP address." 127 Network infrastructure devices (e.g. switches, routers, 128 firewalls), which fit the definition, are also considered to be 129 endpoints within this document. 131 Based on the previous definition of an asset, an endpoint is a 132 type of asset. 134 Exposure 136 An endpoint misconfiguration or software flaw that allows access 137 to information or capabilities that can be used by an attacker as 138 a means to compromise an endpoint or network. (derived from CVE 139 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": 145 Intentional release of sensitive data to an unauthorized entity. 146 - "Scavenging": Searching through data residue in a system to gain 147 unauthorized knowledge of sensitive data. - "Human error": / 148 exposure/ Human action or inaction that unintentionally results in 149 an entity gaining unauthorized knowledge of sensitive data. 150 (Compare: corruption, incapacitation.) - "Hardware or software 151 error": /exposure/ System failure that unintentionally results in 152 an entity gaining unauthorized knowledge of sensitive data. 153 (Compare: corruption, incapacitation.) 155 Misconfiguration 157 A misconfiguration is a configuration setting that violates 158 organizational security policies, introduces a possible security 159 weakness in a system, or permits or causes unintended behavior 160 that may impact the security posture of a system. (from NIST IR 161 7670) The misalignment of a unit of endpoint configuration posture 162 relative to organizational expectations that is subject to 163 exploitation or misuse. 165 posture 167 Defined in [RFC5209] as "configuration and/or status of hardware 168 or software on an endpoint as it pertains to an organization's 169 security policy." 171 This term is used within the scope of this document to represent 172 the state information that is collected from an endpoint (e.g. 173 software/hardware inventory, configuration settings). 175 posture attributes 177 Defined in [RFC5209] as "attributes describing the configuration 178 or status (posture) of a feature of the endpoint. For example, a 179 Posture Attribute might describe the version of the operating 180 system installed on the system." 182 Within this document this term represents a specific assertion 183 about endpoint state (e.g. configuration setting, installed 184 software, hardware). The phrase "features of the endpoint" refers 185 to installed software or software components. 187 Remediation 189 A remediation is defined as a security-related set of actions that 190 results in a change to a computer's state and may consist of 191 changes motivated by the need to enforce organizational security 192 policies, address discovered vulnerabilities, or correct 193 misconfigurations. (from NIST IR 7670) 195 software flaw 197 A weakness in software that is subject to exploitation or misuse. 198 A software flaw can be used by an attacker to gain access to a 199 system or network, and/or materially affect the confidentiality, 200 integrity or availability of information hosted by an endpoint or 201 exchanged over a network. Such a flaw may allow an attacker to 202 execute commands as another user, access data that is contrary to 203 specified access controls, pose as another entity, or to conduct a 204 denial of service. (derived from CVE vulnerability definition) 206 system resource 208 Defined in [RFC4949] as "data contained in an information system; 209 or a service provided by a system; or a system capacity, such as 210 processing power or communication bandwidth; or an item of system 211 equipment (i.e., hardware, firmware, software, or documentation); 212 or a facility that houses system operations and equipment. 214 Vulnerability 216 A vulnerability is a state of configuration or defect in a system 217 which allows an unintended and unauthorized party to violate the 218 security or policies of the system. 220 A weakness in an information system, system security procedures, 221 internal controls, or implementation that is subject to 222 exploitation or misuse. This includes flaws in software and 223 processes, and misconfiguration of hardware or software. (derived 224 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 Vulnerability Management 246 The process of mitigating the ability to exploit a vulnerability, 247 via defect removal or protective measures such that exploitation 248 becomes impossible or highly unlikely. (from Chris Inacio) 250 2.1. Requirements Language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in RFC 2119 [RFC2119]. 256 3. IANA Considerations 258 This memo includes no request to IANA. 260 4. Security Considerations 262 This memo documents terminology for security automation. While it is 263 about security, it does not affect security. 265 5. Acknowledgements 267 6. Change Log 269 6.1. ietf-sacm-terminology-01- to -02- 271 Added Vulnerability, Vulnerability Management, xposure, 272 Misconfiguration, and Software flaw. 274 6.2. -00- draft 276 7. References 278 7.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 7.2. Informative References 285 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 286 4949, August 2007. 288 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 289 Tardo, "Network Endpoint Assessment (NEA): Overview and 290 Requirements", RFC 5209, June 2008. 292 Authors' Addresses 294 David Waltermire 295 National Institute of Standards and Technology 296 100 Bureau Drive 297 Gaithersburg, Maryland 20877 298 USA 300 Email: david.waltermire@nist.gov 302 Adam W. Montville 303 Tripwire, Inc. 304 101 SW Main Street, Suite 1500 305 Portland, Oregon 97204 306 USA 308 Email: amontville@tripwire.com 310 David Harrington 311 Effective Software 312 50 Harding Rd 313 Portsmouth, NH 03801 314 USA 316 Email: ietfdbh@comcast.net