idnits 2.17.1 draft-ietf-sacm-terminology-16.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 (December 14, 2018) is 1931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 935, but not defined == Unused Reference: 'I-D.ietf-netmod-entity' is defined on line 1263, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-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 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational J. Lu 5 Expires: June 17, 2019 Oracle Corporation 6 J. Strassner 7 Huawei Technologies 8 N. Cam-Winget 9 Cisco Systems 10 A. Montville 11 CIS 12 December 14, 2018 14 Security Automation and Continuous Monitoring (SACM) Terminology 15 draft-ietf-sacm-terminology-16 17 Abstract 19 This memo documents terminology used in the documents produced by 20 SACM (Security Automation and Continuous Monitoring). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 17, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 61 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 62 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 65 8.2. Informative References . . . . . . . . . . . . . . . . . 28 66 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 29 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 69 1. Introduction 71 Our goal with this document is to improve our agreement on the 72 terminology used in documents produced by the IETF Working Group for 73 Security Automation and Continuous Monitoring. Agreeing on 74 terminology should help reach consensus on which problems we're 75 trying to solve, and propose solutions and decide which ones to use. 77 2. Terms and Definitions 79 This section describes terms that have been defined by other RFC's 80 and defines new ones. The predefined terms will reference the RFC 81 and where appropriate will be annotated with the specific context by 82 which the term is used in SACM. Note that explanatory or 83 informational augmentation to definitions are segregated from the 84 definitions themselves. The definition for the term immediately 85 follows the term on the same line, whereas expositional text is 86 contained in subsequent paragraphs immediately following the 87 definition. 89 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 90 entity without accompanying evidence of its validity". 92 In the context of SACM, an assertion is the output of a SACM 93 Component in the form of a SACM Statement (including metadata 94 about the data source and data origin, e.g. timestamps). While 95 the validity of an assertion about Content and Content Metadata 96 cannot be verified without, for example, Integrity Proofing of the 97 Data Source, an assertion (and therefore a SACM statement, 98 respectively) of the validity of Statement Metadata can by enabled 99 by including corresponding Integrity Evidence created by the Data 100 Origin. 102 Assessment: Defined in [RFC5209] as "the process of collecting 103 posture for a set of capabilities on the endpoint (e.g., host- 104 based firewall) such that the appropriate validators may evaluate 105 the posture against compliance policy." 107 Attribute: Is a data element, as defined in [RFC5209], that is 108 atomic. 110 In the context of SACM, attributes are "atomic" information 111 elements and an equivalent to attribute-value-pairs. Attributes 112 can be components of Subjects, the basic composite definitions 113 that are defined in the SACM Information Model. 115 Capability: A set of features that are available from a SACM 116 Component. 118 See also "capability" in [I-D.ietf-i2nsf-terminology]. 120 In the context of SACM, the extent of a SACM component's ability 121 is enabled by the functions it is composed of. Capabilities are 122 registered at a SACM broker (potentially also at a proxy or a 123 repository component if it includes broker functions) by a SACM 124 component via the SACM component registration task and can be 125 discovered by or negotiated with other SACM components via the 126 corresponding tasks. For example, the capability of a SACM 127 provider may be to provide target endpoint records (declarative 128 guidance about well-known or potential target endpoints), or only 129 a subset of that data. 131 A capability's description is in itself imperative guidance on 132 what functions are exposed to other SACM components in a SACM 133 domain and how to use them in workflows. 135 The SACM Vulnerability Assessment Scenario 136 [I-D.ietf-sacm-vuln-scenario] defines the terms Endpoint 137 Management Capabilities, Vulnerability Management Capabilities, 138 and Vulnerability Assessment Capabilities, which illustrate 139 specific sets of SACM capabilities on an enterprise IT 140 department's point of view and therefore compose sets of 141 declarative guidance. 143 Collection Result: Is a composition of one or more content elements 144 carrying information about a target endpoint, that is produced by 145 a collector when conducting a collection task. 147 Collection Task: A targeted task that collects attributes and/or 148 corresponding attribute values from target endpoint. 150 There are four types of frequency collection tasks can be 151 conducted with: 153 ad-hoc, e.g. triggered by a unsolicited query 155 conditional, e.g. triggered in accordance with policies included 156 in the compositions of workflows 158 scheduled, e.g. in regular intervals, such as every minute or 159 weekly 161 continuously, e.g. a network behavior observation 163 There are three types of collection methods, each requiring an 164 appropriate set of functions to be included in the SACM component 165 conducting the collection task: 167 Self-Reporting: A SACM component located on the target endpoint 168 itself conducts the collection task. 170 Remote-Acquisition: A SACM component located on an Endpoint 171 different from the target endpoint conducts the collection task 172 via interfaces available on the target endpoint, e.g. SNMP/ 173 NETCONF or WMI. 175 Behavior-Observation: A SACM component located on an Endpoint 176 different from the target endpoint observes network traffic 177 related to the target endpoint and conducts the collection task 178 via interpretation of that network traffic. 180 Collector: A piece of software that acquires information about one 181 or more target endpoints by conducting collection tasks. 183 A collector can be distributed across multiple endpoints, e.g. 184 across a target endpoint and a SACM component. The separate parts 185 of the collector can communicate with a specialized protocol, such 186 as PA-TNC [RFC5792]. At least one part of a distributed collector 187 has to take on the role of a provider of information by providing 188 SACM interfaces to propagate capabilities and to provide SACM 189 content in the form of collection results. 191 Configuration: A non-volatile subset of the endpoint attributes of a 192 endpoint that is intended to be unaffected by a normal reboot- 193 cycle. 195 Configuration is a type of imperative guidance that is stored in 196 files (files dedicated to contain configuration and/ or files that 197 are software components), directly on block devices, or on 198 specific hardware components that can be accessed via 199 corresponding software components. Modification of configuration 200 can be conducted manually or automatically via management (plane) 201 interfaces that support management protocols, such as SNMP or WMI. 202 A change of configuration can occur during both run-time and down- 203 time of an endpoint. It is common practice to scheduled a change 204 of configuration during or directly after the completion of a 205 boot-cycle via corresponding software components located on the 206 target endpoint itself. 208 Examples: The static association of an IP address and a MAC 209 address in a DHCP server configuration, a directory-path that 210 identifies a log-file directory, a registry entry. 212 Configuration Drift: The disposition of endpoint characteristics to 213 change over time. 215 Configuration drift exists for both hardware components and 216 software components. Typically, the frequency and scale of 217 configuration drift of software components is significantly higher 218 than the configuration drift of hardware components. 220 Consumer: A SACM Role that requires a SACM Component to include SACM 221 Functions enabling it to receive information from other SACM 222 Components. 224 Content Element: Content elements constitute the payload data (SACM 225 content) transferred via statement Subjects emitted by providers 226 of information. Every content element Subject includes a specific 227 content Subject and a corresponding content metadata Subject. 229 Content Metadata: Data about content Subjects. Every content- 230 element includes a content metadata Subject. The Subject can 231 include any information element that can annotate the content 232 transferred. Examples include time stamps or data provenance 233 Subjects. 235 Control Plane: An architectural component that provides common 236 control functions to all SACM components. 238 Typically used as a term in the context of routing, e.g. 239 [RFC6192]. SACM components may include authentication, 240 authorization, (capability) discovery or negotiation, registration 241 and subscription. The control plane orchestrates the flow on the 242 data plane according to imperative guidance (i.e. configuration) 243 received via the management plane. SACM components with 244 interfaces to the control plane have knowledge of the capabilities 245 of other SACM components within a SACM domain. 247 Controller: A controller is a SACM Role that is assigned to a SACM 248 component containing control plane functions managing and 249 facilitating information sharing or execute on security functions. 251 There are three types of SACM controllers: Broker, Proxy, and 252 Repository. Depending on its type, a controller can also contain 253 functions that have interfaces on the data plane. 255 Data Confidentiality: Defined in [RFC4949] as "the property that 256 data is not disclosed to system entities unless they have been 257 authorized to know the data." 259 Data In Motion: Data that is being transported via a network; also 260 referred to as "Data in Transit" or "Data in Flight". 262 Data in motion requires a data model to transfer the data using a 263 specific encoding. Typically, data in motion is serialized 264 (marshalling) into a transport encoding by a provider of 265 information and deserialized (unmarshalling) by a consumer of 266 information. The termination points of provider of information 267 and consumer of information data is transferred between are 268 interfaces. In regard to data in motion, the interpretation of 269 the roles consumer of information and provider of information 270 depends on the corresponding OSI layer (e.g. on layer2: between 271 interfaces connected to a broadcast domain, on layer4: between 272 interfaces that maintain a TCP connection). In the context of 273 SACM, consumer of information and provider of information are SACM 274 components. 276 Data At Rest: Data that is stored. 278 Data at rest requires a data model to encode the data to be 279 stored. In the context of SACM, data at rest located on a SACM 280 component can be provided to other SACM components via 281 discoverable capabilities. 283 Data Integrity: Defined in [RFC4949] as "the property that data has 284 not been changed, destroyed, or lost in an unauthorized or 285 accidental manner." 287 Data Origin: The SACM Component that initially acquired or produced 288 data about an endpoint. 290 Data Origin enables a SACM component to identify the SACM 291 component that initially acquired or produced data about a 292 (target) endpoint (e.g. via collection from a data source) and 293 made it available to a SACM domain via a SACM statement. Data 294 Origin can be expressed by an endpoint label information element 295 (e.g. to be used as metadata in statement). 297 Data Plane: Is an architectural component providing operational 298 functions enabling information exchange that is not command and 299 control or management related. 301 Typically used as a term in the context of routing (and used as a 302 synonym for forwarding plane, e.g. [RFC6192]). In the context of 303 SACM, the data plane is an architectural component providing 304 operational functions to enable a SACM component to provide and 305 consume SACM statements and therefore SACM content, which composes 306 the actual SACM content. The data plane in a SACM domain is used 307 to conduct distributed SACM tasks by transporting SACM content via 308 specific transport encodings and corresponding operations defined 309 by SACM data models. 311 Data Provenance: An historical record of the sources, origins and 312 evolution, as it pertains to data, that is influenced by inputs, 313 entities, functions and processes. 315 Additional Information - In the context of SACM, data provenance 316 is expressed as metadata that identifies SACM statements and 317 corresponding content elements a new statement is created from. 318 In a downstream process, this references can cascade, creating a 319 data provenance tree that enables SACM components to trace back 320 the original data sources involved in the creation of SACM 321 statements and take into account their characteristics and 322 trustworthiness. 324 Data Source: Is an endpoint from which a particular set of 325 attributes and/or attribute values have been collected. 327 Data Source enables a SACM component to identify - and potentially 328 characterize - a (target) endpoint that is claimed to be the 329 original source of endpoint attributes in a SACM statement. Data 330 Source can be expressed as metadata by an endpoint label 331 information element or a corresponding subject of identifying 332 endpoint attributes. 334 Endpoint: Defined in [RFC5209] as "any computing device that can be 335 connected to a network." 337 Additional Information - The [RFC5209] definition continues, "Such 338 devices normally are associated with a particular link layer 339 address before joining the network and potentially an IP address 340 once on the network. This includes: laptops, desktops, servers, 341 cell phones, or any device that may have an IP address." 343 To further clarify the [RFC5209] definition, an endpoint is any 344 physical or virtual device that may have a network address. Note 345 that, network infrastructure devices (e.g. switches, routers, 346 firewalls), which fit the definition, are also considered to be 347 endpoints within this document. 349 Physical endpoints are always composites that are composed of 350 hardware components and software components. Virtual endpoints 351 are composed entirely of software components and rely on software 352 components that provide functions equivalent to hardware 353 components. 355 The SACM architecture differentiates two essential categories of 356 endpoints: Endpoints whose security posture is intended to be 357 assessed (target endpoints) and endpoints that are specifically 358 excluded from endpoint posture assessment (excluded endpoints). 360 Based on the definition of an asset, an endpoint is a type of 361 asset. 363 Endpoint Attribute: Is a discreet endpoint characteristic that is 364 computably observable. 366 Endpoint Attributes typically constitute Attributes that can be 367 bundled into Subject (e.g. information about a specific network 368 interface can be represented via a set of multiple AVP). 370 Endpoint Characteristics: The state, configuration and composition 371 of the software components and (virtual) hardware components a 372 target endpoint is composed of, including observable behavior, 373 e.g. sys-calls, log-files, or PDU emission on a network. 375 In SACM work-flows, (Target) Endpoint Characteristics are 376 represented via Information Elements. 378 Endpoint Characterization Task: The task of endpoint 379 characterization that uses endpoint attributes that represent 380 distinct endpoint characteristics. 382 Endpoint Classification: The categorization of of the endpoint into 383 one or more taxonomic structures. 385 Endpoint classification requires declarative guidance in the form 386 of an endpoint profile, discovery results and potentially 387 collection results. Types, classes or the characteristics of an 388 individual target endpoint are defined via endpoint profiles. 390 Endpoint Classification Task: The task of endpoint classification 391 that uses an endpoint's characteristics to determine how to 392 categorize the given endpoint into one or more taxonomic 393 structures. 395 Endpoint Label: A unique label associated with a unique endpoint. 397 Endpoint specializations have corresponding endpoint label 398 specializations. For example, an endpoint label used on a SACM 399 Component is a SACM Component Label. 401 Endpoint Management Capabilities: Enterprise IT management 402 capabilities that are tailored to manage endpoint identity, 403 endpoint information, and associated metadata. 405 Evaluation Task: A task by which an endpoint's asserted attribute 406 value is evaluated against a policy-compliant attribute value. 408 Evaluation Result: The resulting value from having evaluated a set 409 of posture attributes. 411 Expected Endpoint Attribute State: The policy-compliant state of an 412 endpoint attribute that is to be compared against. 414 Sets of expected endpoint attribute states are transported as 415 declarative guidance in target endpoint profiles via the 416 management plane. This, for example, can be a policy, but also a 417 recorded past state. An expected state is represented by an 418 Attribute or a Subject that represents a set of multiple attribute 419 value pairs. 421 Guidance: Machine-processable input directing SACM processes or 422 tasks. 424 Examples of such processes/tasks include automated device 425 management, remediation, collection, evaluation. Guidance 426 influences the behavior of a SACM Component and is considered 427 content of the management plane. In the context of SACM, guidance 428 is machine-readable and can be manually or automatically generated 429 or provided. Typically, the tasks that provide guidance to SACM 430 components have a low-frequency and tend to be sporadic. 432 There are two types of guidance: 434 Declarative Guidance: Guidance that defines the configuration or 435 state an endpoint is supposed to be in, without providing specific 436 actions or methods to produce that desired state. Examples 437 include Target Endpoint Profiles or network topology based 438 requirements. 440 Imperative Guidance: Guidance that prescribes specific actions to 441 be conducted or methods to be used in order to achieve an outcome. 442 Examples include a targeted Collection Task or the IP-Address of a 443 SACM Component that provides a registration function. 445 Prominent examples include: modification of the configuration of a 446 SACM component or updating a target endpoint profile that resides 447 on an evaluator. In essence, guidance is transported via the 448 management plane. 450 Endpoint Hardware Inventory: The set of hardware components that 451 compose a specific endpoint representing its hardware 452 configuration. 454 Hardware Component: A distinguishable physical component used to 455 compose an endpoint. 457 The composition of an endpoint can be changed over time by adding 458 or removing hardware components. In essence, every physical 459 endpoint is potentially a composite of multiple hardware 460 components, typically resulting in a hierarchical composition of 461 hardware components. The composition of hardware components is 462 based on interconnects provided by specific hardware types (e.g. 463 FRU in a chassis are connected via redundant busses). In general, 464 a hardware component can be distinguished by its serial number. 465 Occasionally, hardware components are referred to as power sucking 466 aliens. 468 Information Element: A representation of information about physical 469 and virtual "objects of interest". 471 Information elements are the building blocks that constitute the 472 SACM information model. In the context of SACM, an information 473 element that expresses a single value with a specific name is 474 referred to as an Attribute (analogous to an attribute-value- 475 pair). A set of attributes that is bundled into a more complex 476 composite information element is referred to as a Subject. Every 477 information element in the SACM information model has a unique 478 name. Endpoint attributes or time stamps, for example, are 479 represented as information elements in the SACM information model. 481 Information Model: An abstract representation of data, their 482 properties, relationships between data and the operations that can 483 be performed on the data. 485 While there is some overlap with a data model, [RFC3444] 486 distinguishes an information model as being protocol and 487 implementation neutral whereas a data model would provide such 488 details. The purpose of the SACM information model is to ensure 489 interoperability between SACM data models (that are used as 490 transport encoding) and to provide a standardized set of 491 information elements for communication between SACM components. 493 Interaction Model: The definition of specific sequences regarding 494 the exchange of messages (data in motion), including, for example, 495 conditional branching, thresholds and timers. 497 An interaction model, for example, can be used to define 498 operations, such as registration or discovery, on the control 499 plane. A composition of data models for data in motion and a 500 corresponding interaction model is a protocol. 502 Internal Collector: A collector that runs on a target endpoint to 503 acquire information from that target endpoint. 505 Management Plane: An architectural component providing common 506 functions to steer the behavior of SACM components, e.g. their 507 behavior on the control plane. 509 Typically, a SACM component can fulfill its purpose without 510 continuous input from the management plane. In contrast, without 511 continuous availability of control plane functions a typical SACM 512 component could not function properly. In general, interaction on 513 the management plane is less frequent and less regular than on the 514 control plane. Input via the management plane can be manual (e.g. 515 via a CLI), or can be automated via management plane functions 516 that are part of other SACM components. 518 Network Address: A layer-specific address that follows a layer- 519 specific address scheme. 521 The following characteristics are a summery derived from the 522 Common Information Model and ITU-T X.213. Each Network Interface 523 of a specific layer can be associated with one or more addresses 524 appropriate for that layer. There is no guarantee that a network 525 address is globally unique. A dedicated authority entity can 526 provide a level of assurance that a network address is unique in 527 its given scope. In essence, there is always a scope to a network 528 address, in which it is intended to be unique. 530 Examples include: physical Ethernet port with a MAC address, layer 531 2 VLAN interface with a MAC address, layer 3 interface with 532 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 533 IPv4 address. 535 Network Interface: An Endpoint is connected to a network via one or 536 more Network Interfaces. Network Interfaces can be physical 537 (Hardware Component) or logical (virtual Hardware component, i.e. 538 a dedicated Software Component). Network Interfaces of an 539 Endpoint can operate on different layers, most prominently what is 540 now commonly called layer 2 and 3. Within a layer, interfaces can 541 be nested. 543 In SACM, the association of Endpoints and Network Addresses via 544 Network Interfaces is vital to maintain interdependent autonomous 545 processes that can be targeted at Target Endpoints, unambiguously. 547 Examples include: physical Ethernet port, layer 2 VLAN interface, 548 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 550 Metadata: Data about data. 552 In the SACM information model, data is referred to as Content. 553 Metadata about the content is referred to as Content-Metadata, 554 respectively. Content and Content-Metadata are combined into 555 Subjects called Content-Elements in the SACM information model. 556 Some information elements defined by the SACM information model 557 can be part of the Content or the Content-Metadata. Therefore, if 558 an information element is considered data or data about data 559 depends on which kind of Subject it is associated with. The SACM 560 information model also defines metadata about the data origin via 561 the Subject Statement-Metadata. Typical examples of metadata are 562 time stamps, data origin or data source. 564 Posture: Defined in [RFC5209] as "configuration and/or status of 565 hardware or software on an endpoint as it pertains to an 566 organization's security policy." 568 This term is used within the scope of SACM to represent the 569 configuration and state information that is collected from a 570 target endpoint in the form of endpoint attributes (e.g. software/ 571 hardware inventory, configuration settings, dynamically assigned 572 addresses). This information may constitute one or more posture 573 attributes. 575 Posture Attributes: Defined in [RFC5209] as "attributes describing 576 the configuration or status (posture) of a feature of the 577 endpoint. A Posture Attribute represents a single property of an 578 observed state. For example, a Posture Attribute might describe 579 the version of the operating system installed on the system." 581 Within this document this term represents a specific assertion 582 about endpoint configuration or state (e.g. configuration setting, 583 installed software, hardware) represented via endpoint attributes. 584 The phrase "features of the endpoint" highlighted above refers to 585 installed software or software components. 587 Provider: A provider is a SACM role assigned to a SACM component 588 that provides role-specific functions to provide information to 589 other SACM components. 591 Repository: A repository is a controller that contains functions to 592 consume, store and provide information of a particular kind. 594 Such information is typically data transported on the data plane, 595 but potentially also data and metadata from the control and 596 management plane. A single repository may provide the functions 597 of more than one specific repository type (i.e. configuration 598 baseline repository, assessment results repository, etc.) 600 SACM Broker Controller: A SACM Broker Controller is a controller 601 that contains control plane functions to provide and/or connect 602 services on behalf of other SACM components via interfaces on the 603 control plane. 605 A broker may provide, for example, authorization services and 606 find, upon request, SACM components providing requested services. 608 SACM Component: Is a component, as defined in 609 [I-D.ietf-i2nsf-terminology], that is composed of SACM 610 capabilities. 612 In the context of SACM, a set of SACM functions composes a SACM 613 component. A SACM component conducts SACM tasks, acting on 614 control plane, data plane and/or management plane via 615 corresponding SACM interfaces. SACM defines a set of standard 616 components (e.g. a collector, a broker, or a data store). A SACM 617 component contains at least a basic set of control plane functions 618 and can contain data plane and management plane functions. A SACM 619 component residing on an endpoint assigns one or more SACM roles 620 to the corresponding endpoint due to the SACM functions it is 621 composed of. A SACM component "resides on" an endpoint and an 622 endpoint "contains" a SACM component, correspondingly. For 623 example, a SACM component that is composed solely of functions 624 that provide information would only take on the role of a 625 provider. 627 SACM Component Discovery: The task of discovering the capabilities 628 provided by SACM components within a SACM domain. 630 This is likely to be performed via an appropriate set of control 631 plane functions. 633 SACM Component Label: A specific endpoint label that is used to 634 identify a SACM component. 636 In content-metadata, this label is called data origin. 638 SACM Content: The payload provided by SACM components to the SACM 639 domain on the data plane. 641 SACM content includes the SACM data models. 643 SACM Domain: Endpoints that include a SACM component compose a SACM 644 domain. 646 (To be revised, additional definition content TBD, possible 647 dependencies to SACM architecture) 649 SACM Function: A behavioral aspect of a SACM component that provides 650 external SACM Interfaces or internal interfaces to other SACM 651 Functionse. 653 For example, a SACM Function with SACM Interfaces on the Control 654 Plane can provide a brokering function to other SACM Components. 655 Via Data Plane interfaces, a SACM Function can act as a provider 656 and/or as a consumer of information. SACM Functions can be 657 propagated as the Capabilities of a SACM Component and can be 658 discovered by or negotiated with other SACM Components. 660 SACM Interface: An interface, as defined in 661 [I-D.ietf-i2nsf-terminology], that provides SACM-specific 662 operations. 664 [I-D.ietf-i2nsf-terminology] defines interface as a "set of 665 operations one object knows it can invoke on, and expose to, 666 another object," and further defines interface by stating that an 667 interface "decouples the implementation of the operation from its 668 specification. An interface is a subset of all operations that a 669 given object implements. The same object may have multiple types 670 of interfaces to serve different purposes." 672 In the context of SACM, SACM Functions provide SACM Interfaces on 673 the management, control, or data plane. Operations a SACM 674 Interface provides are based on corresponding data model defined 675 by SACM. SACM Interfaces are used for communication between SACM 676 components. 678 SACM Proxy Controller: A SACM Proxy Controller is a controller that 679 provides data plane and control plane functions, information, or 680 services on behalf of another component, which is not directly 681 participating in the SACM architecture. 683 SACM Role: Is a role, as defined in [I-D.ietf-i2nsf-terminology], 684 that requires the SACM Component assuming the role to bear a set 685 of SACM functions or interfaces. 687 SACM Roles provide three important benefits. First, it enables 688 different behavior to be supported by the same Component for 689 different contexts. Second, it enables the behavior of a 690 Component to be adjusted dynamically (i.e., at runtime, in 691 response)to changes in context, by using one or more Roles to 692 define the behavior desired for each context. Third, it decouples 693 the Roles of a Component from the Applications that use that 694 Component." 696 In the context of SACM, SACM roles are associated with SACM 697 components and are defined by the set of functions and interfaces 698 a SACM component includes. There are three SACM roles: provider, 699 consumer, and controller. The roles associated with a SACM 700 component are determined by the purpose of the SACM functions and 701 corresponding SACM interfaces the SACM component is composed of. 703 SACM Statement: Is an assertion that is made by a SACM Component. 705 Security Automation: The process of which security alerts can be 706 automated through the use of different components to monitor, 707 analyze and assess endpoints and network traffic for the purposes 708 of detecting misconfigurations, misbehaviors or threats. 710 Security Automation is intended to identify target endpoints that 711 cannot be trusted (see "trusted" in [RFC4949]. This goal is 712 achieved by creating and processing evidence (assessment 713 statements) that a target endpoint is not a trusted system 714 [RFC4949]. 716 Software Package: A generic software package (e.g. a text editor). 718 Software Component: A software package installed on an endpoint. 720 The software component may include a unique serial number (e.g. a 721 text editor associated with a unique license key). 723 Software Instance: A running instance of a software component. 725 For example, on a multi-user system, one logged-in user has one 726 instance of a text editor running and another logged-in user has 727 another instance of the same text editor running, or on a single- 728 user system, a user could have multiple independent instances of 729 the same text editor running. 731 State: A volatile set of endpoint attributes of a (target) endpoint 732 that is affected by a reboot-cycle. 734 Local state is created by the interaction of components with other 735 components via the control plane, via processing data plane 736 payload, or via the functional properties of local hardware and 737 software components. Dynamic configuration (e.g. IP address 738 distributed dynamically via an address distribution and management 739 services, such as DHCP) is considered state that is the result of 740 the interaction with another component (e.g. provided by a DHCP 741 server with a specific configuration). 743 Examples: The static association of an IP address and a MAC 744 address in a DHCP server configuration, a directory-path that 745 identifies a log-file directory, a registry entry. 747 Statement: A statement is the root/top-level subject defined in the 748 SACM information model. 750 A statement is used to bundle Content Elements into one subject 751 and includes metadata about the data origin. 753 Subject: A semantic composite information element pertaining to a 754 system entity that is a target endpoint. 756 Like Attributes, subjects have a name and are composed of 757 attributes and/or other subjects. Every IE that is part of a 758 subject can have a quantitiy associated with it (e.g. zero-one, 759 none-unbounded). The content IE of a subject can be an unordered 760 or an ordered list. 762 In contrast to the definitions of subject provided by [RFC4949], a 763 subject in the scope of SACM is neither "a system entity that 764 causes information to flow among objects or changes the system 765 state" nor "a name of a system entity that is bound to the data 766 items in a digital certificate". 768 In the context of SACM, a subject is a semantic composite of 769 information elements about a system entity that is a target 770 endpoint. Every acquirable subject-as defined in the scope of 771 SACM-about a target endpoint represents and therefore identifies 772 every subject-as defined by [RFC4949]-that is a component of that 773 target endpoint. The semantic difference between both definitions 774 can be subtle in practice and is in consequence important to 775 highlight. 777 Supplicant: A component seeking to be authenticated via the control 778 plane for the purpose of participating in a SACM domain. 780 System Resource: Defined in [RFC4949] as "data contained in an 781 information system; or a service provided by a system; or a system 782 capacity, such as processing power or communication bandwidth; or 783 an item of system equipment (i.e., hardware, firmware, software, 784 or documentation); or a facility that houses system operations and 785 equipment." 787 Target Endpoint: Is an endpoint that is under assessment at some 788 point in, or region of, time. 790 Every endpoint that is not specifically designated as an excluded 791 endpoint is a target endpoint. A target endpoint is not part of a 792 SACM domain unless it contains a SACM component (e.g. a SACM 793 component that publishes collection results coming from an 794 internal collector). 796 A target endpoint is similar to a device that is a Target of 797 Evaluation (TOE) as defined in Common Criteria and as referenced 798 by {{RFC4949}. 800 Target Endpoint Address: An address that is layer specific and which 801 follows layer specific address schemes. 803 Each interface of a specific layer can be associated with one or 804 more addresses appropriate for that layer. There is no guarantee 805 that an address is globally unique. In general, there is a scope 806 to an address in which it is intended to be unique. 808 Examples include: physical Ethernet port with a MAC address, layer 809 2 VLAN interface with a MAC address, layer 3 interface with 810 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 811 IPv4 address. 813 Target Endpoint Characterization: The description of the distinctive 814 nature of a target endpoint, that is based on its characteristics. 816 Target Endpoint Characterization Record: A set of endpoint 817 attributes about a target endpoint that was encountered in a SACM 818 domain, which are associated with that target endpoint as a result 819 of a Target Endpoint Characterization Task. 821 A characterization record is intended to be a representation of an 822 endpoint. It cannot be assured that a record distinctly 823 represents a single target endpoint unless a set of one or more 824 endpoint attributes that compose a unique set of identifying 825 endpoint attributes are included in the record. Otherwise, the 826 set of identifying attributes included in a record can match more 827 than one target endpoints, which are - in consequence - 828 indistinguishable to a SACM domain until more qualifying endpoint 829 attributes can be acquired and added to the record. A 830 characterization record is maintained over time in order to assert 831 that acquired endpoint attributes are either about an endpoint 832 that was encountered before or an endpoint that has not been 833 encountered before in a SACM domain. A characterization record 834 can include, for example, acquired configuration, state or 835 observed behavior of a specific target endpoint. Multiple and 836 even conflicting instances of this information can be included in 837 a characterization record by using timestamps and/or data origins 838 to differentiate them. The endpoint attributes included in a 839 characterization record can be used to re-identify a distinct 840 target endpoint over time. Classes or profiles can be associated 841 with a characterization record via the Classification Task in 842 order to guide collection, evaluation or remediation tasks. 844 Target Endpoint Characterization Task: An ongoing task of 845 continuously adding acquired endpoint attributes to a 846 corresponding record. The TE characterization task manages the 847 representation of encountered target endpoints in the SACM domain 848 in the form of characterization records. For example, the output 849 of a target endpoint discovery task or a collection task can be 850 processed by the characterization task and added to the record. 851 The TE characterization Task also manages these representations of 852 target endpoints encountered in the SACM domain by splitting or 853 merging the corresponding records as new or more refined endpoint 854 attributes become available. 856 Target Endpoint Classification Task: The task of associating a class 857 from an extensible list of classes with an endpoint 858 characterization record. TE classes function as imperative and 859 declarative guidance for collection, evaluation, remediation and 860 security posture assessment in general. 862 Target Endpoint Discovery Task: The ongoing task of detecting 863 previously unknown interaction of a potential target endpoint in 864 the SACM domain. TE Discovery is not directly targeted at a 865 specific target endpoint and therefore an un-targeted task. SACM 866 Components conducting the discovery task as a part of their 867 function are typically distributed and located, for example, on 868 infrastructure components or collect from those remotely via 869 appropriate interfaces. Examples of infrastructure components 870 that are of interest to the discovery task include routers, 871 switches, VM hosting or VM managing components, AAA servers, or 872 servers handling dynamic address distribution. 874 Target Endpoint Identifier: The target endpoint discovery task and 875 the collection tasks can result in a set of identifying endpoint 876 attributes added to a corresponding Characterization Record. This 877 subset of the endpoint attributes included in the record is used 878 as a target endpoint identifier, by which a specific target 879 endpoint can be referenced. Depending on the available 880 identifying attributes, this reference can be ambiguous and is a 881 "best-effort" mechanism. Every distinct set of identifying 882 endpoint attributes can be associated with a target endpoint label 883 that is unique in a SACM domain. 885 Target Endpoint Label: An endpoint label that identifies a specific 886 target endpoint. 888 Target Endpoint Profile: A bundle of expected or desired component 889 composition, configurations and states that is associated with a 890 target endpoint. 892 The corresponding task by which the association with a target 893 endpoint takes places is the endpoint classification task. The 894 task by which an endpoint profile is created is the endpoint 895 characterization task. A type or class of target endpoints can be 896 defined via a target endpoint profile. Examples include: 897 printers, smartphones, or an office PC. 899 In respect to [RFC4949], a target endpoint profile is a protection 900 profile as defined by Common Criteria (analogous to the target 901 endpoint being the target of evaluation). 903 SACM Task: Is a task conducted within the scope of a SACM domain by 904 one or more SACM functions that achieves a SACM-defined outcome. 906 A SACM task can be triggered by other operations or functions 907 (e.g. a query from another SACM component or an unsolicited push 908 on the data plane due to an ongoing subscription). A task is part 909 of a SACM process chain. A task starts at a given point in time 910 and ends in a deterministic state. With the exception of a 911 collection task, a SACM task consumes SACM statements provided by 912 other SACM components. The output of a task is a result that can 913 be provided (e.g. published) on the data plane. 915 The following tasks are defined by SACM: 917 Target Endpoint Discovery 919 Target Endpoint Characterization 921 Target Endpoint Classification 923 Collection 925 Evaluation [TBD] 927 Information Sharing [TBD] 929 SACM Component Discovery 931 SACM Component Authentication [TBD] 933 SACM Component Authorization [TBD] 935 SACM Component Registration [TBD] 937 Timestamps : Defined in [RFC4949] as "with respect to a data object, 938 a label or marking in which is recorded the time (time of day or 939 other instant of elapsed time) at which the label or marking was 940 affixed to the data object". 942 A timestamp always requires context, i.e. additional information 943 elements that are associated with it. Therefore, all timestamps 944 wrt information elements are always metadata. Timestamps in SACM 945 Content Elements may be generated outside a SACM Domain and may be 946 encoded in an unknown representation. Inside a SACM domain the 947 representation of timestamps is well-defined and unambiguous. 949 Virtual Endpoint: An endpoint composed entirely of logical system 950 components (see [RFC4949]). 952 The most common example is a virtual machine/host running on a 953 target endpoint. Effectively, target endpoints can be nested and 954 at the time of this writing the most common example of target 955 endpoint characteristics about virtual components is the 956 EntLogicalEntry in [RFC6933]. 958 Vulnerability Assessment: An assessment specifically tailored to 959 determining whether a set of endpoints is vulnerable according to 960 the information contained in the vulnerability description 961 information. 963 Vulnerability Description Information: Information pertaining to the 964 existence of a flaw or flaws in software, hardware, and/or 965 firmware, which could potentially have an adverse impact on 966 enterprise IT functionality and/or security. 968 Vulnerability description information should contain enough 969 information to support vulnerability detection. 971 Vulnerability Detection Data: A type of imperative guidance 972 extracted or derived from vulnerability description information 973 that describes the specific mechanisms of vulnerability detection 974 that is used by an enterprise's vulnerability management 975 capabilities to determine if a vulnerability is present on an 976 endpoint. 978 Vulnerability Management Capabilities: An IT management capability 979 tailored toward managing endpoint vulnerabilities and associated 980 metadata on an ongoing basis by ingesting vulnerability 981 description information and vulnerability detection data, and 982 performing vulnerability assessments. 984 Vulnerability assessment capabilities: An assessment capability that 985 is tailored toward determining whether a set of endpoints is 986 vulnerable according to vulnerability description information. 988 Workflow: A workflow is a modular composition of tasks that can 989 contain loops, conditionals, multiple starting points and multiple 990 endpoints. 992 The most prominent workflow in SACM is the assessment workflow. 994 3. IANA Considerations 996 This memo includes no request to IANA. 998 4. Security Considerations 1000 This memo documents terminology for security automation. While it is 1001 about security, it does not affect security. 1003 5. Acknowledgements 1005 6. Change Log 1007 Changes from version 00 to version 01: 1009 o Added simple list of terms extracted from UC draft -05. It is 1010 expected that comments will be received on this list of terms as 1011 to whether they should be kept in this document. Those that are 1012 kept will be appropriately defined or cited. 1014 Changes from version 01 to version 02: 1016 o Added Vulnerability, Vulnerability Management, xposure, 1017 Misconfiguration, and Software flaw. 1019 Changes from version 02 to version 03: 1021 o Removed Section 2.1. Cleaned up some editing nits; broke terms 1022 into 2 sections (predefined and newly defined terms). Added some 1023 of the relevant terms per the proposed list discussed in the IETF 1024 89 meeting. 1026 Changes from version 03 to version 04: 1028 o TODO 1030 Changes from version 04 to version 05: 1032 o TODO 1034 Changes from version 05 to version 06: 1036 o Updated author information. 1038 o Combined "Pre-defined Terms" with "New Terms and Definitions". 1040 o Removed "Requirements language". 1042 o Removed unused reference to use case draft; resulted in removal of 1043 normative references. 1045 o Removed introductory text from Section 1 indicating that this 1046 document is intended to be temporary. 1048 o Added placeholders for missing change log entries. 1050 Changes from version 06 to version 07: 1052 o Added Contributors section. 1054 o Updated author list. 1056 o Changed title from "Terminology for Security Assessment" to 1057 "Secure Automation and Continuous Monitoring (SACM) Terminology". 1059 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 1061 o Added appendix The Attic to stash terms for future updates. 1063 o Added Authentication, Authorization, Data Confidentiality, Data 1064 Integrity, Data Origin, Data Provenance, SACM Component, SACM 1065 Component Discovery, Target Endpoint Discovery. 1067 o Major updates to Building Block, Function, SACM Role, Target 1068 Endpoint. 1070 o Minor updates to Broker, Capability, Collection Task, Evaluation 1071 Task, Posture. 1073 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 1074 Endpoint Discovery to Endpoint Identification. 1076 o Moved Asset Targeting, Client, Endpoint Identification to The 1077 Attic. 1079 o Endpoint Attributes added as a TODO. 1081 o Changed the structure of the Change Log. 1083 Changes from version 07 to version 08: 1085 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 1086 Internal Collector, Network Address, Network Interface, SACM 1087 Domain, Statement, Target Endpoint Identifier, Target Endpoint 1088 Label, Timestamp. 1090 o Major updates to Attributes, Broker, Collection Task, Consumer, 1091 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 1092 State, SACM Function, Provider, Proxy, Repository, SACM Role, 1093 Target Endpoint. 1095 o Minor updates to Asset, Building Block, Data Origin, Data Source, 1096 Data Provenance, Endpoint, Management Plane, Posture, Posture 1097 Attribute, SACM Component, SACM Component Discovery, Target 1098 Endpoint Discovery. 1100 o Relabeled Function to SACM Function. 1102 Changes from version 08 to version 09: 1104 o Updated author list. 1106 o Added Data Plane, Endpoint Characterization, Endpoint 1107 Classification, Guidance, Interaction Model, Software Component, 1108 Software Instance, Software Package, Statement, Target Endpoint 1109 Profile, SACM Task. 1111 o Removed Building Block. 1113 o Major updates to Control Plane, Endpoint Attribute, Expected 1114 Endpoint State, Information Model, Management Plane. 1116 o Minor updates to Attribute, Capabilities, SACM Function, SACM 1117 Component, Collection Task. 1119 o Moved Asset Characterization to The Attic. 1121 Changes from version 09 to version 10: 1123 o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint 1124 Management Capability, Hardware Component, Hardware Inventory, 1125 Hardware Type, SACM Interface, Target Endpoint Characterization 1126 Record, Target Endpoint Characterization Task, Target Endpoint 1127 Classification Task, Target Endpoint Discovery Task, Vulnerability 1128 Description Information, Vulnerability Detection Data, 1129 Vulnerability Management Capability, Vulnerability Assessment 1131 o Added references to i2nsf definitions in Capability, SACM 1132 Component, SACM Interface, SACM Role. 1134 o Added i2nsf Terminology I-D Reference. 1136 o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier. 1138 o Minor Updates to Guidance, SACM Component Discovery, Target 1139 Endpoint Label, Target Endpoint Profile. 1141 o Relabeled SACM Task 1143 o Removed Target Endpoint Discovery 1145 Changes from version 10 to version 11: 1147 o Added Content Element, Content Metadata, Endpoint Label, 1148 Information Element, Metadata, SACM Component Label, Workflow. 1150 o Major Updates to Assessment, Capability, Collector, Endpoint 1151 Management Capabilities, Guidance, Vulnerability Assessment 1152 Capabilities, Vulnerability Detection Data, Vulnerability 1153 Assessment Capabilities. 1155 o Minor updates to Collection Result, Control Plane, Data in Motion, 1156 Data at Rest, Data Origin, Network Interface, Statement, Target 1157 Endpoint Label. 1159 o Relabeled Endpoint Management Capability, Vulnerability Management 1160 Capability, Vulnerability Assessment. 1162 Changes from version 11 to version 12: 1164 o Added Configuration, Endpoint Characteristic, Event, SACM Content, 1165 State, Subject. 1167 o Major Updates to Assertion, Data in Motion, Data Provenance, Data 1168 Source, Interaction Model. 1170 o Minor Updates to Attribute, Control Plane, Data Origin, Data 1171 Provenance, Expected Endpoint State, Guidance, Target Endpoint 1172 Classification Task, Vulnerability Detection Data. 1174 Changes from version 12 to version 13: 1176 o Added Virtual Component. 1178 o Major Updates to Capability, Collection Task, Hardware Component, 1179 Hardware Type, Security Automation, Subject, Target Endpoint, 1180 Target Endpoint Profile. 1182 o Minor Updates to Assertion, Data Plane, Endpoint Characteristics. 1184 Changes from version 13 to version 14: 1186 o Handled a plethora of issues listed in GitHub. 1188 o Pruned some commonly understood terms. 1190 o Narrowing term labels per their definitions. 1192 o In some cases, excised expositional text. 1194 o Where expositional text was left intact, it has been separated 1195 from the actual definition of a term. 1197 Changes from version 14 to version 16: 1199 o moved obsolete definitions into the Appendix (attic). 1201 7. Contributors 1202 David Waltermire 1203 National Institute of Standards and Technology 1204 100 Bureau Drive 1205 Gaithersburg, MD 20877 1206 USA 1208 Email: david.waltermire@nist.gov 1210 Adam W. Montville 1211 Center for Internet Security 1212 31 Tech Valley Drive 1213 East Greenbush, NY 12061 1214 USA 1216 Email: adam.w.montville@gmail.com 1218 David Harrington 1219 Effective Software 1220 50 Harding Rd 1221 Portsmouth, NH 03801 1222 USA 1224 Email: ietfdbh@comcast.net 1226 Brian Ford 1227 Lancope 1228 3650 Brookside Parkway, Suite 500 1229 Alpharetta, GA 30022 1230 USA 1232 Email: bford@lancope.com 1234 Merike Kaeo 1235 Double Shot Security 1236 3518 Fremont Avenue North, Suite 363 1237 Seattle, WA 98103 1238 USA 1240 Email: merike@doubleshotsecurity.com 1242 8. References 1243 8.1. Normative References 1245 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1246 (PA) Protocol Compatible with Trusted Network Connect 1247 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1248 . 1250 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1251 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1252 DOI 10.17487/RFC6933, May 2013, 1253 . 1255 8.2. Informative References 1257 [I-D.ietf-i2nsf-terminology] 1258 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1259 Birkholz, "Interface to Network Security Functions (I2NSF) 1260 Terminology", draft-ietf-i2nsf-terminology-06 (work in 1261 progress), July 2018. 1263 [I-D.ietf-netmod-entity] 1264 Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1265 YANG Data Model for Hardware Management", draft-ietf- 1266 netmod-entity-08 (work in progress), January 2018. 1268 [I-D.ietf-sacm-vuln-scenario] 1269 Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., 1270 Fitzgerald-McKay, J., and D. Waltermire, "SACM 1271 Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- 1272 scenario-02 (work in progress), September 2016. 1274 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1275 Information Models and Data Models", RFC 3444, 1276 DOI 10.17487/RFC3444, January 2003, 1277 . 1279 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1280 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1281 . 1283 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1284 Tardo, "Network Endpoint Assessment (NEA): Overview and 1285 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1286 . 1288 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1289 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1290 March 2011, . 1292 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 1294 Appendix A. The Attic 1296 The following terms are stashed for now and will be updated later: 1298 Asset: Is a system resource, as defined in [RFC4949], that may be 1299 composed of other assets. 1301 Examples of Assets include: Endpoints, Software, Guidance, or 1302 X.509 public key certificates. An asset is not necessarily owned 1303 by an organization. 1305 Asset Management: The IT process by which assets are provisioned, 1306 updated, maintained and deprecated. 1308 Asset Characterization: Asset characterization is the process of 1309 defining attributes that describe properties of an identified 1310 asset. 1312 Asset Targeting: Asset targeting is the use of asset identification 1313 and categorization information to drive human-directed, automated 1314 decision making for data collection and analysis in support of 1315 endpoint posture assessment. 1317 Client: An architectural component receiving services from another 1318 architectural component. 1320 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 1321 The process by which an endpoint can be identified. 1323 Authors' Addresses 1325 Henk Birkholz 1326 Fraunhofer SIT 1327 Rheinstrasse 75 1328 Darmstadt 64295 1329 Germany 1331 Email: henk.birkholz@sit.fraunhofer.de 1332 Jarrett Lu 1333 Oracle Corporation 1334 4180 Network Circle 1335 Santa Clara, CA 95054 1336 USA 1338 Email: jarrett.lu@oracle.com 1340 John Strassner 1341 Huawei Technologies 1342 2330 Central Expressway 1343 Santa Clara, CA 95138 1344 USA 1346 Email: john.sc.strassner@huawei.com 1348 Nancy Cam-Winget 1349 Cisco Systems 1350 3550 Cisco Way 1351 San Jose, CA 95134 1352 USA 1354 Email: ncamwing@cisco.com 1356 Adam Montville 1357 Center for Internet Security 1358 31 Tech Valley Drive 1359 East Greenbush, NY 12061 1360 USA 1362 Email: adam.w.montville@gmail.com