idnits 2.17.1 draft-ietf-sacm-terminology-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 15, 2014) is 3535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sacm-use-cases' is defined on line 338, 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 (~~), 4 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: February 16, 2015 Tripwire 6 D. Harrington 7 Effective Software 8 N. Cam-Winget 9 Cisco Systems 10 August 15, 2014 12 Terminology for Security Assessment 13 draft-ietf-sacm-terminology-05 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 February 16, 2015. 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 . . . . . . . . . . . . . . . . 4 58 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 7 64 6.2. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 7 65 6.3. ietf-sacm-terminology-02- to -03- . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 Information Model 137 An information model is an abstract representation of data, their 138 properties, relationships between data and the operations that can 139 be performed on the data. While there is some overlap with a data 140 model, [RFC3444] distinguished an information model as being 141 protocol and implementation neutral whereas a data model would 142 provide such details. 144 Posture 145 Defined in [RFC5209] as "configuration and/or status of hardware 146 or software on an endpoint as it pertains to an organization's 147 security policy." 149 This term is used within the scope of this document to represent 150 the state information that is collected from an endpoint (e.g. 151 software/hardware inventory, configuration settings). The state 152 information may constitute one to many Posture Attributes. 154 Posture Attributes 156 Defined in [RFC5209] as "attributes describing the configuration 157 or status (posture) of a feature of the endpoint. A Posture 158 Attribute represents a single property of an observed state. For 159 example, a Posture Attribute might describe the version of the 160 operating system installed on the system." 162 Within this document this term represents a specific assertion 163 about endpoint state (e.g. configuration setting, installed 164 software, hardware). The phrase "features of the endpoint" refers 165 to installed software or software components. 167 System Resource 169 Defined in [RFC4949] as "data contained in an information system; 170 or a service provided by a system; or a system capacity, such as 171 processing power or communication bandwidth; or an item of system 172 equipment (i.e., hardware, firmware, software, or documentation); 173 or a facility that houses system operations and equipment. 175 2.2. New Terms and Definitions 177 This section defines terms that are not explictly defined in the 178 IETF. 180 Asset characterization 182 Asset characterization is the process of defining attributes that 183 describe properties of an identified asset. 185 Asset Management 187 The process by which assets are provisioned, updated, maintained 188 and deprecated. 190 Asset Targeting 191 Asset targeting is the use of asset identification and 192 categorization information to drive human-directed, automated 193 decision making for data collection and analysis in support of 194 endpoint posture assessment. 196 Broker 198 An entity providing and/or connecting services on the behalf of 199 other architectural components. Within the SACM Architecture, for 200 example, a broker may provide authorization services and find, 201 upon request, entities providing requested services. 203 Building Block 205 For SACM, a building block is a unit of functionality that may 206 apply to more than one use case and can be supported by different 207 components of an architectural model. 209 Capability 211 The extent of an architectural component's ability. For example, 212 a Posture Information Provider may only provide endpoint 213 management data, and then only a subset of that data. 215 Client 217 An architectural component receiving services from another 218 architectural component. 220 Collection Task 222 The process by which posture attributes or values are collected. 224 Consumer 226 An architectural component receiving information from another 227 architectrual component. 229 Evaluation Task 231 The process by which posture attributes are evaluated. 233 Endpoint Target 235 The endpoint of interest. 237 Endpoint Discovery 238 The process by which an endpoint can be identified. 240 Evaluation Result 242 The resulting value from having evaluated a set of posture 243 attributes. 245 Expected Endpoint State 247 The required state of an endpoint that is to be compared against. 249 Function 251 A behavioral aspect of a particular architectural component, which 252 belies that component's purpose. For example, the Management 253 Plane can provide a brokering function to other SACM architectrual 254 components. 256 Management Plane (TBD per list; was "Control Plane") 258 Architectural component providing common functions to all SACM 259 participants, including authentication, authorization, 260 capabilities mappings, and the like. 262 Provider 264 An architectural component providing information to another 265 architectrual component. 267 Proxy 269 An architectural component providing functions, information, or 270 services on behalf of another component, which is not directly 271 participating in the architecture. 273 Repository 275 An architectural component intended to store information of a 276 particular kind. A single repository may provide the functions of 277 more than one repository type (i.e. configuration baseline 278 repository, assessment results repository, etc.) 280 Role 282 A label representing a collection of functions provided by a 283 particular architectural component. 285 Security Automation 286 The process of which security alerts can be automated through the 287 use of different tools to monitor, evaluate and analyze endpoint 288 and network traffic for the purposes of detecting 289 misconfigurations, misbehaviors or threats. 291 Supplicant 293 The entity seeking to be authenticated by the Management Plane for 294 the purpose of participating in the SACM architecture. 296 2.3. Requirements Language 298 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 299 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 300 document are to be interpreted as described in RFC 2119 [RFC2119]. 302 3. IANA Considerations 304 This memo includes no request to IANA. 306 4. Security Considerations 308 This memo documents terminology for security automation. While it is 309 about security, it does not affect security. 311 5. Acknowledgements 313 6. Change Log 315 6.1. ietf-sacm-terminology-01- to -02- 317 Added simple list of terms extracted from UC draft -05. It is 318 expected that comments will be received on this list of terms as to 319 whether they should be kept in this document. Those that are kept 320 will be appropriately defined or cited. 322 6.2. ietf-sacm-terminology-01- to -02- 324 Added Vulnerability, Vulnerability Management, xposure, 325 Misconfiguration, and Software flaw. 327 6.3. ietf-sacm-terminology-02- to -03- 329 Removed Section 2.1. Cleaned up some editing nits; broke terms into 330 2 sections (predefined and newly defined terms). Added some of the 331 relevant terms per the proposed list discussed in the IETF 89 332 meeting. 334 7. References 336 7.1. Normative References 338 [I-D.ietf-sacm-use-cases] 339 Waltermire, D. and D. Harrington, "Endpoint Security 340 Posture Assessment - Enterprise Use Cases", draft-ietf- 341 sacm-use-cases-06 (work in progress), March 2014. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 7.2. Informative References 348 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 349 Information Models and Data Models", RFC 3444, January 350 2003. 352 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 353 4949, August 2007. 355 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 356 Tardo, "Network Endpoint Assessment (NEA): Overview and 357 Requirements", RFC 5209, June 2008. 359 Authors' Addresses 361 David Waltermire 362 National Institute of Standards and Technology 363 100 Bureau Drive 364 Gaithersburg, Maryland 20877 365 USA 367 Email: david.waltermire@nist.gov 369 Adam W. Montville 370 Tripwire 371 101 SW Main Street, 15th floor 372 Portland, Oregon 97204 373 USA 375 Email: adam.w.montville@gmail.com 376 David Harrington 377 Effective Software 378 50 Harding Rd 379 Portsmouth, NH 03801 380 USA 382 Email: ietfdbh@comcast.net 384 Nancy Cam-Winget 385 Cisco Systems 386 3550 Cisco Way 387 San Jose, CA 95134 388 US 390 Email: ncamwing@cisco.com