idnits 2.17.1 draft-ietf-sacm-terminology-09.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 (March 21, 2016) is 2956 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 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational J. Lu 5 Expires: September 22, 2016 Oracle Corporation 6 N. Cam-Winget 7 Cisco Systems 8 March 21, 2016 10 Secure Automation and Continuous Monitoring (SACM) Terminology 11 draft-ietf-sacm-terminology-09 13 Abstract 15 This memo documents terminology used in the documents produced by 16 SACM (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 September 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 57 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 59 8. Informative References . . . . . . . . . . . . . . . . . . . 17 60 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 17 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 63 1. Introduction 65 Our goal with this document is to improve our agreement on the 66 terminology used in documents produced by the IETF Working Group for 67 Security Automation and Continuous Monitoring. Agreeing on 68 terminology should help reach consensus on which problems we're 69 trying to solve, and propose solutions and decide which ones to use. 71 2. Terms and Definitions 73 This section describes terms that have been defined by other RFC's 74 and defines new ones. The predefined terms will reference the RFC 75 and where appropriate will be annotated with the specific context by 76 which the term is used in SACM. 78 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 79 entity without accompanying evidence of its validity". In the 80 context of SACM, an assertion is a collection result that includes 81 metadata about the data source (and optionally a timestamp 82 indicating the point in time the assertion was created at). The 83 validity of an assertion cannot be verified. 85 Assessment: Defined in [RFC5209] as "the process of collecting 86 posture for a set of capabilities on the endpoint (e.g., host- 87 based firewall) such that the appropriate validators may evaluate 88 the posture against compliance policy." 90 Within SACM the use of the term is expanded to support other uses 91 of collected posture (e.g. reporting, network enforcement, 92 vulnerability detection, license management). The phrase "set of 93 capabilities on the endpoint" includes: hardware and software 94 installed on the endpoint." 96 Asset: Defined in [RFC4949] as "a system resource that is (a) 97 required to be protected by an information system's security 98 policy, (b) intended to be protected by a countermeasure, or (c) 99 required for a system's mission". In the scope of SACM, an asset 100 can be composed of other assets. Examples of Assets include: 101 Endpoints, Software, Guidance, or X.509 public key certificates. 102 An asset is not necessarily owned by an organization. 104 Asset Management: The process by which assets are provisioned, 105 updated, maintained and deprecated. 107 Attribute: Defined in [RFC5209] as "data element including any 108 requisite meta-data describing an observed, expected, or the 109 operational status of an endpoint feature (e.g., anti-virus 110 software is currently in use)." If not indicated otherwise, 111 attributes in SACM are represented and processed as attribute 112 value pairs. 114 Authentication: Defined in [RFC4949] as "the process of verifying a 115 claim that a system entity or system resource has a certain 116 attribute value." 118 Authorization: Defined in [RFC4949] as "an approval that is granted 119 to a system entity to access a system resource." 121 Broker: A broker is a specific controller type that contains control 122 plane functions to provide and/or connect services on behalf of 123 other SACM components via interfaces on the control plane. A 124 broker may provide, for example, authorization services and find, 125 upon request, SACM components providing requested services. 127 Capability: The extent of an SACM component's ability enabled by the 128 functions it is composed of. Capabilities are propagated by a 129 SACM component and can be discovered by or negotiated with other 130 SACM components. For example, the capability of a SACM Provider 131 may be to provide endpoint management data, or only a subset of 132 that data. 134 Collection Result: Information about a target endpoint that is 135 produced by a collector conducting a collection task. A 136 collection result is composed of one or more endpoint attributes. 138 Collection Task: The task by which endpoint attributes and/or 139 corresponding attribute values about a target endpoint are 140 collected. There are three types of collection tasks, each 141 requiring an appropriate set of functions to be included in the 142 SACM component conducting the collection task: 144 Self-Reporting: A SACM component located on the target endpoint 145 itself conducts the collection task. 147 Remote-Acquisition: A SACM component located on an Endpoint 148 different from the target endpoint conducts the collection task 149 via interfaces available on the target endpoint, e.g. SNMP/ 150 NETCONF or WMI. 152 Behavior-Observation: A SACM component located on an Endpoint 153 different from the target endpoint observes network traffic 154 related to the target endpoint and conducts the collection task 155 via interpretation of that network traffic. 157 Collector: A piece of software that acquires information about one 158 or more target endpoints by conducting collection tasks. A 159 collector provides acquired information to SACM components in the 160 form of collection results. A SACM component that consumes 161 collection results may take on the role of a provider and publish 162 the collection results in a SACM domain. (TBD: A collector may 163 not be a SACM component and therefore not part of a SACM domain). 165 Consumer: A consumer is a SACM role that is assigned to a SACM 166 component that contains functions to receive information from 167 other SACM components. 169 Control Plane: Typically used as a term in the context of routing, 170 e.g. [RFC6192]. In the context of SACM, the control plane is an 171 architectural component providing common control functions to all 172 SACM components, including authentication, authorization, 173 capability discovery or negotiation. The control plane 174 orchestrates the flow on the data plane according to guidance and/ 175 or input from the management plane. SACM components with 176 interfaces to the control plane have knowledge of the capabilities 177 of other SACM components within a SACM domain. 179 Controller: A controller is a SACM role that is assigned to a SACM 180 component containing control plane functions that manage and 181 facilitate information sharing or execute on security functions. 182 There are three types of SACM controllers: Broker, Proxy, and 183 Repository. Depending on its type, a controller can also contain 184 functions that have interfaces on the data plane. 186 Data Confidentiality: Defined in [RFC4949] as "the property that 187 data is not disclosed to system entities unless they have been 188 authorized to know the data." 190 Data Integrity: Defined in [RFC4949] as "the property that data has 191 not been changed, destroyed, or lost in an unauthorized or 192 accidental manner." 194 Data Origin: One or more properties that enable a SACM component to 195 identify the SACM component that initially acquired or produced 196 data about a (target) endpoint (e.g. via collection from a data 197 source). 199 Data Plane: Typically used as a term in the context of routing (and 200 used as a synonym for forwarding plane, e.g. [RFC6192]). In the 201 context of SACM, the data plane is an architectural component 202 providing operational functions to enable a SACM component to 203 provide and consume SACM statements and therefore SACM content 204 (the "payload"). The data plane is used to conduct distributed 205 SACM tasks by transporting SACM content using transporting 206 encodings and corresponding operations defined by SACM data 207 models. 209 Data Provenance: A historical record of the sources, origins and 210 evolution of data that is influenced by inputs, entities, 211 functions and processes. 213 Data Source: One or more properties that enable a SACM component to 214 identify an (target) endpoint that is claimed to be the original 215 source of received data. 217 Endpoint: Defined in [RFC5209] as "any computing device that can be 218 connected to a network. Such devices normally are associated with 219 a particular link layer address before joining the network and 220 potentially an IP address once on the network. This includes: 221 laptops, desktops, servers, cell phones, or any device that may 222 have an IP address." 224 To further clarify the [RFC5209] definition, an endpoint is any 225 physical or virtual device that may have a network address. Note 226 that, network infrastructure devices (e.g. switches, routers, 227 firewalls), which fit the definition, are also considered to be 228 endpoints within this document. 230 The SACM architecture differentiates two essential categories of 231 endpoints: Endpoints whose security posture is intended to be 232 assessed (target endpoints) and endpoints that are specifically 233 excluded from endpoint posture assessment (excluded endpoints). 235 Based on the definition of an asset, an endpoint is a type of 236 asset. 238 Endpoint Attribute: In the context of SACM, endpoint attributes are 239 information elements that describe a characteristic of a target 240 endpoint. Endpoint Attributes typically constitute atomic 241 information elements (AVP) that can be bundled into composite 242 information elements (e.g. information about a specific network 243 interface can be represented via a set of multiple AVP). 245 Endpoint Characterization: The task by which a profile is composed 246 out of endpoint attributes that describe the desired or expected 247 posture of a type or class of target endpoints or even an 248 individual target endpoint. The result of this task is an 249 endpoint profile that is required as guidance for the tasks of 250 endpoint classification or posture assessment. 252 Endpoint Classification: The task by which a discovered target 253 endpoint is classified. Endpoint classification requires guidance 254 in the form of an endpoint profile, discovery results and 255 potentially collection results. Types, classes or the 256 characteristics of an individual target endpoint are defined via 257 endpoint profiles. 259 Evaluation Task: The task by which endpoint attributes are 260 evaluated. 262 Evaluation Result: The resulting value from having evaluated a set 263 of posture attributes. 265 Excluded Endpoint: A specific designation, which is assigned to an 266 endpoint that is not supposed to be the subject of a collection 267 task (and therefore is not a target endpoint). Typically but not 268 necessarily, endpoints that contain a SACM component (and are 269 therefore part of the SACM domain) are designated as excluded 270 endpoints. Target endpoints that contain a SACM component cannot 271 be designated as excluded endpoints and are part of the SACM 272 domain. 274 Expected Endpoint State: The required state of an endpoint that is 275 to be compared against. Sets of expected endpoint states are 276 transported as guidance in target endpoint profiles via the 277 management plane. This, for example, can be a policy, but also a 278 recorded past state. An expected state is represented can be 279 represented via a atomic information element or an composite 280 information element that represents a set of multiple attribute 281 value pairs. 283 SACM Function: A behavioral aspect or capacity of a particular SACM 284 component, which belies that SACM component's purpose. For 285 example, a SACM function with interfaces on the control plane can 286 provide a brokering function to other SACM components. Via data 287 plane interfaces, a function can act as a provider and/or as a 288 consumer of information. SACM functions can be propagated as the 289 capabilities of a SACM component and can be discovered by or 290 negotiated with other SACM components. 292 Guidance: Input to processes and tasks, such as collecting, 293 assessing or reporting. Guidance influences the behavior of a 294 SACM component and is considered content of the management plane. 295 Guidance can be manually or automatically generated or provided. 296 Typically, the tasks that provide guidance to SACM components have 297 a low-frequency and tend to be be sporadic. A prominent example 298 of guidance are target endpoint profiles, but guidance can have 299 many forms, including: 301 Configuration, e.g. a SACM component's name, or a CMDB's IPv6 302 address. 304 Profiles, e.g. a set of expected states for network behavior 305 associated with target endpoints employed by specific users. 307 Policies, e.g. an interval to refresh the registration of a SACM 308 component, or a list of required capabilities for SACM components 309 in a specific location. 311 Information Model: An information model is an abstract 312 representation of data, their properties, relationships between 313 data and the operations that can be performed on the data. While 314 there is some overlap with a data model, [RFC3444] distinguishes 315 an information model as being protocol and implementation neutral 316 whereas a data model would provide such details. The purpose of 317 the SACM information model is to ensure interoperability between 318 SACM data models (that are used as transport encoding) and to 319 provide a standardized set of information elements for 320 communication between SACM components. 322 Interaction Model: For now this is a Place-Holder. Is an 323 interaction model that defines, for example, the operations on the 324 control plane, such as registration or SACM component discovery, 325 required? 327 Internal Collector: Internal Collector: a collector that runs on a 328 target endpoint to acquire information from that target endpoint. 329 (TBD: An internal collector is not a SACM component and therefore 330 not part of a SACM domain). 332 Management Plane: An architectural component providing common 333 functions to steer the behavior of SACM components, e.g. its 334 behavior on the control plane. Prominent examples include: 335 modification of the configuration of a SACM component or updating 336 a target endpoint profile that resides on an evaluator. In 337 essence, guidance is transported via the management plane. 338 Typically, a SACM component can fulfill its purpose without 339 continuous input from the management plane. In contrast, without 340 continuous availability of control plane functions a typical SACM 341 component could not function properly. In general, interaction on 342 the management plane is less frequent and less regular than on the 343 control plane. Input via the management plane can be manual (e.g. 344 via a CLI), or can be automated via management plane functions 345 that are part of other SACM components. 347 Network Address: Network addresses are layer specific and follow 348 layer specific address schemes. Each interface of a specific 349 layer can be associated with one or more addresses appropriate for 350 that layer. There is no guarantee that an address is globally 351 unique. In general, there is a scope to an address in which it is 352 intended to be unique. 354 Examples include: physical Ethernet port with a MAC address, layer 355 2 VLAN interface with a MAC address, layer 3 interface with 356 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 357 IPv4 address. 359 Network Interface: An endpoint is connected to a network via one or 360 more interfaces. Interfaces can be physical or virtual. 361 Interfaces of an endpoint can operate on different layers, most 362 prominently what is now commonly called layer 2 and 3. Within a 363 layer, interfaces can be nested. On layer 2, a root interface is 364 typically associated with a physical interface port and nested 365 interfaces are virtual interfaces. In the case of a virtual 366 endpoint, a root interface can be a virtual interface. Virtual 367 layer 2 interfaces of one or more endpoints can also constitute an 368 aggregated group of links that act as one. On layer 3, nested 369 interfaces typically constitute virtual tunnels or networks. 371 Examples include: physical Ethernet port, layer 2 VLAN interface, 372 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 374 Posture: Defined in [RFC5209] as "configuration and/or status of 375 hardware or software on an endpoint as it pertains to an 376 organization's security policy." 378 This term is used within the scope of SACM to represent the 379 configuration and state information that is collected from a 380 target endpoint in the form of endpoint attributes (e.g. software/ 381 hardware inventory, configuration settings, dynamically assigned 382 addresses). This information may constitute one or more posture 383 attributes. 385 Posture Attributes: Defined in [RFC5209] as "attributes describing 386 the configuration or status (posture) of a feature of the 387 endpoint. A Posture Attribute represents a single property of an 388 observed state. For example, a Posture Attribute might describe 389 the version of the operating system installed on the system." 391 Within this document this term represents a specific assertion 392 about endpoint configuration or state (e.g. configuration setting, 393 installed software, hardware) represented via endpoint attributes. 394 The phrase "features of the endpoint" highlighted above refers to 395 installed software or software components. 397 Provider: A provider is a SACM role that is assigned to a SACM 398 component that contains functions to provide information to other 399 SACM components. 401 Proxy: A proxy is a specific controller type that provides data 402 plane and control plane functions, information, or services on 403 behalf of another component, which is not directly participating 404 in the SACM architecture. 406 Repository: A repository is a specific controller type that contains 407 functions to consume, store and provide information of a 408 particular kind - typically data transported on the data plane, 409 but potentially also data and metadata from the control and 410 management plane. A single repository may provide the functions 411 of more than one specific repository type (i.e. configuration 412 baseline repository, assessment results repository, etc.) 414 SACM Role: SACM roles are associated with SACM components and are 415 defined by the set of functions and interfaces a SACM component 416 includes. There are three SACM roles: provider, consumer, and 417 controller. The roles associated with a SACM component are 418 determined by the purpose of the functions and corresponding 419 interfaces the SACM component is composed of. 421 SACM Component: A set of SACM functions composes a SACM component. 422 A SACM component conducts SACM tasks, acting on control plane, 423 data plane and/or management plane via corresponding SACM 424 interfaces. SACM defines a set of standard components (e.g. a 425 collector, a broker, or a data store). A SACM component contains 426 at least a basic set of control plane functions and can contain 427 data plane and management plane functions. A SACM component 428 residing on an endpoint assigns one or more SACM roles to the 429 corresponding endpoint due to the SACM functions it is composed 430 of. A SACM component "resides on" an endpoint and an endpoint 431 "contains" a SACM component, correspondingly. For example, a SACM 432 component that is composed solely of functions that provide 433 information would only take on the role of a provider. 435 SACM Component Discovery: The function by which a SACM component 436 (e.g. by role, capabilities, or data provided/consumed) can be 437 discovered. 439 SACM Domain: Endpoints that include a SACM component compose a SACM 440 domain. (To be revised, additional definition content TBD, 441 possible dependencies to SACM architecture) 443 Security Automation: The process of which security alerts can be 444 automated through the use of different tools to monitor, evaluate 445 and analyze endpoint and network traffic for the purposes of 446 detecting misconfigurations, misbehaviors or threats. 448 Software Package: A generic software package (e.g. a text editor). 450 Software Component: A software package installed on an endpoint, 451 including a unique serial number if present (e.g. a text editor 452 associated with a unique license key). 454 Software Instance: A running instance of the software component 455 (e.g. on a multi-user system, one logged-in user has one instance 456 of a text editor running and another logged-in user has another 457 instance of the same text editor running, or on a single-user 458 system, a user could have multiple independent instances of the 459 same text editor running). 461 Statement: The output of a provider, e.g. a report or an assertion 462 acquired via a collection result from a collector, that includes 463 metadata about the data origin and the point in time the statement 464 was created at. A statement can be accompanied by evidence of the 465 validity of its metadata. 467 Supplicant: The entity seeking to be authenticated by the Management 468 Plane for the purpose of participating in the SACM architecture. 470 System Resource: Defined in [RFC4949] as "data contained in an 471 information system; or a service provided by a system; or a system 472 capacity, such as processing power or communication bandwidth; or 473 an item of system equipment (i.e., hardware, firmware, software, 474 or documentation); or a facility that houses system operations and 475 equipment. 477 Target Endpoint: A target endpoint is an "endpoint under assessment" 478 (even if it is not actively under assessment at all times) or 479 "endpoint of interest". Every endpoint that is not specifically 480 designated as an excluded endpoint is a target endpoint. A target 481 endpoint is not part of a SACM domain unless it contains a SACM 482 component (e.g. a SACM component that publishes collection results 483 coming from an internal collector). 485 A target endpoint is similar to a device that is a Target of 486 Evaluation (TOE) as defined in Common Criteria. 488 Target Endpoint Discovery: The function by which target endpoints 489 can be discovered. The output of target endpoint discovery 490 typically includes identifying endpoint attributes. 492 Target Endpoint Identifier: The target endpoint discovery process 493 and collection tasks targeted at target endpoints can result in a 494 set of identifying endpoint attributes. This set of identifying 495 endpoint attributes is used as a target endpoint identifier 496 referring to a specific target endpoint. Depending on the 497 available identifying attributes this reference can be ambiguous 498 and is a "best-effort" mechanism. Every distinct set of 499 identifying endpoint attributes can be associated with a unique 500 target endpoint label. 502 Target Endpoint Label: An artificially created id that references a 503 distinct set of identifying attributes (Target Endpoint 504 Identifier). A target endpoint label is unique in a SACM domain 505 and created by a SACM component that contains an appropriate 506 function. 508 Target Endpoint Profile: A bundle of expected or desired 509 configurations and states (typically a composition of endpoint 510 attribute value pairs) that can be associated with a target 511 endpoint. The corresponding task by which the association with a 512 target endpoint takes places is the endpoint classification. The 513 task by which a endpoint profile is created is the endpoint 514 characterization. A type or class of target endpoints is defined 515 within a target endpoint profile, e.g. printer, smartphone, or an 516 office PC. 518 (SACM) Task: [TBD conflicts in definitions of specific tasks] A SACM 519 task is conducted by one or more SACM functions that reside on a 520 SACM component (e.g. a collection task or endpoint 521 characterization). A SACM task can be triggered by other 522 operations or functions (e.g. a query from another SACM component 523 or an unsolicited push due to a subscription on the data plane). 524 A task is part of a SACM process chain. A task starts at a given 525 point in time and ends in a deterministic state. With the 526 exception of a collection task, a SACM task consumes SACM content. 527 The output of a task is a result that can be provided (e.g. 529 published) on the data plane. There are six fundamental tasks 530 defined in SACM: 532 Asset Classification: Map the assets on the target endpoints to 533 asset classes. This enables identification of the attributes 534 needed to exchange information pertaining to the target endpoint. 535 [the label now conflicts with Endpoint Classification] 537 Attribute Definition: Define the attributes desired to be 538 collected from each target endpoint. This is what we want to know 539 about a target endpoint. For instance, organizations will want to 540 know what software is installed and its many critical security 541 attributes such as patch level. 543 Policy Definition: This is where an organization can express its 544 policy for acceptable or problematic values of an endpoint 545 attribute. The expected values of an endpoint attribute are 546 determined for later comparison against the actual endpoint 547 attribute values during the evaluation process. Expected values 548 may include both those values which are good as well as those 549 values which represent problems, such as vulnerabilities. The 550 organization can also specify the endpoint attributes that are to 551 be present for a given target endpoint. 553 Information Collection: Collect information (attribute values) 554 from the target endpoint to populate the endpoint data. 556 Endpoint Assessment: Evaluate the actual values of the endpoint 557 attributes against those expressed in the policy. (An evaluation 558 result may become additional endpoint data). 560 Result Reporting: Report the results of the evaluation for use by 561 other components. Examples of use of a report would be additional 562 evaluation, network enforcement, vulnerability detection, and 563 license management. 565 Timestamps : Defined in [RFC4949] as "with respect to a data object, 566 a label or marking in which is recorded the time (time of day or 567 other instant of elapsed time) at which the label or marking was 568 affixed to the data object" and as "with respect to a recorded 569 network event, a data field in which is recorded the time (time of 570 day or other instant of elapsed time) at which the event took 571 place.". 573 This term is used in SACM to describe a recorded point in time at 574 which an endpoint attribute is created or updated by a target 575 endpoint and observed, transmitted or processed by a SACM 576 component. Timestamps can be created by target endpoints or SACM 577 components and are associated with endpoint attributes provided or 578 consumed by SACM components. Outside of the domain of SACM 579 components the assurance of correctness of time stamps is 580 typically significantly lower than inside a SACM domain. In 581 general, it cannot be simply assumed that the source of time a 582 target endpoint uses is synchronized or trustworthy. 584 3. IANA Considerations 586 This memo includes no request to IANA. 588 4. Security Considerations 590 This memo documents terminology for security automation. While it is 591 about security, it does not affect security. 593 5. Acknowledgements 595 6. Change Log 597 Changes from version 00 to version 01: 599 o Added simple list of terms extracted from UC draft -05. It is 600 expected that comments will be received on this list of terms as 601 to whether they should be kept in this document. Those that are 602 kept will be appropriately defined or cited. 604 Changes from version 01 to version 02: 606 o Added Vulnerability, Vulnerability Management, xposure, 607 Misconfiguration, and Software flaw. 609 Changes from version 02 to version 03: 611 o Removed Section 2.1. Cleaned up some editing nits; broke terms 612 into 2 sections (predefined and newly defined terms). Added some 613 of the relevant terms per the proposed list discussed in the IETF 614 89 meeting. 616 Changes from version 03 to version 04: 618 o TODO 620 Changes from version 04 to version 05: 622 o TODO 624 Changes from version 05 to version 06: 626 o Updated author information. 628 o Combined "Pre-defined Terms" with "New Terms and Definitions". 630 o Removed "Requirements language". 632 o Removed unused reference to use case draft; resulted in removal of 633 normative references. 635 o Removed introductory text from Section 1 indicating that this 636 document is intended to be temporary. 638 o Added placeholders for missing change log entries. 640 Changes from version 06 to version 07: 642 o Added Contributors section. 644 o Updated author list. 646 o Changed title from "Terminology for Security Assessment" to 647 "Secure Automation and Continuous Monitoring (SACM) Terminology". 649 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 651 o Added appendix The Attic to stash terms for future updates. 653 o Added Authentication, Authorization, Data Confidentiality, Data 654 Integrity, Data Origin, Data Provenance, SACM Component, SACM 655 Component Discovery, Target Endpoint Discovery. 657 o Major updates to Building Block, Function, SACM Role, Target 658 Endpoint. 660 o Minor updates to Broker, Capability, Collection Task, Evaluation 661 Task, Posture. 663 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 664 Endpoint Discovery to Endpoint Identification. 666 o Moved Asset Targeting, Client, Endpoint Identification to The 667 Attic. 669 o Endpoint Attributes added as a TODO. 671 o Changed the structure of the Change Log. 673 Changes from version 07 to version 08: 675 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 676 Internal Collector, Network Address, Network Interface, SACM 677 Domain, Statement, Target Endpoint Identifier, Target Endpoint 678 Label, Timestamp. 680 o Major updates to Attributes, Broker, Collection Task, Consumer, 681 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 682 State, SACM Function, Provider, Proxy, Repository, SACM Role, 683 Target Endpoint. 685 o Minor updates to Asset, Building Block, Data Origin, Data Source, 686 Data Provenance, Endpoint, Management Plane, Posture, Posture 687 Attribute, SACM Component, SACM Component Discovery, Target 688 Endpoint Discovery. 690 o Relabeled Function to SACM Function. 692 Changes from version 08 to version 09: 694 o Updated author list. 696 o Added Data Plane, Endpoint Characterization, Endpoint 697 Classification, Guidance, Interaction Model, Software Component, 698 Software Instance, Software Package, Statement, Target Endpoint 699 Profile, SACM Task. 701 o Removed Building Block. 703 o Major updates to Control Plane, Endpoint Attribute, Expected 704 Endpoint State, Information Model, Management Plane. 706 o Minor updates to Attribute, Capabilities, SACM Function, SACM 707 Component, Collection Task. 709 o Moved Asset Characterization to The Attic. 711 7. Contributors 713 David Waltermire 714 National Institute of Standards and Technology 715 100 Bureau Drive 716 Gaithersburg, MD 20877 717 USA 719 Email: david.waltermire@nist.gov 721 Adam W. Montville 722 Center for Internet Security 723 31 Tech Valley Drive 724 East Greenbush, NY 12061 725 USA 727 Email: adam.w.montville@gmail.com 729 David Harrington 730 Effective Software 731 50 Harding Rd 732 Portsmouth, NH 03801 733 USA 735 Email: ietfdbh@comcast.net 737 Nancy Cam-Winget 738 Cisco Systems 739 3550 Cisco Way 740 San Jose, CA 95134 741 USA 743 Email: ncamwing@cisco.com 745 Jarrett Lu 746 Oracle Corporation 747 4180 Network Circle 748 Santa Clara, CA 95054 749 USA 751 Email: jarrett.lu@oracle.com 753 Brian Ford 754 Lancope 755 3650 Brookside Parkway, Suite 500 756 Alpharetta, GA 30022 757 USA 759 Email: bford@lancope.com 761 Merike Kaeo 762 Double Shot Security 763 3518 Fremont Avenue North, Suite 363 764 Seattle, WA 98103 765 USA 767 Email: merike@doubleshotsecurity.com 769 8. Informative References 771 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 772 Information Models and Data Models", RFC 3444, DOI 773 10.17487/RFC3444, January 2003, 774 . 776 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 777 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 778 . 780 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 781 Tardo, "Network Endpoint Assessment (NEA): Overview and 782 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 783 . 785 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 786 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 787 March 2011, . 789 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 791 Appendix A. The Attic 793 The following terms are stashed for now and will be updated later: 795 Asset Characterization: Asset characterization is the process of 796 defining attributes that describe properties of an identified 797 asset. 799 Asset Targeting: Asset targeting is the use of asset identification 800 and categorization information to drive human-directed, automated 801 decision making for data collection and analysis in support of 802 endpoint posture assessment. 804 Client: An architectural component receiving services from another 805 architectural component. 807 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 808 The process by which an endpoint can be identified. 810 Authors' Addresses 812 Henk Birkholz 813 Fraunhofer SIT 814 Rheinstrasse 75 815 Darmstadt 64295 816 Germany 818 Email: henk.birkholz@sit.fraunhofer.de 820 Jarrett Lu 821 Oracle Corporation 822 4180 Network Circle 823 Santa Clara, CA 95054 824 USA 826 Email: jarrett.lu@oracle.com 828 Nancy Cam-Winget 829 Cisco Systems 830 3550 Cisco Way 831 San Jose, CA 95134 832 USA 834 Email: ncamwing@cisco.com