idnits 2.17.1 draft-ietf-sacm-terminology-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 237: '...A SACM component MUST contain at least...' RFC 2119 keyword, line 238: '...lding blocks and MAY contain data plan...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2015) is 3188 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TODO' is mentioned on line 165, but not defined == Missing Reference: 'TBD' is mentioned on line 267, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational July 06, 2015 5 Expires: January 7, 2016 7 Secure Automation and Continuous Monitoring (SACM) Terminology 8 draft-ietf-sacm-terminology-07 10 Abstract 12 This memo documents terminology used in the documents produced by 13 SACM (Security Automation and Continuous Monitoring). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 7, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 51 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 53 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 54 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 56 8. Informative References . . . . . . . . . . . . . . . . . . . 10 57 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 10 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 60 1. Introduction 62 Our goal with this document is to improve our agreement on the 63 terminology used in documents produced by the IETF Working Group for 64 Security Automation and Continuous Monitoring. Agreeing on 65 terminology should help reach consensus on which problems we're 66 trying to solve, and propose solutions and decide which ones to use. 68 2. Terms and Definitions 70 This section describes terms that have been defined by other RFC's 71 and defines new ones. The predefined terms will reference the RFC 72 and where appropriate will be annotated with the specific context by 73 which the term is used in SACM. 75 Assessment: Defined in [RFC5209] as "the process of collecting 76 posture for a set of capabilities on the endpoint (e.g., host- 77 based firewall) such that the appropriate validators may evaluate 78 the posture against compliance policy." 80 Within SACM the use of the term is expanded to support other uses 81 of collected posture (e.g. reporting, network enforcement, 82 vulnerability detection, license management). The phrase "set of 83 capabilities on the endpoint" includes: hardware and software 84 installed on the endpoint." 86 Asset: Defined in [RFC4949] as "a system resource that is (a) 87 required to be protected by an information system's security 88 policy, (b) intended to be protected by a countermeasure, or (c) 89 required for a system's mission. 91 Asset Characterization: Asset characterization is the process of 92 defining attributes that describe properties of an identified 93 asset. 95 Asset Management: The process by which assets are provisioned, 96 updated, maintained and deprecated. 98 Attribute: Defined in [RFC5209] as "data element including any 99 requisite meta-data describing an observed, expected, or the 100 operational status of an endpoint feature (e.g., anti-virus 101 software is currently in use)." 103 Authentication: Defined in [RFC4949] as "the process of verifying a 104 claim that a system entity or system resource has a certain 105 attribute value." 107 Authorization: Defined in [RFC4949] as "an approval that is granted 108 to a system entity to access a system resource." 110 Broker: A standard SACM component providing and/or connecting 111 services on the behalf of other SACM components via the control 112 plane. Within the SACM Architecture, for example, a broker may 113 provide authorization services and find, upon request, SACM 114 components providing requested services. 116 Building Block: For SACM, a building block is a unit of 117 functionality that is used to compose SACM components. It 118 contains functions and may apply to one or more use cases. A 119 Building Block can have interfaces on the data plane, the control 120 plane, or on the management plane. 122 Capability: The extent of an SACM component's ability enabled by the 123 building blocks it is composed of. For example, a Posture 124 Information Provider may only provide endpoint management data, 125 and then only a subset of that data. 127 Collection Task: The task by which endpoint attributes and/or 128 corresponding attribute values are collected. 130 Consumer: An architectural component receiving information from 131 another architectrual component. 133 Data Confidentiality: Defined in [RFC4949] as "the property that 134 data is not disclosed to system entities unless they have been 135 authorized to know the data." 137 Data Integrity: Defined in [RFC4949] as "the property that data has 138 not been changed, destroyed, or lost in an unauthorized or 139 accidental manner." 141 Data Origin: One or more properties that enable a SACM component to 142 identify an Endpoint that is claimed to be the original source of 143 received data. 145 Data Provenance: A historical record of the origins and evolution of 146 data that is influenced by inputs, entities, functions and 147 processes. 149 Endpoint: Defined in [RFC5209] as "any computing device that can be 150 connected to a network. Such devices normally are associated with 151 a particular link layer address before joining the network and 152 potentially an IP address once on the network. This includes: 153 laptops, desktops, servers, cell phones, or any device that may 154 have an IP address." 156 To further clarify the [RFC5209] definition, an endpoint is any 157 physical or virtual device that may have a network address. Note 158 that, network infrastructure devices (e.g. switches, routers, 159 firewalls), which fit the definition, are also considered to be 160 endpoints within this document. 162 Based on the previous definition of an asset, an endpoint is a 163 type of asset. 165 Endpoint Attributes: [TODO] (Definition of content, structure, and 166 relationship to Posture Attributes) 168 Evaluation Task: The task by which endpoint attributes are 169 evaluated. 171 Evaluation Result: The resulting value from having evaluated a set 172 of posture attributes. 174 Expected Endpoint State: The required state of an endpoint that is 175 to be compared against. 177 Function: A behavioral aspect or capacity of a particular building 178 block, which belies that building blocks's purpose. For example, 179 a building block on the control plane can provide a brokering 180 function to other SACM components. On the data plane, a function 181 can act as a provider and/or as a consumer of information. 183 Information Model: An information model is an abstract 184 representation of data, their properties, relationships between 185 data and the operations that can be performed on the data. While 186 there is some overlap with a data model, [RFC3444] distinguishes 187 an information model as being protocol and implementation neutral 188 whereas a data model would provide such details. 190 Management Plane (TBD per list; was "Control Plane"): Architectural 191 component providing common functions to all SACM participants, 192 including authentication, authorization, capabilities mappings, 193 and the like. 195 Posture: Defined in [RFC5209] as "configuration and/or status of 196 hardware or software on an endpoint as it pertains to an 197 organization's security policy." 199 This term is used within the scope of SACM to represent the 200 configuration and state information that is collected from an 201 endpoint (e.g. software/hardware inventory, configuration 202 settings, dynamically assigned addresses). This information may 203 constitute one to many Posture Attributes. 205 Posture Attributes: Defined in [RFC5209] as "attributes describing 206 the configuration or status (posture) of a feature of the 207 endpoint. A Posture Attribute represents a single property of an 208 observed state. For example, a Posture Attribute might describe 209 the version of the operating system installed on the system." 211 Within this document this term represents a specific assertion 212 about endpoint configuration or state (e.g. configuration setting, 213 installed software, hardware). The phrase "features of the 214 endpoint" refers to installed software or software components. 216 Provider: An architectural component providing information to 217 another architectrual component. 219 Proxy: An architectural component providing functions, information, 220 or services on behalf of another component, which is not directly 221 participating in the architecture. 223 Repository: An architectural component intended to store information 224 of a particular kind. A single repository may provide the 225 functions of more than one repository type (i.e. configuration 226 baseline repository, assessment results repository, etc.) 228 SACM Role: A label representing a collection of building blocks 229 (containing functions and composing SACM components) residing on a 230 particular endpoint. If a particular endpoint does not contain 231 any SACM components it takes on the role of a target endpoint 232 unless indicated otherwise. 234 SACM Component: A composition of building blocks that contain 235 control plane, data plane or management plane functions. SACM 236 defines a set of standard components (e.g. a collector, a broker, 237 or a data store). A SACM component MUST contain at least a basic 238 set of control plane building blocks and MAY contain data plane 239 and managment plane building blocks. A SACM component residing on 240 an endpoint assigns one or more SACM roles to the corresponding 241 endpoint. A SACM component "resides on" an endpoint and an 242 endpoint "contains" a SACM component, correspondingly. 244 SACM Component Discovery: The function by which a SACM component (or 245 subsets, such as SACM roles or other functions) can be discovered. 247 Security Automation: The process of which security alerts can be 248 automated through the use of different tools to monitor, evaluate 249 and analyze endpoint and network traffic for the purposes of 250 detecting misconfigurations, misbehaviors or threats. 252 Supplicant: The entity seeking to be authenticated by the Management 253 Plane for the purpose of participating in the SACM architecture. 255 System Resource: Defined in [RFC4949] as "data contained in an 256 information system; or a service provided by a system; or a system 257 capacity, such as processing power or communication bandwidth; or 258 an item of system equipment (i.e., hardware, firmware, software, 259 or documentation); or a facility that houses system operations and 260 equipment. 262 Target Endpoint: A target endpoint is a SACM Role. An endpoint that 263 takes on the target endpoint role either contains no SACM 264 component or contains an internal SACM component. A target 265 endpoint is an "endpoint under assessment" (even if it is not 266 actively under assessment at all times). If an endpoint takes on 267 both the role of target endpoint and _Not A Target Endpoint_ [TBD] 268 it is not a Target Endpoint. 270 A target endpoint is similar to a device that is a Target of 271 Evaluation (TOE) as defined in Common Criteria. 273 Target Endpoint Discovery: The function by which target endpoints 274 can be discovered. 276 3. IANA Considerations 278 This memo includes no request to IANA. 280 4. Security Considerations 282 This memo documents terminology for security automation. While it is 283 about security, it does not affect security. 285 5. Acknowledgements 287 6. Change Log 289 Changes from version 00 to version 01: 291 o Added simple list of terms extracted from UC draft -05. It is 292 expected that comments will be received on this list of terms as 293 to whether they should be kept in this document. Those that are 294 kept will be appropriately defined or cited. 296 Changes from version 01 to version 02: 298 o Added Vulnerability, Vulnerability Management, xposure, 299 Misconfiguration, and Software flaw. 301 Changes from version 02 to version 03: 303 o Removed Section 2.1. Cleaned up some editing nits; broke terms 304 into 2 sections (predefined and newly defined terms). Added some 305 of the relevant terms per the proposed list discussed in the IETF 306 89 meeting. 308 Changes from version 03 to version 04: 310 o TODO 312 Changes from version 04 to version 05: 314 o TODO 316 Changes from version 05 to version 06: 318 o Updated author information. 320 o Combined "Pre-defined Terms" with "New Terms and Definitions". 322 o Removed "Requirements language". 324 o Removed unused reference to use case draft; resulted in removal of 325 normative references. 327 o Removed introductory text from Section 1 indicating that this 328 document is intended to be temporary. 330 o Added placeholders for missing change log entries. 332 Changes from version 06 to version 07: 334 o Added Contributors section. 336 o Updated author list. 338 o Changed title from "Terminology for Security Assessment" to 339 "Secure Automation and Continuous Monitoring (SACM) Terminology". 341 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 343 o Added appendix The Attic to stash terms for future updates. 345 o Added Authentication, Authorization, Data Confidentiality, Data 346 Integrity, Data Origin, Data Provenance, SACM Component, SACM 347 Component Discovery, Target Endpoint Discovery. 349 o Major updates to Building Block, Function, SACM Role, Target 350 Endpoint. 352 o Minor updates to Broker, Capability, Collection Task, Evaluation 353 Task, Posture. 355 o Relabled Role to SACM Role, Endpoint Target to Target Endpoint, 356 Endpoint Discovery to Endpoint Identification. 358 o Moved Asset Targeting, Client, Endpoint Identification to The 359 Attic. 361 o Endpoint Attributes added as a TODO. 363 o Changed the structure of the Change Log. 365 7. Contributors 367 David Waltermire 368 National Institute of Standards and Technology 369 100 Bureau Drive 370 Gaithersburg, Maryland 20877 371 USA 373 Email: david.waltermire@nist.gov 375 Adam W. Montville 376 Center for Internet Security 377 31 Tech Valley Drive 378 East Greenbush, New York 12061 379 USA 380 Email: adam.w.montville@gmail.com 382 David Harrington 383 Effective Software 384 50 Harding Rd 385 Portsmouth, NH 03801 386 USA 388 Email: ietfdbh@comcast.net 390 Nancy Cam-Winget 391 Cisco Systems 392 3550 Cisco Way 393 San Jose, CA 95134 394 US 395 Jarrett Lu 396 Oracle Corporation 397 4180 Network Circle 398 Santa Clara, California 95054 400 Email: jarrett.lu@oracle.com 402 Jarrett Lu 403 Oracle Corporation 404 4180 Network Circle 405 Santa Clara, California 95054 407 Email: jarrett.lu@oracle.com 409 Brian Ford 410 Lancope 411 3650 Brookside Parkway, Suite 500 412 Alpharetta, Georgia 30022 414 Email: bford@lancope.com 416 Merike Kaeo 417 Double Shot Security 418 3518 Fremont Avenue North, Suite 363 419 Seattle, Washington 98103 421 Email: merike@doubleshotsecurity.com 423 8. Informative References 425 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 426 Information Models and Data Models", RFC 3444, January 427 2003. 429 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 430 4949, August 2007. 432 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 433 Tardo, "Network Endpoint Assessment (NEA): Overview and 434 Requirements", RFC 5209, June 2008. 436 Appendix A. The Attic 438 The following terms are stashed for now and will be updated later: 440 Asset Targeting: Asset targeting is the use of asset identification 441 and categorization information to drive human-directed, automated 442 decision making for data collection and analysis in support of 443 endpoint posture assessment. 445 Client: An architectural component receiving services from another 446 architectural component. 448 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 449 The process by which an endpoint can be identified. 451 Author's Address 453 Henk Birkholz 454 Fraunhofer SIT 455 Rheinstrasse 75 456 Darmstadt 64295 457 Germany 459 Email: henk.birkholz@sit.fraunhofer.de