idnits 2.17.1 draft-ietf-sacm-terminology-13.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 (July 04, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 953, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 == Outdated reference: A later version (-08) exists of draft-ietf-netmod-entity-03 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: January 5, 2018 Oracle Corporation 6 J. Strassner 7 Huawei Technologies 8 N. Cam-Winget 9 Cisco Systems 10 July 04, 2017 12 Security Automation and Continuous Monitoring (SACM) Terminology 13 draft-ietf-sacm-terminology-13 15 Abstract 17 This memo documents terminology used in the documents produced by 18 SACM (Security Automation and Continuous Monitoring). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 5, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 59 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 60 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 63 8.2. Informative References . . . . . . . . . . . . . . . . . 28 64 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 29 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 67 1. Introduction 69 Our goal with this document is to improve our agreement on the 70 terminology used in documents produced by the IETF Working Group for 71 Security Automation and Continuous Monitoring. Agreeing on 72 terminology should help reach consensus on which problems we're 73 trying to solve, and propose solutions and decide which ones to use. 75 2. Terms and Definitions 77 This section describes terms that have been defined by other RFC's 78 and defines new ones. The predefined terms will reference the RFC 79 and where appropriate will be annotated with the specific context by 80 which the term is used in SACM. 82 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 83 entity without accompanying evidence of its validity". In the 84 context of SACM, an assertion is the output of a SACM component in 85 the form of a statement (including metadata about the data source 86 and data origin, e.g. timestamps). While the validity of an 87 assertion cannot be verified without, for example, an additional 88 attestation protocol, an assertion (and therefore a statement, 89 respectively) can be accompanied by evidence of the validity of 90 its metadata provided by a SACM component. 92 Assessment: Defined in [RFC5209] as "the process of collecting 93 posture for a set of capabilities on the endpoint (e.g., host- 94 based firewall) such that the appropriate validators may evaluate 95 the posture against compliance policy." 96 An assessment is a specific workflow that incorporates the SACM 97 tasks discovery, collection and evaluation. A prominent instance 98 of the assessment workflow is illustrated in the Vulnerability 99 Assessment Scenario [I-D.ietf-sacm-vuln-scenario]. 101 Asset: Defined in [RFC4949] as "a system resource that is (a) 102 required to be protected by an information system's security 103 policy, (b) intended to be protected by a countermeasure, or (c) 104 required for a system's mission". In the scope of SACM, an asset 105 can be composed of other assets. Examples of Assets include: 106 Endpoints, Software, Guidance, or X.509 public key certificates. 107 An asset is not necessarily owned by an organization. 109 Asset Management: The process by which assets are provisioned, 110 updated, maintained and deprecated. 112 Attribute: Defined in [RFC5209] as "data element including any 113 requisite meta-data describing an observed, expected, or the 114 operational status of an endpoint feature (e.g., anti-virus 115 software is currently in use)." In the context of SACM, 116 attributes are "atomic" information elements and an equivalent to 117 attribute-value-pairs. Attributes can be components of Subjects. 119 Authentication: Defined in [RFC4949] as "the process of verifying a 120 claim that a system entity or system resource has a certain 121 attribute value." 123 Authorization: Defined in [RFC4949] as "an approval that is granted 124 to a system entity to access a system resource." 126 Broker: A broker is a specific controller type that contains control 127 plane functions to provide and/or connect services on behalf of 128 other SACM components via interfaces on the control plane. A 129 broker may provide, for example, authorization services and find, 130 upon request, SACM components providing requested services. 132 Capability: In [I-D.ietf-i2nsf-terminology] a capability is "a set 133 of features that are available from an I2NSF Component. These 134 functions may, but do not have to, be used. All Capabilities are 135 announced through the I2NSF Registration Interface. Examples are 136 Capabilities that are available from an NSF Server." 138 In the context of SACM, the extent of a SACM component's ability 139 is enabled by the functions it is composed of. Capabilities are 140 registered at a SACM broker (potentially also at a proxy or a 141 repository component if it includes broker functions) by a SACM 142 component via the SACM component registration task and can be 143 discovered by or negotiated with other SACM components via the 144 corresponding tasks. For example, the capability of a SACM 145 provider may be to provide target endpoint records (declarative 146 guidance about well-known or potential target endpoints), or only 147 a subset of that data. 149 A capability's description is in itself imperative guidance on 150 what functions are exposed to other SACM components in a SACM 151 domain and how to use them in workflows. 153 The SACM Vulnerability Assessment Scenario 154 [I-D.ietf-sacm-vuln-scenario] defines the terms Endpoint 155 Management Capabilities, Vulnerability Management Capabilities, 156 and Vulnerability Assessment Capabilities, which illustrate 157 specific sets of SACM capabilities on an enterprise IT 158 department's point of view and therefore compose sets of 159 declarative guidance. 161 Collection Result: Information about a target endpoint that is 162 produced by a collector conducting a collection task. A 163 collection result is composed as one or more content-elements. 165 Collection Task: The task by which endpoint attributes and/or 166 corresponding attribute values about a target endpoint are 167 collected. The collection tasks are targeted at specific target 168 endpoints and therefore are targeted tasks. 170 There are four types of frequency collection tasks can be 171 conducted with: 173 ad-hoc, e.g. triggered by a unsolicited query 175 conditional, e.g. triggered in accordance with policies included 176 in the compositions of workflows 178 scheduled, e.g. in regular intervals, such as every minute or 179 weekly 181 continuously, e.g. a network behavior observation 183 There are three types of collection methods, each requiring an 184 appropriate set of functions to be included in the SACM component 185 conducting the collection task: 187 Self-Reporting: A SACM component located on the target endpoint 188 itself conducts the collection task. 190 Remote-Acquisition: A SACM component located on an Endpoint 191 different from the target endpoint conducts the collection task 192 via interfaces available on the target endpoint, e.g. SNMP/ 193 NETCONF or WMI. 195 Behavior-Observation: A SACM component located on an Endpoint 196 different from the target endpoint observes network traffic 197 related to the target endpoint and conducts the collection task 198 via interpretation of that network traffic. 200 Collector: A piece of software that acquires information about one 201 or more target endpoints by conducting collection tasks. A 202 collector provides acquired information in the form of collection 203 results via a set of registered capabilities that can be 204 discovered by other SACM components. 206 A collector can be distributed across multiple endpoints, e.g. 207 across a target endpoint and a SACM component. The separate parts 208 of the collector can communicate with a specialized protocol, such 209 as PA-TNC [RFC5792]. At least one part of a distributed collector 210 has to take on the role of a provider of information by providing 211 SACM interfaces to propagate capabilities and to provide SACM 212 content in the form of collection results. 214 Configuration: A non-volatile subset of the endpoint attributes of a 215 (target) endpoint that is intended to be unaffected by a normal 216 reboot-cycle. Configuration is a type of imperative guidance that 217 is stored in files (files dedicated to contain configuration and/ 218 or files that are software components), directly on block devices, 219 or on specific hardware components that can be accessed via 220 corresponding software components. Modification of configuration 221 can be conducted manually or automatically via management (plane) 222 interfaces that support management protocols, such as SNMP or WMI. 223 A change of configuration can occur during both run-time and down- 224 time of an endpoint. It is common practice to scheduled a change 225 of configuration during or directly after the completion of a 226 boot-cycle via corresponding software components located on the 227 target endpoint itself. 229 Examples: The static association of an IP address and a MAC 230 address in a DHCP server configuration, a directory-path that 231 identifies a log-file directory, a registry entry. 233 Configuration Drift: The discrepancy of a target endpoint's endpoint 234 attributes representing the actual composition of a target 235 endpoint (is-state) and its intended composition (should-state) in 236 the scope of a valid target endpoint composition (could-state) due 237 to continuous alteration of a target endpoint's composition over 238 time. Configuration drift exists for both hardware components and 239 software components. Typically, the frequency and scale of 240 configuration drift of software components is significantly higher 241 than the configuration drift of hardware components. 243 Consumer: A consumer is a SACM role that is assigned to a SACM 244 component that contains functions to receive information from 245 other SACM components. 247 Content Element: Content elements constitute the payload data (SACM 248 content) transferred via statement Subjects emitted by providers 249 of information. Every content element Subject includes a specific 250 content Subject and a corresponding content metadata Subject. 252 Content Metadata: Data about content Subjects. Every content- 253 element includes a content metadata Subject. The Subject can 254 include any information element that can annotate the content 255 transeferred. Examples include time stamps or data provenance 256 Subjects. 258 Control Plane: Typically used as a term in the context of routing, 259 e.g. [RFC6192]. In the context of SACM, the control plane is an 260 architectural component providing common control functions to all 261 SACM components, including authentication, authorization, 262 (capability) discovery or negotiation, registration and 263 subscription. The control plane orchestrates the flow on the data 264 plane according to imperative guidance (i.e. configuration) 265 received via the management plane. SACM components with 266 interfaces to the control plane have knowledge of the capabilities 267 of other SACM components within a SACM domain. 269 Controller: A controller is a SACM role that is assigned to a SACM 270 component containing control plane functions that manage and 271 facilitate information sharing or execute on security functions. 272 There are three types of SACM controllers: Broker, Proxy, and 273 Repository. Depending on its type, a controller can also contain 274 functions that have interfaces on the data plane. 276 Data Confidentiality: Defined in [RFC4949] as "the property that 277 data is not disclosed to system entities unless they have been 278 authorized to know the data." 280 Data In Motion: Data that is being transported via a network; also 281 referred to as "Data in Transit" or "Data in Flight". Data in 282 motion requires a data model to transfer the data using a specific 283 encoding. Typically, data in motion is serialized (marshalling) 284 into a transport encoding by a provider of information and 285 deserialized (unmarshalling) by a consumer of information. The 286 termination points of provider of information and consumer of 287 information data is transferred between are interfaces. In regard 288 to data in motion, the interpretation of the roles consumer of 289 information and provider of information depends on the 290 corresponding OSI layer (e.g. on layer2: between interfaces 291 connected to a broadcast domain, on layer4: between interfaces 292 that maintain a TCP connection). In the context of SACM, consumer 293 of information and provider of information are SACM components. 295 The SACM architecture and corresponding models focus on data in 296 motion. 298 Data At Rest: Data that is stored in a repository. Data at rest 299 requires a data model to encode the data to be stored. In the 300 context of SACM, data at rest located on a SACM component can be 301 provided to other SACM components via discoverable capabilities. 303 In the context of SACM, data models for data at rest are out of 304 scope. 306 Data Integrity: Defined in [RFC4949] as "the property that data has 307 not been changed, destroyed, or lost in an unauthorized or 308 accidental manner." 310 Data Origin: One or more properties (i.e. endpoint attributes) that 311 enable a SACM component to identify the SACM component that 312 initially acquired or produced data about a (target) endpoint 313 (e.g. via collection from a data source) and made it available to 314 a SACM domain via a SACM statement. Data Origin can be expressed 315 by an endpoint label information element (e.g. to be used as 316 metadata in statement). 318 Data Plane (fix statement): Typically used as a term in the context 319 of routing (and used as a synonym for forwarding plane, e.g. 320 [RFC6192]). In the context of SACM, the data plane is an 321 architectural component providing operational functions to enable 322 a SACM component to provide and consume SACM statements and 323 therefore SACM content, which composes the actual SACM content. 324 The data plane in a SACM domain is used to conduct distributed 325 SACM tasks by transporting SACM content via specific transport 326 encodings and corresponding operations defined by SACM data 327 models. 329 Data Provenance: A historical record of the sources, origins and 330 evolution of data that is influenced by inputs, entities, 331 functions and processes. In the context of SACM, data provenance 332 is expressed as metadata that identifies SACM statements and 333 corresponding content elements a new statement is created from. 334 In a downstream process, this references can cascade, creating a 335 data provenance tree that enables SACM components to trace back 336 the original data sources involved in the creation of SACM 337 statements and take into account their characteristics and 338 trustworthiness. 340 Data Source: One or more properties (i.e. endpoint attributes) that 341 enable a SACM component to identify - and potentially characterize 342 - a (target) endpoint that is claimed to be the original source of 343 endpoint attributes in a SACM statement. Data Source can be 344 expressed as metadata by an endpoint label information element or 345 a corresponding subject of identifying endpoint attributes. 347 Endpoint: Defined in [RFC5209] as "any computing device that can be 348 connected to a network. Such devices normally are associated with 349 a particular link layer address before joining the network and 350 potentially an IP address once on the network. This includes: 351 laptops, desktops, servers, cell phones, or any device that may 352 have an IP address." 354 To further clarify the [RFC5209] definition, an endpoint is any 355 physical or virtual device that may have a network address. Note 356 that, network infrastructure devices (e.g. switches, routers, 357 firewalls), which fit the definition, are also considered to be 358 endpoints within this document. 360 Physical endpoints are always composites that are composed of 361 hardware components and software components. Virtual endpoints 362 are composed entirely of software components and rely on software 363 components that provide functions equivalent to hardware 364 components. 366 The SACM architecture differentiates two essential categories of 367 endpoints: Endpoints whose security posture is intended to be 368 assessed (target endpoints) and endpoints that are specifically 369 excluded from endpoint posture assessment (excluded endpoints). 371 Based on the definition of an asset, an endpoint is a type of 372 asset. 374 Endpoint Attribute: In the context of SACM, endpoint attributes are 375 information elements that describe an endpoint characteristic of a 376 target endpoint. Endpoint Attributes typically constitute 377 Attributes that can be bundled into Subject (e.g. information 378 about a specific network interface can be represented via a set of 379 multiple AVP). 381 Endpoint Characteristics: The state, configuration and composition 382 of the software components and (virtual) hardware components a 383 target endpoint is composed of, including observable behavior, 384 e.g. sys-calls, log-files, or PDU emission on a network. 386 Endpoint Characterization: The task by which a profile is composed 387 out of endpoint attributes that describe the desired or expected 388 posture of a type or class of target endpoints or even an 389 individual target endpoint. The result of this task is an 390 endpoint profile that is required as declarative guidance for the 391 tasks of endpoint classification or posture assessment. 393 Endpoint Classification: The task by which a discovered target 394 endpoint is classified. Endpoint classification requires 395 declarative guidance in the form of an endpoint profile, discovery 396 results and potentially collection results. Types, classes or the 397 characteristics of an individual target endpoint are defined via 398 endpoint profiles. 400 Endpoint Label: In a SACM domain, every endpoint can be identified 401 by an endpoint label. There are two prominent uses of endpoint 402 labels in a SACM domain: to identify SACM components and to 403 identify Target Endpoints. Both endpoint labels can be used in 404 SACM content or in content metadata: 406 SACM Components are identified by: SACM component label / Data 407 Origin 409 Target Endpoints are identified by: TE label / Data Source 411 An endpoint label is expressed as an artificially created ID that 412 references a distinct set of identifying attributes (Target 413 Endpoint Identifier). A target endpoint label is unique in a SACM 414 domain and created by a SACM component that provides the 415 appropriate function as a capability. 417 Endpoint Management Capabilities: An enterprise IT department's 418 ability to manage endpoint identity, endpoint information, and 419 associated metadata on an ongoing basis. 421 Evaluation Task: The task by which endpoint attributes are 422 evaluated. 424 Evaluation Result: The resulting value from having evaluated a set 425 of posture attributes. 427 Event: The change of a target endpoint characteristics at a specific 428 point in time. In the context of SACM, an event is a statement 429 (and therefore data in motion) that includes the new target 430 endpoint characteristics and optional also the past ones, 431 annotated with corresponding metedata (most prominently, the 432 collection time of the data that constitutes the observation of 433 the event regarding the target endpoint). 435 Excluded Endpoint: A specific designation, which is assigned to an 436 endpoint that is not supposed to be the subject of a collection 437 task (and therefore is not a target endpoint). Typically but not 438 necessarily, endpoints that contain a SACM component (and are 439 therefore part of the SACM domain) are designated as excluded 440 endpoints. Target endpoints that contain a SACM component cannot 441 be designated as excluded endpoints and are part of the SACM 442 domain. 444 Expected Endpoint State: The required state of an endpoint that is 445 to be compared against. Sets of expected endpoint states are 446 transported as declarative guidance in target endpoint profiles 447 via the management plane. This, for example, can be a policy, but 448 also a recorded past state. An expected state is represented can 449 be represented via an Attribute or an Subject that represents a 450 set of multiple attribute value pairs. 452 SACM Function: A behavioral aspect or capacity of a particular SACM 453 component, which belies that SACM component's purpose. For 454 example, a SACM function with interfaces on the control plane can 455 provide a brokering function to other SACM components. Via data 456 plane interfaces, a function can act as a provider and/or as a 457 consumer of information. SACM functions can be propagated as the 458 capabilities of a SACM component and can be discovered by or 459 negotiated with other SACM components. 461 Guidance: Input instructions to processes, such as automated device 462 management or remediation, and SACM tasks, such as collection or 463 evaluation. Guidance influences the behavior of a SACM component 464 and is considered content of the management plane. In the context 465 of SACM, guidance is machine-readable and can be manually or 466 automatically generated or provided. Typically, the tasks that 467 provide guidance to SACM components have a low-frequency and tend 468 to be be sporadic. 470 There are two types of guidance: 472 Declarative Guidance: defines the configuration or state an 473 endpoint is supposed to be in--without providing specific actions 474 or methods to produce that desired state. Examples include Target 475 Endpoint Profiles or network topology based requirements. 477 Imperative Guidance: prescribes specific actions to be conducted 478 or methods to be used in order to achieve an outcome. Examples 479 include a targeted Collection Task or the IP-Address of a SACM 480 Component that provides a registration function. 482 Hardware Component: Hardware components are the distinguishable 483 physical components that compose an endpoint. The composition of 484 an endpoint can be changed over time by adding or removing 485 hardware components. In essence, every physical endpoint is 486 potentially a composite of multiple hardware components, typically 487 resulting in a hierarchical composition of hardware components. 488 The composition of hardware components is based on interconnects 489 provided by specific hardware types (e.g. a mainboard is a 490 hardware type that provides local busses as an interconnect or an 491 FRU is a hardware type that is itself connected via an 492 interconnect to a chassis and can provide further interconnects 493 for additional hardware components, such as interfaces modules). 494 In general, a hardware component can be distinguished by its 495 serial number. Occasionally, hardware components are referred to 496 as power sucking aliens. 498 The Entity MIB version 4 [RFC6933] and the YANG Data Model for 499 Hardware Management [I-D.ietf-netmod-entity] provide common 500 examples of target endpoint characteristics about hardware 501 components. 503 Hardware Inventory: The list of hardware components that compose a 504 specific endpoint representing its hardware configuration. 506 Hardware Type: Hardware types define specific and distinguishable 507 categories of hardware components that can be part of endpoints, 508 e.g. CPU or 802.11p interface. Typically, hardware types can be 509 distinguished by their vendor assigned names, names of standards 510 used, or a model name. 512 The IANAPhysicalClass [RFC6933] and corresponding iana-entity YANG 513 module [I-D.ietf-netmod-entity] provide the standard references 514 for physical hardware types. 516 Information Element: A representation of information about physical 517 and virtual "objects of interests". Information elements are the 518 building blocks that constitute the SACM information model. In 519 the context of SACM, an information element that expresses a 520 single value with a specific name is referred to as an Attribute 521 (analogous to an attribute-value-pair). A set of attributes that 522 is bundled into a more complex composite information element is 523 referred to as a Subject. Every information element in the SACM 524 information model has a unique name. Endpoint attributes or time 525 stamps, for example, are represented as information elements in 526 the SACM information model. 528 Information Model: An information model is an abstract 529 representation of data, their properties, relationships between 530 data and the operations that can be performed on the data. While 531 there is some overlap with a data model, [RFC3444] distinguishes 532 an information model as being protocol and implementation neutral 533 whereas a data model would provide such details. The purpose of 534 the SACM information model is to ensure interoperability between 535 SACM data models (that are used as transport encoding) and to 536 provide a standardized set of information elements for 537 communication between SACM components. 539 Interaction Model: The definition of specific sequences regarding 540 the exchange of messages (data in motion), including, for exmaple, 541 conditional branching, thresholds and timers. An interaction 542 model, for example, can be used to define operations, such as 543 registration or discovery, on the control plane. A composition of 544 data models for data in motion and a corresponding interaction 545 model is a protocol. 547 Internal Collector: Internal Collector: a collector that runs on a 548 target endpoint to acquire information from that target endpoint. 549 (TBD: An internal collector is not a SACM component and therefore 550 not part of a SACM domain). 552 Management Plane: An architectural component providing common 553 functions to steer the behavior of SACM components, e.g. its 554 behavior on the control plane. Prominent examples include: 555 modification of the configuration of a SACM component or updating 556 a target endpoint profile that resides on an evaluator. In 557 essence, guidance is transported via the management plane. 558 Typically, a SACM component can fulfill its purpose without 559 continuous input from the management plane. In contrast, without 560 continuous availability of control plane functions a typical SACM 561 component could not function properly. In general, interaction on 562 the management plane is less frequent and less regular than on the 563 control plane. Input via the management plane can be manual (e.g. 564 via a CLI), or can be automated via management plane functions 565 that are part of other SACM components. 567 Metadata: Data about data. In the SACM information model, data is 568 referred to as Content. Metadata about the content is referred to 569 as Content-Metadata, respectively. Content and Content-Metadata 570 are combined into Subjects called Content-Elements in the SACM 571 information model. Some information elements defined by the SACM 572 information model can be part of the Content or the Content- 573 Metadata. Therefore, if an information element is considered data 574 or data about data depends on which kind of Subject it is 575 associated with. The SACM information model also defines metadata 576 about the data origin via the Subject Statement-Metadata. Typical 577 examples of metadata are time stamps, data origin or data source. 579 Network Address: Network addresses are layer specific and follow 580 layer specific address schemes. Each interface of a specific 581 layer can be associated with one or more addresses appropriate for 582 that layer. There is no guarantee that an address is globally 583 unique. In general, there is a scope to an address in which it is 584 intended to be unique. 586 Examples include: physical Ethernet port with a MAC address, layer 587 2 VLAN interface with a MAC address, layer 3 interface with 588 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 589 IPv4 address. 591 Network Interface: An endpoint is connected to a network via one or 592 more network interfaces. Network interfaces can be physical or 593 virtual. Network interfaces of an endpoint can operate on 594 different layers, most prominently what is now commonly called 595 layer 2 and 3. Within a layer, interfaces can be nested. 597 On layer 2, a root interface is typically associated with a 598 physical interface port and nested interfaces are virtual 599 interfaces. In the case of a virtual endpoint, a root interface 600 can be a virtual interface. Virtual layer 2 interfaces of one or 601 more endpoints can also constitute an aggregated group of links 602 that act as one. 604 On layer 3, nested interfaces typically constitute virtual tunnels 605 or virtual (mesh) networks. 607 Examples include: physical Ethernet port, layer 2 VLAN interface, 608 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 610 Posture: Defined in [RFC5209] as "configuration and/or status of 611 hardware or software on an endpoint as it pertains to an 612 organization's security policy." 614 This term is used within the scope of SACM to represent the 615 configuration and state information that is collected from a 616 target endpoint in the form of endpoint attributes (e.g. software/ 617 hardware inventory, configuration settings, dynamically assigned 618 addresses). This information may constitute one or more posture 619 attributes. 621 Posture Attributes: Defined in [RFC5209] as "attributes describing 622 the configuration or status (posture) of a feature of the 623 endpoint. A Posture Attribute represents a single property of an 624 observed state. For example, a Posture Attribute might describe 625 the version of the operating system installed on the system." 627 Within this document this term represents a specific assertion 628 about endpoint configuration or state (e.g. configuration setting, 629 installed software, hardware) represented via endpoint attributes. 630 The phrase "features of the endpoint" highlighted above refers to 631 installed software or software components. 633 Provider: A provider is a SACM role that is assigned to a SACM 634 component that contains functions to provide information to other 635 SACM components. 637 Proxy: A proxy is a specific controller type that provides data 638 plane and control plane functions, information, or services on 639 behalf of another component, which is not directly participating 640 in the SACM architecture. 642 Repository: A repository is a specific controller type that contains 643 functions to consume, store and provide information of a 644 particular kind - typically data transported on the data plane, 645 but potentially also data and metadata from the control and 646 management plane. A single repository may provide the functions 647 of more than one specific repository type (i.e. configuration 648 baseline repository, assessment results repository, etc.) 650 SACM Component: A component is defined in 651 [I-D.ietf-i2nsf-terminology] as "an encapsulation of software that 652 communicates using Interfaces. A Component may be implemented by 653 hardware and/or Software, and be represented using a set of 654 classes. In general, a Component encapsulates a set of data 655 structures as well as a set of algorithms that implement the 656 functions that it provides." 658 In the context of SACM, a set of SACM functions composes a SACM 659 component. A SACM component conducts SACM tasks, acting on 660 control plane, data plane and/or management plane via 661 corresponding SACM interfaces. SACM defines a set of standard 662 components (e.g. a collector, a broker, or a data store). A SACM 663 component contains at least a basic set of control plane functions 664 and can contain data plane and management plane functions. A SACM 665 component residing on an endpoint assigns one or more SACM roles 666 to the corresponding endpoint due to the SACM functions it is 667 composed of. A SACM component "resides on" an endpoint and an 668 endpoint "contains" a SACM component, correspondingly. For 669 example, a SACM component that is composed solely of functions 670 that provide information would only take on the role of a 671 provider. 673 SACM Component Discovery: The task of brokering appropriate SACM 674 components according to their capabilities or roles on reques. 676 Input: Query 678 Output: a list of SACM components including metadata 680 SACM Component Label: A specific endpoint label that is used to 681 identify a SACM component. In content-metadata, this label is 682 called data origin. 684 SACM Content: The payload provided by SACM components to the SACM 685 domain on the data plane. SACM content includes the SACM data 686 models. 688 SACM Domain: Endpoints that include a SACM component compose a SACM 689 domain. (To be revised, additional definition content TBD, 690 possible dependencies to SACM architecture) 692 SACM Interface: An interface is defined in 693 [I-D.ietf-i2nsf-terminology] as "A set of operations one object 694 knows it can invoke on, and expose to, another object. This 695 decouples the implementation of the operation from its 696 specification. An interface is a subset of all operations that a 697 given object implements. The same object may have multiple types 698 of interfaces to serve different purposes." 700 In the context of SACM, SACM Functions provide SACM Interfaces on 701 the management, control, or data plane. Operations a SACM 702 Interface provides are based on corresponding data model defined 703 by SACM. SACM Interfaces are used for communication between SACM 704 components. 706 SACM Role: A role is defined in [I-D.ietf-i2nsf-terminology] as "an 707 abstraction of a Component that models context-specific views and 708 responsibilities of an object as separate role objects that can be 709 statically or dynamically attached to (and removed from) the 710 object that the role object describes. This provides three 711 important benefits. First, it enables different behavior to be 712 supported by the same Component for different contexts. Second, 713 it enables the behavior of a Component to be adjusted dynamically 714 (i.e., at runtime, in response)to changes in context, by using one 715 or more Roles to define the behavior desired for each context. 716 Third, it decouples the Roles of a Component from the Applications 717 that use that Component." 719 In the context of SACM, SACM roles are associated with SACM 720 components and are defined by the set of functions and interfaces 721 a SACM component includes. There are three SACM roles: provider, 722 consumer, and controller. The roles associated with a SACM 723 component are determined by the purpose of the SACM functions and 724 corresponding SACM interfaces the SACM component is composed of. 726 Security Automation: The process of which security alerts can be 727 automated through the use of different components to monitor, 728 analyze and assess endpoints and network traffic for the purposes 729 of detecting miss-configurations, miss-behaviors or threats. 730 Security Automation is intended to identify target endpoints that 731 cannot be trusted (see "trusted" in [RFC4949]. This goal is 732 achieved by creating and processing evidence (assessment 733 statements) that a target endpoint is not a trusted system 734 [RFC4949]. 736 Software Package: A generic software package (e.g. a text editor). 738 Software Component: A software package installed on an endpoint, 739 including a unique serial number if present (e.g. a text editor 740 associated with a unique license key). 742 Software Instance: A running instance of the software component 743 (e.g. on a multi-user system, one logged-in user has one instance 744 of a text editor running and another logged-in user has another 745 instance of the same text editor running, or on a single-user 746 system, a user could have multiple independent instances of the 747 same text editor running). 749 State: A volatile subset endpoint attributes of a (target) endpoint 750 that is affected by a reboot-cycle. Local state is created by the 751 interaction of components with other components via the control 752 plane, via processing data plane payload, or via the functional 753 properties of local hardware and software components. Dynamic 754 configuration (e.g. IP address distributed dynamically via an 755 address distribution and management services, such as DHCP) is 756 considered state that is the result of the interaction with 757 another component that provides configuration via the control 758 plane (e.g. provided by a DHCP server with a specific 759 configuration). 761 Examples: The static association of an IP address and a MAC 762 address in a DHCP server configuration, a directory-path that 763 identifies a log-file directory, a registry entry. 765 Statement: A statement is a subject defined in the SACM information 766 model. 768 When a statement is used to provide content to a SACM domain, it 769 is a top-level subject that bundles Content Elements into one 770 subject and includes metadata about the data origin. 772 Subject: A composite information element. Like Attributes, subjects 773 have a name and are composed of attributes and/or other subjects. 774 Every IE that is part of a subject can have a quantitiy associated 775 with it (e.g. zero-one, none-unbounded). The content IE of a 776 subject can be an unordered or an ordered list. 778 In contrast to the definitions of subject provided by [RFC4949], a 779 subject in the scope of SACM is neither "a system entity that 780 causes information to flow among objects or changes the system 781 state" nor "a name of a system entity that is bound to the data 782 items in a digital certificate". 784 In the context of SACM, a subject is a semantic composite of 785 information elements about a system entity that is a target 786 endpoint. Every acquirable subject--as defined in the scope of 787 SACM--about a target endpoint represents and therefore identifies 788 every subject--as defined by [RFC4949]--that is a component of 789 that target endpoint. The semantic difference between both 790 definitions can be subtle in practice and is in consequence 791 important to highlight. 793 Supplicant: A SACM component seeking to be authenticated via the 794 control plane for the purpose of participating in a SACM domain. 796 System Resource: Defined in [RFC4949] as "data contained in an 797 information system; or a service provided by a system; or a system 798 capacity, such as processing power or communication bandwidth; or 799 an item of system equipment (i.e., hardware, firmware, software, 800 or documentation); or a facility that houses system operations and 801 equipment. 803 Target Endpoint: A target endpoint is an "endpoint under assessment" 804 (even if it is not actively under assessment at all times) or 805 "endpoint of interest". Every endpoint that is not specifically 806 designated as an excluded endpoint is a target endpoint. A target 807 endpoint is not part of a SACM domain unless it contains a SACM 808 component (e.g. a SACM component that publishes collection results 809 coming from an internal collector). 811 A target endpoint is similar to a device that is a Target of 812 Evaluation (TOE) as defined in Common Criteria and as referenced 813 by {{RFC4949}. 815 In respect to [RFC4949] a target endpoint is an information system 816 and therefore a composite that is a system entity composed of 817 system components or system entities, respectively. 819 Target Endpoint Characterization Record: A set of endpoint 820 attributes about a target endpoint that was encountered in a SACM 821 domain, which are associated with a target endpoint by being 822 included in the corresponding record. A characterization record 823 is intended to be a representation of an endpoint. It cannot be 824 assured that a record distinctly represents a single target 825 endpoint unless a set of one or more endpoint attributes that 826 compose a unique set of identifying endpoint attributes are 827 included in the record. Otherwise, the set of identifying 828 attributes included in a record can match more than one target 829 endpoints, which are - in consequence - indistinguishable to a 830 SACM domain until more qualifying endpoint attributes can be 831 acquired and added to the record. A characterization record is 832 maintained over time in order to assert that acquired endpoint 833 attributes are either about an endpoint that was encountered 834 before or an endpoint that has not been encountered before in a 835 SACM domain. A characterization record can include, for example, 836 acquired configuration, state or observed behavior of a specific 837 target endpoint. Multiple and even conflicting instances of this 838 information can be included in a characterization record by using 839 timestamps and/or data origins to differentiate them. The 840 endpoint attributes included in a characterization record can be 841 used to re-identify a distinct target endpoint over time. Classes 842 or profiles can be associated with a characterization record via 843 the Classification Task in order to guide collection, evaluation 844 or remediation tasks. 846 Target Endpoint Characterization Task: An ongoing task of 847 continuously adding acquired endpoint attributes to a 848 corresponding record. The TE characterization task manages the 849 representation of encountered target endpoints in the SACM domain 850 in the form of characterization records. For example, the output 851 of a target endpoint discovery task or a collection task can be 852 processed by the characterization task and added to the record. 853 The TE characterization Task also manages these representations of 854 target endpoints encountered in the SACM domain by splitting or 855 merging the corresponding records as new or more refined endpoint 856 attributes become available. 858 Input: discovered target endpoint attributes, endpoint attribute 859 collection, existing characterization records 861 Output: target endpoint characterization records 863 Target Endpoint Classification Task: The task of associating a class 864 from an extensible list of classes with an endpoint 865 characterization record. TE classes function as imperative and 866 declarative guidance for collection, evaluation, remediation and 867 security posture assessment in general. 869 Input: endpoint characterization records (without classification), 870 guidance (how to classify a record) 872 Output: endpoint characterization records (with classification) 874 Target Endpoint Discovery Task: The ongoing task of detecting 875 previously unknown interaction of a potential target endpoint in 876 the SACM domain. TE Discovery is not directly targeted at a 877 specific target endpoint and therefore an un-targeted task. SACM 878 Components conducting the discovery task as a part of their 879 function are typically distributed and located, for example, on 880 infrastructure components or collect from those remotely via 881 appropriate interfaces. Examples of infrastructure components 882 that are of interest to the discovery task include routers, 883 switches, VM hosting or VM managing components, AAA servers, or 884 servers handling dynamic address distribution. 886 Input: endpoint attributes acquired via local or remote interfaces 888 Output: endpoint attributes including metadata such as data source 889 or data origin 891 Target Endpoint Identifier: The target endpoint discovery task and 892 the collection tasks can result in a set of identifying endpoint 893 attributes added to a corresponding Characterization Record. This 894 subset of the endpoint attributes included in the record is used 895 as a target endpoint identifier, by which a specific target 896 endpoint can be referenced. Depending on the available 897 identifying attributes, this reference can be ambiguous and is a 898 "best-effort" mechanism. Every distinct set of identifying 899 endpoint attributes can be associated with a target endpoint label 900 that is unique in a SACM domain. 902 Target Endpoint Label: A specific endpoint label that refers to a 903 target endpoint identifier used to identify a specific target 904 endpoint (also referred to as TE label). In content-metadata, 905 this label is called data source. 907 Target Endpoint Profile: A bundle of expected or desired component 908 composition, configurations and states--therefore a composition of 909 information elements that constitute declarative guidance-- 910 associated with a target endpoint. 912 The corresponding task by which the association with a target 913 endpoint takes places is the endpoint classification task. The 914 task by which an endpoint profile is created is the endpoint 915 characterization task. A type or class of target endpoints can be 916 defined via a target endpoint profile. Examples include: 917 printers, smartphones, or an office PC. 919 In respect to [RFC4949], a target endpoint profile is a protection 920 profile as defined by Common Criteria (analogous to the target 921 endpoint being the target of evaluation). 923 SACM Task: A SACM task is conducted by one or more SACM functions 924 that reside on a SACM component (e.g. a collection task or 925 endpoint characterization). A SACM task can be triggered by other 926 operations or functions (e.g. a query from another SACM component 927 or an unsolicited push on the data plane due to an ongoing 928 subscription). A task is part of a SACM process chain. A task 929 starts at a given point in time and ends in a deterministic state. 930 With the exception of a collection task, a SACM task consumes SACM 931 statements provided by other SACM components. The output of a 932 task is a result that can be provided (e.g. published) on the data 933 plane. There following tasks are defined by SACM: 935 Target Endpoint Discovery 937 Target Endpoint Characterization 939 Target Endpoint Classification 941 Collection 943 Evaluation [TBD] 945 Information Sharing [TBD] 947 SACM Component Discovery 949 SACM Component Authentication [TBD] 951 SACM Component Authorization [TBD] 953 SACM Component Registration [TBD] 955 Timestamps : Defined in [RFC4949] as "with respect to a data object, 956 a label or marking in which is recorded the time (time of day or 957 other instant of elapsed time) at which the label or marking was 958 affixed to the data object" and as "with respect to a recorded 959 network event, a data field in which is recorded the time (time of 960 day or other instant of elapsed time) at which the event took 961 place.". 963 This term is used in SACM to describe a recorded point in time at 964 which, for example, an information element is created or updated 965 on a target endpoint, and observed, transmitted or processed by a 966 SACM component. Timestamps can be created by target endpoints or 967 SACM components and are associated with SACM statements provided 968 or consumed by SACM components. Outside of the domain of SACM 969 components the assurance of correctness of time stamps is 970 typically significantly lower than inside a SACM domain. In 971 general, it cannot be simply assumed that the source of time a 972 target endpoint uses is synchronized or trustworthy. 974 Virtual Component: A target endpoint can be composed entirely of 975 logical system entities (see [RFC4949]. The most common example 976 is a virtual machine/host running on a target endpoint. 978 Effectively, target endpoints can be nested and at the time of 979 this writing the most common example of target endpoint 980 characteristics about virtual components is the EntLogicalEntry in 981 [RFC6933]. 983 Vulnerability Assessment: The process of determining whether a set 984 of endpoints is vulnerable according to the information contained 985 in the vulnerability description information. 987 Vulnerability Description Information: Information pertaining to the 988 existence of a flaw or flaws in software, hardware, and/or 989 firmware, which could potentially have an adverse impact on 990 enterprise IT functionality and/or security. Vulnerability 991 description information should contain enough information to 992 support vulnerability detection. 994 Vulnerability Detection Data: A type of imperative guidance 995 extracted or derived from vulnerability description information 996 that describes the specific mechanisms of vulnerability detection 997 that is used by an enterprise's vulnerability management 998 capabilities to determine if a vulnerability is present on an 999 endpoint. 1001 Vulnerability Management Capabilities: An enterprise IT department's 1002 ability to manage endpoint vulnerabilities and associated metadata 1003 on an ongoing basis by ingesting vulnerability description 1004 information and vulnerability detection data, and performing 1005 vulnerability assessments. 1007 Vulnerability assessment capabilities: An enterprise IT department's 1008 ability to determine whether a set of endpoints is vulnerable 1009 according to the information contained in the vulnerability 1010 description information. 1012 Workflow: A workflow is a modular composition of tasks. A workflow 1013 can contain loops, conditionals, multiple starting points and 1014 multiple endpoints. The most prominant workflow in SACM is the 1015 assessment workflow. 1017 3. IANA Considerations 1019 This memo includes no request to IANA. 1021 4. Security Considerations 1023 This memo documents terminology for security automation. While it is 1024 about security, it does not affect security. 1026 5. Acknowledgements 1028 6. Change Log 1030 Changes from version 00 to version 01: 1032 o Added simple list of terms extracted from UC draft -05. It is 1033 expected that comments will be received on this list of terms as 1034 to whether they should be kept in this document. Those that are 1035 kept will be appropriately defined or cited. 1037 Changes from version 01 to version 02: 1039 o Added Vulnerability, Vulnerability Management, xposure, 1040 Misconfiguration, and Software flaw. 1042 Changes from version 02 to version 03: 1044 o Removed Section 2.1. Cleaned up some editing nits; broke terms 1045 into 2 sections (predefined and newly defined terms). Added some 1046 of the relevant terms per the proposed list discussed in the IETF 1047 89 meeting. 1049 Changes from version 03 to version 04: 1051 o TODO 1053 Changes from version 04 to version 05: 1055 o TODO 1057 Changes from version 05 to version 06: 1059 o Updated author information. 1061 o Combined "Pre-defined Terms" with "New Terms and Definitions". 1063 o Removed "Requirements language". 1065 o Removed unused reference to use case draft; resulted in removal of 1066 normative references. 1068 o Removed introductory text from Section 1 indicating that this 1069 document is intended to be temporary. 1071 o Added placeholders for missing change log entries. 1073 Changes from version 06 to version 07: 1075 o Added Contributors section. 1077 o Updated author list. 1079 o Changed title from "Terminology for Security Assessment" to 1080 "Secure Automation and Continuous Monitoring (SACM) Terminology". 1082 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 1084 o Added appendix The Attic to stash terms for future updates. 1086 o Added Authentication, Authorization, Data Confidentiality, Data 1087 Integrity, Data Origin, Data Provenance, SACM Component, SACM 1088 Component Discovery, Target Endpoint Discovery. 1090 o Major updates to Building Block, Function, SACM Role, Target 1091 Endpoint. 1093 o Minor updates to Broker, Capability, Collection Task, Evaluation 1094 Task, Posture. 1096 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 1097 Endpoint Discovery to Endpoint Identification. 1099 o Moved Asset Targeting, Client, Endpoint Identification to The 1100 Attic. 1102 o Endpoint Attributes added as a TODO. 1104 o Changed the structure of the Change Log. 1106 Changes from version 07 to version 08: 1108 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 1109 Internal Collector, Network Address, Network Interface, SACM 1110 Domain, Statement, Target Endpoint Identifier, Target Endpoint 1111 Label, Timestamp. 1113 o Major updates to Attributes, Broker, Collection Task, Consumer, 1114 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 1115 State, SACM Function, Provider, Proxy, Repository, SACM Role, 1116 Target Endpoint. 1118 o Minor updates to Asset, Building Block, Data Origin, Data Source, 1119 Data Provenance, Endpoint, Management Plane, Posture, Posture 1120 Attribute, SACM Component, SACM Component Discovery, Target 1121 Endpoint Discovery. 1123 o Relabeled Function to SACM Function. 1125 Changes from version 08 to version 09: 1127 o Updated author list. 1129 o Added Data Plane, Endpoint Characterization, Endpoint 1130 Classification, Guidance, Interaction Model, Software Component, 1131 Software Instance, Software Package, Statement, Target Endpoint 1132 Profile, SACM Task. 1134 o Removed Building Block. 1136 o Major updates to Control Plane, Endpoint Attribute, Expected 1137 Endpoint State, Information Model, Management Plane. 1139 o Minor updates to Attribute, Capabilities, SACM Function, SACM 1140 Component, Collection Task. 1142 o Moved Asset Characterization to The Attic. 1144 Changes from version 09 to version 10: 1146 o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint 1147 Management Capability, Hardware Component, Hardware Inventory, 1148 Hardware Type, SACM Interface, Target Endpoint Characterization 1149 Record, Target Endpoint Characterization Task, Target Endpoint 1150 Classification Task, Target Endpoint Discovery Task, Vulnerability 1151 Description Information, Vulnerability Detection Data, 1152 Vulnerability Management Capability, Vulnerability Assessment 1154 o Added references to i2nsf definitions in Capability, SACM 1155 Component, SACM Interface, SACM Role. 1157 o Added i2nsf Terminology I-D Reference. 1159 o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier. 1161 o Minor Updates to Guidance, SACM Component Discovery, Target 1162 Endpoint Label, Target Endpoint Profile. 1164 o Relabeled SACM Task 1166 o Removed Target Endpoint Discovery 1168 Changes from version 10 to version 11: 1170 o Added Content Element, Content Metadata, Endpoint Label, 1171 Information Element, Metadata, SACM Component Label, Workflow. 1173 o Major Updates to Assessment, Capability, Collector, Endpoint 1174 Management Capabilities, Guidance, Vulnerability Assessment 1175 Capabilities, Vulnerability Detection Data, Vulnerability 1176 Assessment Capabilities. 1178 o Minor updates to Collection Result, Control Plane, Data in Motion, 1179 Data at Rest, Data Origin, Network Interface, Statement, Target 1180 Endpoint Label. 1182 o Relabeled Endpoint Management Capability, Vulnerability Management 1183 Capability, Vulnerability Assessment. 1185 Changes from version 11 to version 12: 1187 o Added Configuration, Endpoint Characteristic, Event, SACM Content, 1188 State, Subject. 1190 o Major Updates to Assertion, Data in Motion, Data Provenance, Data 1191 Source, Interaction Model. 1193 o Minor Updates to Attribute, Control Plane, Data Origin, Data 1194 Provenance, Expected Endpoint State, Guidance, Target Endpoint 1195 Classification Task, Vulnerability Detection Data. 1197 Changes from version 12 to version 13: 1199 o Added Virtual Component. 1201 o Major Updates to Capability, Collection Task, Hardware Component, 1202 Hardware Type, Security Automation, Subject, Target Endpoint, 1203 Target Endpoint Profile. 1205 o Minor Updates to Assertion, Data Plane, Endpoint Characteristics. 1207 7. Contributors 1208 David Waltermire 1209 National Institute of Standards and Technology 1210 100 Bureau Drive 1211 Gaithersburg, MD 20877 1212 USA 1214 Email: david.waltermire@nist.gov 1216 Adam W. Montville 1217 Center for Internet Security 1218 31 Tech Valley Drive 1219 East Greenbush, NY 12061 1220 USA 1222 Email: adam.w.montville@gmail.com 1224 David Harrington 1225 Effective Software 1226 50 Harding Rd 1227 Portsmouth, NH 03801 1228 USA 1230 Email: ietfdbh@comcast.net 1232 Brian Ford 1233 Lancope 1234 3650 Brookside Parkway, Suite 500 1235 Alpharetta, GA 30022 1236 USA 1238 Email: bford@lancope.com 1240 Merike Kaeo 1241 Double Shot Security 1242 3518 Fremont Avenue North, Suite 363 1243 Seattle, WA 98103 1244 USA 1246 Email: merike@doubleshotsecurity.com 1248 8. References 1249 8.1. Normative References 1251 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1252 (PA) Protocol Compatible with Trusted Network Connect 1253 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1254 . 1256 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1257 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1258 DOI 10.17487/RFC6933, May 2013, 1259 . 1261 8.2. Informative References 1263 [I-D.ietf-i2nsf-terminology] 1264 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1265 Birkholz, "Interface to Network Security Functions (I2NSF) 1266 Terminology", draft-ietf-i2nsf-terminology-03 (work in 1267 progress), March 2017. 1269 [I-D.ietf-netmod-entity] 1270 Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1271 YANG Data Model for Hardware Management", draft-ietf- 1272 netmod-entity-03 (work in progress), March 2017. 1274 [I-D.ietf-sacm-vuln-scenario] 1275 Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., 1276 Fitzgerald-McKay, J., and D. Waltermire, "SACM 1277 Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- 1278 scenario-02 (work in progress), September 2016. 1280 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1281 Information Models and Data Models", RFC 3444, 1282 DOI 10.17487/RFC3444, January 2003, 1283 . 1285 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1286 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1287 . 1289 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1290 Tardo, "Network Endpoint Assessment (NEA): Overview and 1291 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1292 . 1294 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1295 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1296 March 2011, . 1298 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 1300 Appendix A. The Attic 1302 The following terms are stashed for now and will be updated later: 1304 Asset Characterization: Asset characterization is the process of 1305 defining attributes that describe properties of an identified 1306 asset. 1308 Asset Targeting: Asset targeting is the use of asset identification 1309 and categorization information to drive human-directed, automated 1310 decision making for data collection and analysis in support of 1311 endpoint posture assessment. 1313 Client: An architectural component receiving services from another 1314 architectural component. 1316 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 1317 The process by which an endpoint can be identified. 1319 Authors' Addresses 1321 Henk Birkholz 1322 Fraunhofer SIT 1323 Rheinstrasse 75 1324 Darmstadt 64295 1325 Germany 1327 Email: henk.birkholz@sit.fraunhofer.de 1329 Jarrett Lu 1330 Oracle Corporation 1331 4180 Network Circle 1332 Santa Clara, CA 95054 1333 USA 1335 Email: jarrett.lu@oracle.com 1337 John Strassner 1338 Huawei Technologies 1339 2330 Central Expressway 1340 Santa Clara, CA 95138 1341 USA 1343 Email: john.sc.strassner@huawei.com 1344 Nancy Cam-Winget 1345 Cisco Systems 1346 3550 Cisco Way 1347 San Jose, CA 95134 1348 USA 1350 Email: ncamwing@cisco.com