idnits 2.17.1 draft-ietf-sacm-terminology-06.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 date (February 11, 2015) is 3361 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 15, 2015 CIS 6 D. Harrington 7 Effective Software 8 N. Cam-Winget 9 Cisco Systems 10 J. Lu 11 Oracle Corporation 12 B. Ford 13 Lancope 14 M. Kaeo 15 Double Shot Security 16 February 11, 2015 18 Terminology for Security Assessment 19 draft-ietf-sacm-terminology-06 21 Abstract 23 This memo documents terminology used in the documents produced by 24 SACM (Security Automation and Continuous Monitoring). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 15, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 7 67 6.2. ietf-sacm-terminology-01- to -02- . . . . . . . . . . . . 7 68 6.3. ietf-sacm-terminology-02- to -03- . . . . . . . . . . . . 7 69 6.4. ietf-sacm-terminology-03 to -04- . . . . . . . . . . . . 7 70 6.5. ietf-sacm-terminology-04 to -05- . . . . . . . . . . . . 8 71 6.6. ietf-sacm-terminology-05 to -06- . . . . . . . . . . . . 8 72 7. Informative References . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Our goal with this document is to improve our agreement on the 78 terminology used in documents produced by the IETF Working Group for 79 Security Automation and Continuous Monitoring. Agreeing on 80 terminology should help reach consensus on which problems we're 81 trying to solve, and propose solutions and decide which ones to use. 83 2. Terms and Definitions 85 This section describes terms that have been defined by other RFC's 86 and defines new ones. The predefined terms will reference the RFC 87 and where appropriate will be annotated with the specific context by 88 which the term is used in SACM. 90 Assessment 92 Defined in [RFC5209] as "the process of collecting posture for a 93 set of capabilities on the endpoint (e.g., host-based firewall) 94 such that the appropriate validators may evaluate the posture 95 against compliance policy." 96 Within this document the use of the term is expanded to support 97 other uses of collected posture (e.g. reporting, network 98 enforcement, vulnerability detection, license management). The 99 phrase "set of capabilities on the endpoint" includes: hardware 100 and software installed on the endpoint." 102 Asset 104 Defined in [RFC4949] as "a system resource that is (a) required to 105 be protected by an information system's security policy, (b) 106 intended to be protected by a countermeasure, or (c) required for 107 a system's mission. 109 Asset characterization 111 Asset characterization is the process of defining attributes that 112 describe properties of an identified asset. 114 Asset Management 116 The process by which assets are provisioned, updated, maintained 117 and deprecated. 119 Asset Targeting 121 Asset targeting is the use of asset identification and 122 categorization information to drive human-directed, automated 123 decision making for data collection and analysis in support of 124 endpoint posture assessment. 126 Attribute 128 Defined in [RFC5209] as "data element including any requisite 129 meta-data describing an observed, expected, or the operational 130 status of an endpoint feature (e.g., anti-virus software is 131 currently in use)." 133 Broker 135 An entity providing and/or connecting services on the behalf of 136 other architectural components. Within the SACM Architecture, for 137 example, a broker may provide authorization services and find, 138 upon request, entities providing requested services. 140 Building Block 141 For SACM, a building block is a unit of functionality that may 142 apply to more than one use case and can be supported by different 143 components of an architectural model. 145 Capability 147 The extent of an architectural component's ability. For example, 148 a Posture Information Provider may only provide endpoint 149 management data, and then only a subset of that data. 151 Client 153 An architectural component receiving services from another 154 architectural component. 156 Collection Task 158 The process by which posture attributes or values are collected. 160 Consumer 162 An architectural component receiving information from another 163 architectrual component. 165 Endpoint 167 Defined in [RFC5209] as "any computing device that can be 168 connected to a network. Such devices normally are associated with 169 a particular link layer address before joining the network and 170 potentially an IP address once on the network. This includes: 171 laptops, desktops, servers, cell phones, or any device that may 172 have an IP address." 174 To further clarify the [RFC5209] definition, an endpoint is any 175 physical or virtual device that may have a network address. Note 176 that, network infrastructure devices (e.g. switches, routers, 177 firewalls), which fit the definition, are also considered to be 178 endpoints within this document. 180 Based on the previous definition of an asset, an endpoint is a 181 type of asset. 183 Evaluation Task 185 The process by which posture attributes are evaluated. 187 Endpoint Target 188 The endpoint of interest. 190 Endpoint Discovery 192 The process by which an endpoint can be identified. 194 Evaluation Result 196 The resulting value from having evaluated a set of posture 197 attributes. 199 Expected Endpoint State 201 The required state of an endpoint that is to be compared against. 203 Function 205 A behavioral aspect of a particular architectural component, which 206 belies that component's purpose. For example, the Management 207 Plane can provide a brokering function to other SACM architectrual 208 components. 210 Information Model 212 An information model is an abstract representation of data, their 213 properties, relationships between data and the operations that can 214 be performed on the data. While there is some overlap with a data 215 model, [RFC3444] distinguished an information model as being 216 protocol and implementation neutral whereas a data model would 217 provide such details. 219 Management Plane (TBD per list; was "Control Plane") 221 Architectural component providing common functions to all SACM 222 participants, including authentication, authorization, 223 capabilities mappings, and the like. 225 Posture 227 Defined in [RFC5209] as "configuration and/or status of hardware 228 or software on an endpoint as it pertains to an organization's 229 security policy." 231 This term is used within the scope of this document to represent 232 the state information that is collected from an endpoint (e.g. 233 software/hardware inventory, configuration settings). The state 234 information may constitute one to many Posture Attributes. 236 Posture Attributes 238 Defined in [RFC5209] as "attributes describing the configuration 239 or status (posture) of a feature of the endpoint. A Posture 240 Attribute represents a single property of an observed state. For 241 example, a Posture Attribute might describe the version of the 242 operating system installed on the system." 244 Within this document this term represents a specific assertion 245 about endpoint state (e.g. configuration setting, installed 246 software, hardware). The phrase "features of the endpoint" refers 247 to installed software or software components. 249 Provider 251 An architectural component providing information to another 252 architectrual component. 254 Proxy 256 An architectural component providing functions, information, or 257 services on behalf of another component, which is not directly 258 participating in the architecture. 260 Repository 262 An architectural component intended to store information of a 263 particular kind. A single repository may provide the functions of 264 more than one repository type (i.e. configuration baseline 265 repository, assessment results repository, etc.) 267 Role 269 A label representing a collection of functions provided by a 270 particular architectural component. 272 Security Automation 274 The process of which security alerts can be automated through the 275 use of different tools to monitor, evaluate and analyze endpoint 276 and network traffic for the purposes of detecting 277 misconfigurations, misbehaviors or threats. 279 Supplicant 281 The entity seeking to be authenticated by the Management Plane for 282 the purpose of participating in the SACM architecture. 284 System Resource 286 Defined in [RFC4949] as "data contained in an information system; 287 or a service provided by a system; or a system capacity, such as 288 processing power or communication bandwidth; or an item of system 289 equipment (i.e., hardware, firmware, software, or documentation); 290 or a facility that houses system operations and equipment. 292 3. IANA Considerations 294 This memo includes no request to IANA. 296 4. Security Considerations 298 This memo documents terminology for security automation. While it is 299 about security, it does not affect security. 301 5. Acknowledgements 303 6. Change Log 305 6.1. ietf-sacm-terminology-01- to -02- 307 Added simple list of terms extracted from UC draft -05. It is 308 expected that comments will be received on this list of terms as to 309 whether they should be kept in this document. Those that are kept 310 will be appropriately defined or cited. 312 6.2. ietf-sacm-terminology-01- to -02- 314 Added Vulnerability, Vulnerability Management, xposure, 315 Misconfiguration, and Software flaw. 317 6.3. ietf-sacm-terminology-02- to -03- 319 Removed Section 2.1. Cleaned up some editing nits; broke terms into 320 2 sections (predefined and newly defined terms). Added some of the 321 relevant terms per the proposed list discussed in the IETF 89 322 meeting. 324 6.4. ietf-sacm-terminology-03 to -04- 326 TODO 328 6.5. ietf-sacm-terminology-04 to -05- 330 TODO 332 6.6. ietf-sacm-terminology-05 to -06- 334 Updated author information. 336 Combined "Pre-defined Terms" with "New Terms and Definitions". 338 Removed "Requirements language". 340 Removed unused reference to use case draft; resulted in removal of 341 normative references. 343 Removed introductory text from Section 1 indicating that this 344 document is intended to be temporary. 346 Added placeholders for missing change log entries. 348 7. Informative References 350 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 351 Information Models and Data Models", RFC 3444, January 352 2003. 354 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 355 4949, August 2007. 357 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 358 Tardo, "Network Endpoint Assessment (NEA): Overview and 359 Requirements", RFC 5209, June 2008. 361 Authors' Addresses 363 David Waltermire 364 National Institute of Standards and Technology 365 100 Bureau Drive 366 Gaithersburg, Maryland 20877 367 USA 369 Email: david.waltermire@nist.gov 370 Adam W. Montville 371 Center for Internet Security 372 31 Tech Valley Drive 373 East Greenbush, New York 12061 374 USA 376 Email: adam.w.montville@gmail.com 378 David Harrington 379 Effective Software 380 50 Harding Rd 381 Portsmouth, NH 03801 382 USA 384 Email: ietfdbh@comcast.net 386 Nancy Cam-Winget 387 Cisco Systems 388 3550 Cisco Way 389 San Jose, CA 95134 390 US 392 Email: ncamwing@cisco.com 394 Jarrett Lu 395 Oracle Corporation 396 4180 Network Circle 397 Santa Clara, California 95054 399 Email: jarrett.lu@oracle.com 401 Brian Ford 402 Lancope 403 3650 Brookside Parkway, Suite 500 404 Alpharetta, Georgia 30022 406 Email: bford@lancope.com 407 Merike Kaeo 408 Double Shot Security 409 3518 Fremont Avenue North, Suite 363 410 Seattle, Washington 98103 412 Email: merike@doubleshotsecurity.com