idnits 2.17.1 draft-ietf-sacm-terminology-10.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 08, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 739, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational J. Lu 5 Expires: January 9, 2017 Oracle Corporation 6 N. Cam-Winget 7 Cisco Systems 8 July 08, 2016 10 Secure Automation and Continuous Monitoring (SACM) Terminology 11 draft-ietf-sacm-terminology-10 13 Abstract 15 This memo documents terminology used in the documents produced by 16 SACM (Security Automation and Continuous Monitoring). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 9, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 57 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 58 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 59 8. Informative References . . . . . . . . . . . . . . . . . . . 21 60 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 22 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 63 1. Introduction 65 Our goal with this document is to improve our agreement on the 66 terminology used in documents produced by the IETF Working Group for 67 Security Automation and Continuous Monitoring. Agreeing on 68 terminology should help reach consensus on which problems we're 69 trying to solve, and propose solutions and decide which ones to use. 71 2. Terms and Definitions 73 This section describes terms that have been defined by other RFC's 74 and defines new ones. The predefined terms will reference the RFC 75 and where appropriate will be annotated with the specific context by 76 which the term is used in SACM. 78 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 79 entity without accompanying evidence of its validity". In the 80 context of SACM, an assertion is a collection result that includes 81 metadata about the data source (and optionally a timestamp 82 indicating the point in time the assertion was created at). The 83 validity of an assertion cannot be verified. 85 Assessment: Defined in [RFC5209] as "the process of collecting 86 posture for a set of capabilities on the endpoint (e.g., host- 87 based firewall) such that the appropriate validators may evaluate 88 the posture against compliance policy." 90 Within SACM the use of the term is expanded to support other uses 91 of collected posture (e.g. reporting, network enforcement, 92 vulnerability detection, license management). The phrase "set of 93 capabilities on the endpoint" includes: hardware and software 94 installed on the endpoint." 96 Asset: Defined in [RFC4949] as "a system resource that is (a) 97 required to be protected by an information system's security 98 policy, (b) intended to be protected by a countermeasure, or (c) 99 required for a system's mission". In the scope of SACM, an asset 100 can be composed of other assets. Examples of Assets include: 101 Endpoints, Software, Guidance, or X.509 public key certificates. 102 An asset is not necessarily owned by an organization. 104 Asset Management: The process by which assets are provisioned, 105 updated, maintained and deprecated. 107 Attribute: Defined in [RFC5209] as "data element including any 108 requisite meta-data describing an observed, expected, or the 109 operational status of an endpoint feature (e.g., anti-virus 110 software is currently in use)." If not indicated otherwise, 111 attributes in SACM are represented and processed as attribute 112 value pairs. 114 Authentication: Defined in [RFC4949] as "the process of verifying a 115 claim that a system entity or system resource has a certain 116 attribute value." 118 Authorization: Defined in [RFC4949] as "an approval that is granted 119 to a system entity to access a system resource." 121 Broker: A broker is a specific controller type that contains control 122 plane functions to provide and/or connect services on behalf of 123 other SACM components via interfaces on the control plane. A 124 broker may provide, for example, authorization services and find, 125 upon request, SACM components providing requested services. 127 Capability: In [I-D.ietf-i2nsf-terminology] a capability "defines a 128 set of features that are available from a managed entity. 129 Examples of "managed entities" are NSFs and Controllers, where NSF 130 Capabilities and Controller Capabilities define functionality of 131 an NSF and a Controller that may, but do not have to, be used, 132 respectively. All Capabilities are announced through the 133 Registration Interface." 135 In the context of SACM, the extent of a SACM component's ability 136 is enabled by the functions it is composed of. Capabilities are 137 announced by a SACM component via the SACM component registration 138 task and can be discovered by or negotiated with other SACM 139 components. For example, the capability of a SACM Provider may be 140 to provide endpoint management data, or only a subset of that 141 data. 143 Collection Result: Information about a target endpoint that is 144 produced by a collector conducting a collection task. A 145 collection result is composed of one or more endpoint attributes. 147 Collection Task: The task by which endpoint attributes and/or 148 corresponding attribute values about a target endpoint are 149 collected. The collection tasks are targeted at specific target 150 endpoints and therefore are targeted tasks. 152 There are three types of frequency collection tasks can be 153 conducted with: 155 ad-hoc, e.g. triggered by a specific event or a query 157 scheduled, e.g. in regular intervals, such as every minute or 158 weekly 160 continuously, e.g. a network behavior observation 162 There are three types of collection methods, each requiring an 163 appropriate set of functions to be included in the SACM component 164 conducting the collection task: 166 Self-Reporting: A SACM component located on the target endpoint 167 itself conducts the collection task. 169 Remote-Acquisition: A SACM component located on an Endpoint 170 different from the target endpoint conducts the collection task 171 via interfaces available on the target endpoint, e.g. SNMP/ 172 NETCONF or WMI. 174 Behavior-Observation: A SACM component located on an Endpoint 175 different from the target endpoint observes network traffic 176 related to the target endpoint and conducts the collection task 177 via interpretation of that network traffic. 179 Collector: A piece of software that acquires information about one 180 or more target endpoints by conducting collection tasks. A 181 collector provides acquired information to SACM components in the 182 form of collection results. A SACM component that consumes 183 collection results may take on the role of a provider and publish 184 the collection results in a SACM domain. (TBD: A collector may 185 not be a SACM component and therefore not part of a SACM domain). 187 Configuration Drift: The discrepancy of endpoint attributes 188 representing the actual composition of a target endpoint (is- 189 state) and its intended composition (should-state) in the scope of 190 a valid target endpoint composition (could-state) due to 191 continuous alteration of a target endpoint's composition over 192 time. Configuration drift exists for both hardware components and 193 software components. Typically, the frequency and scale of 194 configuration drift of software components is significantly higher 195 than the configuration drift of hardware components. 197 Consumer: A consumer is a SACM role that is assigned to a SACM 198 component that contains functions to receive information from 199 other SACM components. 201 Control Plane: Typically used as a term in the context of routing, 202 e.g. [RFC6192]. In the context of SACM, the control plane is an 203 architectural component providing common control functions to all 204 SACM components, including authentication, authorization, 205 capability discovery or negotiation. The control plane 206 orchestrates the flow on the data plane according to guidance and/ 207 or input from the management plane. SACM components with 208 interfaces to the control plane have knowledge of the capabilities 209 of other SACM components within a SACM domain. 211 Controller: A controller is a SACM role that is assigned to a SACM 212 component containing control plane functions that manage and 213 facilitate information sharing or execute on security functions. 214 There are three types of SACM controllers: Broker, Proxy, and 215 Repository. Depending on its type, a controller can also contain 216 functions that have interfaces on the data plane. 218 Data Confidentiality: Defined in [RFC4949] as "the property that 219 data is not disclosed to system entities unless they have been 220 authorized to know the data." 222 Data In Motion: Data that is being transported via a network. Data 223 in motion requires a data model to encode data in order to be 224 transported. Typically, data in motion is serialized 225 (marshalling) into a transport encoding by a provider of 226 information and deserialized (unmarshalling) by a consumer of 227 information. 229 SACM architecture and corresponding models focus on data in 230 motion. 232 Data At Rest: Data that is stored in a repository. Data at rest 233 requires a data model to encode data in order to be stored. In 234 the context of SACM, data at rest located on a SACM component can 235 be provided to other SACM components via discoverable 236 capabilities. 238 In the context of SACM, data models for data at rest are out of 239 scope. 241 Data Integrity: Defined in [RFC4949] as "the property that data has 242 not been changed, destroyed, or lost in an unauthorized or 243 accidental manner." 245 Data Origin: One or more properties that enable a SACM component to 246 identify the SACM component that initially acquired or produced 247 data about a (target) endpoint (e.g. via collection from a data 248 source). 250 Data Plane: Typically used as a term in the context of routing (and 251 used as a synonym for forwarding plane, e.g. [RFC6192]). In the 252 context of SACM, the data plane is an architectural component 253 providing operational functions to enable a SACM component to 254 provide and consume SACM statements and therefore SACM content 255 (the "payload"). The data plane is used to conduct distributed 256 SACM tasks by transporting SACM content using transporting 257 encodings and corresponding operations defined by SACM data 258 models. 260 Data Provenance: A historical record of the sources, origins and 261 evolution of data that is influenced by inputs, entities, 262 functions and processes. 264 Data Source: One or more properties that enable a SACM component to 265 identify an (target) endpoint that is claimed to be the original 266 source of received data. 268 Endpoint: Defined in [RFC5209] as "any computing device that can be 269 connected to a network. Such devices normally are associated with 270 a particular link layer address before joining the network and 271 potentially an IP address once on the network. This includes: 272 laptops, desktops, servers, cell phones, or any device that may 273 have an IP address." 275 To further clarify the [RFC5209] definition, an endpoint is any 276 physical or virtual device that may have a network address. Note 277 that, network infrastructure devices (e.g. switches, routers, 278 firewalls), which fit the definition, are also considered to be 279 endpoints within this document. 281 Physical endpoints are always composites that are composed of 282 hardware components and software components. Virtual endpoints 283 are composed entirely of software components and rely on software 284 components that provide functions equivalent to hardware 285 components. 287 The SACM architecture differentiates two essential categories of 288 endpoints: Endpoints whose security posture is intended to be 289 assessed (target endpoints) and endpoints that are specifically 290 excluded from endpoint posture assessment (excluded endpoints). 292 Based on the definition of an asset, an endpoint is a type of 293 asset. 295 Endpoint Attribute: In the context of SACM, endpoint attributes are 296 information elements that describe a characteristic of a target 297 endpoint. Endpoint Attributes typically constitute atomic 298 information elements (AVP) that can be bundled into composite 299 information elements (e.g. information about a specific network 300 interface can be represented via a set of multiple AVP). 302 Endpoint Characterization: The task by which a profile is composed 303 out of endpoint attributes that describe the desired or expected 304 posture of a type or class of target endpoints or even an 305 individual target endpoint. The result of this task is an 306 endpoint profile that is required as guidance for the tasks of 307 endpoint classification or posture assessment. 309 Endpoint Classification: The task by which a discovered target 310 endpoint is classified. Endpoint classification requires guidance 311 in the form of an endpoint profile, discovery results and 312 potentially collection results. Types, classes or the 313 characteristics of an individual target endpoint are defined via 314 endpoint profiles. 316 Endpoint Management Capability: An enterprise IT capability managing 317 endpoint identity, endpoint information, and associated metadata 318 on an ongoing basis. 320 Evaluation Task: The task by which endpoint attributes are 321 evaluated. 323 Evaluation Result: The resulting value from having evaluated a set 324 of posture attributes. 326 Excluded Endpoint: A specific designation, which is assigned to an 327 endpoint that is not supposed to be the subject of a collection 328 task (and therefore is not a target endpoint). Typically but not 329 necessarily, endpoints that contain a SACM component (and are 330 therefore part of the SACM domain) are designated as excluded 331 endpoints. Target endpoints that contain a SACM component cannot 332 be designated as excluded endpoints and are part of the SACM 333 domain. 335 Expected Endpoint State: The required state of an endpoint that is 336 to be compared against. Sets of expected endpoint states are 337 transported as guidance in target endpoint profiles via the 338 management plane. This, for example, can be a policy, but also a 339 recorded past state. An expected state is represented can be 340 represented via a atomic information element or an composite 341 information element that represents a set of multiple attribute 342 value pairs. 344 SACM Function: A behavioral aspect or capacity of a particular SACM 345 component, which belies that SACM component's purpose. For 346 example, a SACM function with interfaces on the control plane can 347 provide a brokering function to other SACM components. Via data 348 plane interfaces, a function can act as a provider and/or as a 349 consumer of information. SACM functions can be propagated as the 350 capabilities of a SACM component and can be discovered by or 351 negotiated with other SACM components. 353 Guidance: Input instructions to processes and tasks, such as 354 collecting, assessing or reporting. Guidance influences the 355 behavior of a SACM component and is considered content of the 356 management plane. Guidance can be manually or automatically 357 generated or provided. Typically, the tasks that provide guidance 358 to SACM components have a low-frequency and tend to be be 359 sporadic. A prominent example of guidance are target endpoint 360 profiles, but guidance can have many forms, including: 362 Configuration, e.g. a SACM component's name, or a CMDB's IPv6 363 address. 365 Profiles, e.g. a set of expected states for network behavior 366 associated with target endpoints employed by specific users. 368 Policies, e.g. an interval to refresh the registration of a SACM 369 component, or a list of required capabilities for SACM components 370 in a specific location. 372 Hardware Component: Hardware components are the distinguishable 373 physical components that compose an endpoint. The composition of 374 an endpoint can be changed over time by adding or removing 375 hardware components. In essence, every physical endpoint is 376 potentially a composite of multiple hardware components, typically 377 resulting in a hierarchical composition of hardware components. 378 The composition of hardware components is based on interconnects 379 provided by specific hardware types (e.g. mainboard is a hardware 380 type that provides local busses as an interconnect). In general, 381 a hardware component can be distinguished by its serial number. 382 Occasionally, hardware components are refered to as power sucking 383 aliens. 385 Hardware Inventory: The list of hardware components that compose a 386 specific endpoint representing its hardware configuration. 388 Hardware Type: Hardware types define specific and distinguishable 389 categories of hardware components that can be part of endpoints, 390 e.g. CPU or 802.11p interface. Typically, hardware types can be 391 distinguished by their vendor assigned names, names of standards 392 used, or a model name. 394 Information Model: An information model is an abstract 395 representation of data, their properties, relationships between 396 data and the operations that can be performed on the data. While 397 there is some overlap with a data model, [RFC3444] distinguishes 398 an information model as being protocol and implementation neutral 399 whereas a data model would provide such details. The purpose of 400 the SACM information model is to ensure interoperability between 401 SACM data models (that are used as transport encoding) and to 402 provide a standardized set of information elements for 403 communication between SACM components. 405 Interaction Model: For now this is a Place-Holder. Is an 406 interaction model that defines, for example, the operations on the 407 control plane, such as registration or SACM component discovery, 408 required? 410 Internal Collector: Internal Collector: a collector that runs on a 411 target endpoint to acquire information from that target endpoint. 412 (TBD: An internal collector is not a SACM component and therefore 413 not part of a SACM domain). 415 Management Plane: An architectural component providing common 416 functions to steer the behavior of SACM components, e.g. its 417 behavior on the control plane. Prominent examples include: 418 modification of the configuration of a SACM component or updating 419 a target endpoint profile that resides on an evaluator. In 420 essence, guidance is transported via the management plane. 421 Typically, a SACM component can fulfill its purpose without 422 continuous input from the management plane. In contrast, without 423 continuous availability of control plane functions a typical SACM 424 component could not function properly. In general, interaction on 425 the management plane is less frequent and less regular than on the 426 control plane. Input via the management plane can be manual (e.g. 427 via a CLI), or can be automated via management plane functions 428 that are part of other SACM components. 430 Network Address: Network addresses are layer specific and follow 431 layer specific address schemes. Each interface of a specific 432 layer can be associated with one or more addresses appropriate for 433 that layer. There is no guarantee that an address is globally 434 unique. In general, there is a scope to an address in which it is 435 intended to be unique. 437 Examples include: physical Ethernet port with a MAC address, layer 438 2 VLAN interface with a MAC address, layer 3 interface with 439 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 440 IPv4 address. 442 Network Interface: An endpoint is connected to a network via one or 443 more interfaces. Interfaces can be physical or virtual. 444 Interfaces of an endpoint can operate on different layers, most 445 prominently what is now commonly called layer 2 and 3. Within a 446 layer, interfaces can be nested. On layer 2, a root interface is 447 typically associated with a physical interface port and nested 448 interfaces are virtual interfaces. In the case of a virtual 449 endpoint, a root interface can be a virtual interface. Virtual 450 layer 2 interfaces of one or more endpoints can also constitute an 451 aggregated group of links that act as one. On layer 3, nested 452 interfaces typically constitute virtual tunnels or networks. 454 Examples include: physical Ethernet port, layer 2 VLAN interface, 455 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 457 Posture: Defined in [RFC5209] as "configuration and/or status of 458 hardware or software on an endpoint as it pertains to an 459 organization's security policy." 461 This term is used within the scope of SACM to represent the 462 configuration and state information that is collected from a 463 target endpoint in the form of endpoint attributes (e.g. software/ 464 hardware inventory, configuration settings, dynamically assigned 465 addresses). This information may constitute one or more posture 466 attributes. 468 Posture Attributes: Defined in [RFC5209] as "attributes describing 469 the configuration or status (posture) of a feature of the 470 endpoint. A Posture Attribute represents a single property of an 471 observed state. For example, a Posture Attribute might describe 472 the version of the operating system installed on the system." 474 Within this document this term represents a specific assertion 475 about endpoint configuration or state (e.g. configuration setting, 476 installed software, hardware) represented via endpoint attributes. 477 The phrase "features of the endpoint" highlighted above refers to 478 installed software or software components. 480 Provider: A provider is a SACM role that is assigned to a SACM 481 component that contains functions to provide information to other 482 SACM components. 484 Proxy: A proxy is a specific controller type that provides data 485 plane and control plane functions, information, or services on 486 behalf of another component, which is not directly participating 487 in the SACM architecture. 489 Repository: A repository is a specific controller type that contains 490 functions to consume, store and provide information of a 491 particular kind - typically data transported on the data plane, 492 but potentially also data and metadata from the control and 493 management plane. A single repository may provide the functions 494 of more than one specific repository type (i.e. configuration 495 baseline repository, assessment results repository, etc.) 497 SACM Component: A component is defined in 498 [I-D.ietf-i2nsf-terminology] as "an encapsulation of software that 499 communicates using Interfaces. A Component may be implemented by 500 hardware and/or Software, and be represented using a set of 501 classes. In general, a Component encapsulates a set of data 502 structures as well as a set of algorithms that implement the 503 functions that it provides." 505 In the context of SACM, a set of SACM functions composes a SACM 506 component. A SACM component conducts SACM tasks, acting on 507 control plane, data plane and/or management plane via 508 corresponding SACM interfaces. SACM defines a set of standard 509 components (e.g. a collector, a broker, or a data store). A SACM 510 component contains at least a basic set of control plane functions 511 and can contain data plane and management plane functions. A SACM 512 component residing on an endpoint assigns one or more SACM roles 513 to the corresponding endpoint due to the SACM functions it is 514 composed of. A SACM component "resides on" an endpoint and an 515 endpoint "contains" a SACM component, correspondingly. For 516 example, a SACM component that is composed solely of functions 517 that provide information would only take on the role of a 518 provider. 520 SACM Component Discovery: The task of brokering appropriate SACM 521 components according to their capabilities or roles on reques. 523 Input: Query 525 Output: a list of SACM components including metadata 527 SACM Domain: Endpoints that include a SACM component compose a SACM 528 domain. (To be revised, additional definition content TBD, 529 possible dependencies to SACM architecture) 531 SACM Interface: An interface is defined in 532 [I-D.ietf-i2nsf-terminology] as "A set of operations one object 533 knows it can invoke on, and expose to, another object. This 534 decouples the implementation of the operation from its 535 specification. An interface is a subset of all operations that a 536 given object implements. The same object may have multiple types 537 of interfaces to serve different purposes." 539 In the context of SACM, SACM Funktions provide SACM Interfaces on 540 the management, control, or data plane. Operations a SACM 541 Interface provides are based on corresponding data model defined 542 by SACM. SACM Interfaces are used for communication between SACM 543 components. 545 SACM Role: A role is defined in [I-D.ietf-i2nsf-terminology] as "an 546 abstraction of a Component that models context-specific views and 547 responsibilities of an object as separate role objects that can be 548 statically or dynamically attached to (and removed from) the 549 object that the role object describes. This provides three 550 important benefits. First, it enables different behavior to be 551 supported by the same Component for different contexts. Second, 552 it enables the behavior of a Component to be adjusted dynamically 553 (i.e., at runtime, in response)to changes in context, by using one 554 or more Roles to define the behavior desired for each context. 555 Third, it decouples the Roles of a Component from the Applications 556 that use that Component." 558 In the context of SACM, SACM roles are associated with SACM 559 components and are defined by the set of functions and interfaces 560 a SACM component includes. There are three SACM roles: provider, 561 consumer, and controller. The roles associated with a SACM 562 component are determined by the purpose of the SACM functions and 563 corresponding SACM interfaces the SACM component is composed of. 565 Security Automation: The process of which security alerts can be 566 automated through the use of different tools to monitor, evaluate 567 and analyze endpoint and network traffic for the purposes of 568 detecting misconfigurations, misbehaviors or threats. 570 Software Package: A generic software package (e.g. a text editor). 572 Software Component: A software package installed on an endpoint, 573 including a unique serial number if present (e.g. a text editor 574 associated with a unique license key). 576 Software Instance: A running instance of the software component 577 (e.g. on a multi-user system, one logged-in user has one instance 578 of a text editor running and another logged-in user has another 579 instance of the same text editor running, or on a single-user 580 system, a user could have multiple independent instances of the 581 same text editor running). 583 Statement: The output of a provider, e.g. a report or an assertion 584 acquired via a collection result from a collector, that includes 585 metadata about the data origin and the point in time the statement 586 was created at. A statement can be accompanied by evidence of the 587 validity of its metadata. 589 Supplicant: The entity seeking to be authenticated by the Management 590 Plane for the purpose of participating in the SACM architecture. 592 System Resource: Defined in [RFC4949] as "data contained in an 593 information system; or a service provided by a system; or a system 594 capacity, such as processing power or communication bandwidth; or 595 an item of system equipment (i.e., hardware, firmware, software, 596 or documentation); or a facility that houses system operations and 597 equipment. 599 Target Endpoint: A target endpoint is an "endpoint under assessment" 600 (even if it is not actively under assessment at all times) or 601 "endpoint of interest". Every endpoint that is not specifically 602 designated as an excluded endpoint is a target endpoint. A target 603 endpoint is not part of a SACM domain unless it contains a SACM 604 component (e.g. a SACM component that publishes collection results 605 coming from an internal collector). 607 A target endpoint is similar to a device that is a Target of 608 Evaluation (TOE) as defined in Common Criteria. 610 Target Endpoint Characterization Record: A set of endpoint 611 attributes about a target endpoint that was encountered in a SACM 612 domain, which are associated with a target endpoint by being 613 included in the corresponding record. A characterization record 614 is intended to be a representation of an endpoint. It cannot be 615 assured that a record distinctly represents a single target 616 endpoint unless a set of one or more endpoint attributes that 617 compose a unique set of identifying endpoint attributes are 618 included in the record. Otherwise, the set of identifying 619 attributes included in a record can match more than one target 620 endpoints, which are - in consequence - indistinguishable to a 621 SACM domain until more qualifying endpoint attributes can be 622 acquired and added to the record. A characterization record is 623 maintained over time in order to assert that acquired endpoint 624 attributes are either about an endpoint that was encountered 625 before or an endpoint that has not been encountered before in a 626 SACM domain. A characterization record can include, for example, 627 acquired configuration, state or observed behavior of a specific 628 target endpoint. Multiple and even conflicting instances of this 629 information can be included in a characterization record by using 630 timestamps and/or data origins to differentiate them. The 631 endpoint attributes included in a characterization record can be 632 used to re-identify a distinct target endpoint over time. Classes 633 or profiles can be associated with a characterization record via 634 the Classification Task in order to guide collection, evaluation 635 or remediation tasks. 637 Target Endpoint Characterization Task: An ongoing task of 638 continuously adding acquired endpoint attributes to a 639 corresponding record. The TE characterization task manages the 640 representation of encountered target endpoints in the SACM domain 641 in the form of characterization records. For example, the output 642 of a target endpoint discovery task or a collection task can be 643 processed by the characterization task and added to the record. 644 The TE characterization Task also manages these representations of 645 target endpoints encountered in the SACM domain by splitting or 646 merging the corresponding records as new or more refined endpoint 647 attributes become available. 649 Input: discovered target endpoint attributes, endpoint attribute 650 collection, existing characterization records 652 Output: target endpoint characterization records 654 Target Endpoint Classification Task: The task of associating a class 655 from an extensible list of classes with an endpoint 656 characterization record. TE classes function as guidance for 657 collection, evaluation, remediation and security posture 658 assessment in general. 660 Input: endpoint characterization records (without classification), 661 guidance (how to classify a record) 663 Output: endpoint characterization records (with classification) 665 Target Endpoint Discovery Task: The ongoing task of detecting 666 previously unknown interaction of a potential target endpoint in 667 the SACM domain. TE Discovery is not directly targeted at a 668 specific target endpoint and therefore an un-targeted task. SACM 669 Components conducting the discovery task as a part of their 670 function are typically distributed and located, for example, on 671 infrastructure components or collect from those remotely via 672 appropriate interfaces. Examples of infrastructure components 673 that are of interest to the discovery task include routers, 674 switches, VM hosting or VM managing components, AAA servers, or 675 servers handling dynamic address distribution. 677 Input: endpoint attributes acquired via local or remote interfaces 679 Output: endpoint attributes including metadata such as data source 680 or data origin 682 Target Endpoint Identifier: The target endpoint discovery task and 683 the collection tasks can result in a set of identifying endpoint 684 attributes added to a corresponding Characterization Record. This 685 subset of the endpoint attributes included in the record is used 686 as a target endpoint identifier, by which a specific target 687 endpoint can be referenced. Depending on the available 688 identifying attributes, this reference can be ambiguous and is a 689 "best-effort" mechanism. Every distinct set of identifying 690 endpoint attributes can be associated with a target endpoint label 691 that is unique in a SACM domain. 693 Target Endpoint Label: An artificially created id that references a 694 distinct set of identifying attributes (Target Endpoint 695 Identifier). A target endpoint label is unique in a SACM domain 696 and created by a SACM component that provides the appropriate 697 function as a capability. 699 Target Endpoint Profile: A bundle of expected or desired 700 configurations and states (typically a composition of endpoint 701 attribute value pairs) that can be associated with a target 702 endpoint. The corresponding task by which the association with a 703 target endpoint takes places is the endpoint classification. The 704 task by which an endpoint profile is created is the endpoint 705 characterization. A type or class of target endpoints is defined 706 within a target endpoint profile, e.g. printer, smartphone, or an 707 office PC. 709 SACM Task: A SACM task is conducted by one or more SACM functions 710 that reside on a SACM component (e.g. a collection task or 711 endpoint characterization). A SACM task can be triggered by other 712 operations or functions (e.g. a query from another SACM component 713 or an unsolicited push on the data plane due to an ongoing 714 subscription). A task is part of a SACM process chain. A task 715 starts at a given point in time and ends in a deterministic state. 716 With the exception of a collection task, a SACM task consumes SACM 717 statements provided by other SACM components. The output of a 718 task is a result that can be provided (e.g. published) on the data 719 plane. There following tasks are defined by SACM: 721 Target Endpoint Discovery 723 Target Endpoint Characterization 725 Target Endpoint Classification 727 Collection 729 Evaluation [TBD] 731 Information Sharing [TBD] 733 SACM Component Discovery 735 SACM Component Authentication [TBD] 737 SACM Component Authorization [TBD] 739 SACM Component Registration [TBD] 741 Timestamps : Defined in [RFC4949] as "with respect to a data object, 742 a label or marking in which is recorded the time (time of day or 743 other instant of elapsed time) at which the label or marking was 744 affixed to the data object" and as "with respect to a recorded 745 network event, a data field in which is recorded the time (time of 746 day or other instant of elapsed time) at which the event took 747 place.". 749 This term is used in SACM to describe a recorded point in time at 750 which an endpoint attribute is created or updated by a target 751 endpoint and observed, transmitted or processed by a SACM 752 component. Timestamps can be created by target endpoints or SACM 753 components and are associated with endpoint attributes provided or 754 consumed by SACM components. Outside of the domain of SACM 755 components the assurance of correctness of time stamps is 756 typically significantly lower than inside a SACM domain. In 757 general, it cannot be simply assumed that the source of time a 758 target endpoint uses is synchronized or trustworthy. 760 Vulnerability Assessment: The process of determining whether a set 761 of endpoints is vulnerable according to the information contained 762 in the vulnerability description information. 764 Vulnerability Description Information: Information pertaining to the 765 existence of a flaw or flaws in software, hardware, and/or 766 firmware, which could potentially have an adverse impact on 767 enterprise IT functionality and/or security. Vulnerability 768 description information should contain enough information to 769 support vulnerability detection. 771 Vulnerability Detection Data: A type of guidance extracted from 772 vulnerability description information that describes the specific 773 mechanisms of vulnerability detection that is used by an 774 enterprise's vulnerability management capability to determine if a 775 vulnerability is present on an endpoint. 777 Vulnerability Management Capability: An enterprise IT capability 778 managing endpoint vulnerabilities and associated metadata on an 779 ongoing basis by ingesting vulnerability description information 780 and vulnerability detection data, and performing a vulnerability 781 assessment. 783 3. IANA Considerations 785 This memo includes no request to IANA. 787 4. Security Considerations 789 This memo documents terminology for security automation. While it is 790 about security, it does not affect security. 792 5. Acknowledgements 794 6. Change Log 796 Changes from version 00 to version 01: 798 o Added simple list of terms extracted from UC draft -05. It is 799 expected that comments will be received on this list of terms as 800 to whether they should be kept in this document. Those that are 801 kept will be appropriately defined or cited. 803 Changes from version 01 to version 02: 805 o Added Vulnerability, Vulnerability Management, xposure, 806 Misconfiguration, and Software flaw. 808 Changes from version 02 to version 03: 810 o Removed Section 2.1. Cleaned up some editing nits; broke terms 811 into 2 sections (predefined and newly defined terms). Added some 812 of the relevant terms per the proposed list discussed in the IETF 813 89 meeting. 815 Changes from version 03 to version 04: 817 o TODO 819 Changes from version 04 to version 05: 821 o TODO 823 Changes from version 05 to version 06: 825 o Updated author information. 827 o Combined "Pre-defined Terms" with "New Terms and Definitions". 829 o Removed "Requirements language". 831 o Removed unused reference to use case draft; resulted in removal of 832 normative references. 834 o Removed introductory text from Section 1 indicating that this 835 document is intended to be temporary. 837 o Added placeholders for missing change log entries. 839 Changes from version 06 to version 07: 841 o Added Contributors section. 843 o Updated author list. 845 o Changed title from "Terminology for Security Assessment" to 846 "Secure Automation and Continuous Monitoring (SACM) Terminology". 848 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 850 o Added appendix The Attic to stash terms for future updates. 852 o Added Authentication, Authorization, Data Confidentiality, Data 853 Integrity, Data Origin, Data Provenance, SACM Component, SACM 854 Component Discovery, Target Endpoint Discovery. 856 o Major updates to Building Block, Function, SACM Role, Target 857 Endpoint. 859 o Minor updates to Broker, Capability, Collection Task, Evaluation 860 Task, Posture. 862 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 863 Endpoint Discovery to Endpoint Identification. 865 o Moved Asset Targeting, Client, Endpoint Identification to The 866 Attic. 868 o Endpoint Attributes added as a TODO. 870 o Changed the structure of the Change Log. 872 Changes from version 07 to version 08: 874 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 875 Internal Collector, Network Address, Network Interface, SACM 876 Domain, Statement, Target Endpoint Identifier, Target Endpoint 877 Label, Timestamp. 879 o Major updates to Attributes, Broker, Collection Task, Consumer, 880 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 881 State, SACM Function, Provider, Proxy, Repository, SACM Role, 882 Target Endpoint. 884 o Minor updates to Asset, Building Block, Data Origin, Data Source, 885 Data Provenance, Endpoint, Management Plane, Posture, Posture 886 Attribute, SACM Component, SACM Component Discovery, Target 887 Endpoint Discovery. 889 o Relabeled Function to SACM Function. 891 Changes from version 08 to version 09: 893 o Updated author list. 895 o Added Data Plane, Endpoint Characterization, Endpoint 896 Classification, Guidance, Interaction Model, Software Component, 897 Software Instance, Software Package, Statement, Target Endpoint 898 Profile, SACM Task. 900 o Removed Building Block. 902 o Major updates to Control Plane, Endpoint Attribute, Expected 903 Endpoint State, Information Model, Management Plane. 905 o Minor updates to Attribute, Capabilities, SACM Function, SACM 906 Component, Collection Task. 908 o Moved Asset Characterization to The Attic. 910 Changes from version 09 to version 10: 912 o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint 913 Management Capability, Hardware Component, Hardware Inventory, 914 Hardware Type, SACM Interface, Target Endpoint Characterization 915 Record, Target Endpoint Characterization Task, Target Endpoint 916 Classification Task, Target Endpoint Discovery Task, Vulnerability 917 Description Information, Vulnerability Detection Data, 918 Vulnerability Management Capability, Vulnerability Assessment 920 o Added references to i2nsf definitions in Capability, SACM 921 Component, SACM Interface, SACM Role 923 o Added i2nsf Terminology I-D Reference 925 o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier 927 o Minor Updates to Guidance, SACM Component Discovery, Target 928 Endpoint Label, Target Endpoint Profile 930 o Relabled SACM Task 932 o Removed Target Endpoint Discovery 934 7. Contributors 936 John Strassner 937 Huawei 938 Santa Clara, CA 939 USA 941 Email: john.sc.strassner@huawei.com 943 David Waltermire 944 National Institute of Standards and Technology 945 100 Bureau Drive 946 Gaithersburg, MD 20877 947 USA 949 Email: david.waltermire@nist.gov 951 Adam W. Montville 952 Center for Internet Security 953 31 Tech Valley Drive 954 East Greenbush, NY 12061 955 USA 957 Email: adam.w.montville@gmail.com 958 David Harrington 959 Effective Software 960 50 Harding Rd 961 Portsmouth, NH 03801 962 USA 964 Email: ietfdbh@comcast.net 966 Brian Ford 967 Lancope 968 3650 Brookside Parkway, Suite 500 969 Alpharetta, GA 30022 970 USA 972 Email: bford@lancope.com 974 Merike Kaeo 975 Double Shot Security 976 3518 Fremont Avenue North, Suite 363 977 Seattle, WA 98103 978 USA 980 Email: merike@doubleshotsecurity.com 982 8. Informative References 984 [I-D.ietf-i2nsf-terminology] 985 Hares, S., Strassner, J., Lopez, D., and L. Xia, 986 "Interface to Network Security Functions (I2NSF) 987 Terminology", draft-ietf-i2nsf-terminology-00 (work in 988 progress), May 2016. 990 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 991 Information Models and Data Models", RFC 3444, 992 DOI 10.17487/RFC3444, January 2003, 993 . 995 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 996 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 997 . 999 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1000 Tardo, "Network Endpoint Assessment (NEA): Overview and 1001 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1002 . 1004 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1005 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1006 March 2011, . 1008 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 1010 Appendix A. The Attic 1012 The following terms are stashed for now and will be updated later: 1014 Asset Characterization: Asset characterization is the process of 1015 defining attributes that describe properties of an identified 1016 asset. 1018 Asset Targeting: Asset targeting is the use of asset identification 1019 and categorization information to drive human-directed, automated 1020 decision making for data collection and analysis in support of 1021 endpoint posture assessment. 1023 Client: An architectural component receiving services from another 1024 architectural component. 1026 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 1027 The process by which an endpoint can be identified. 1029 Authors' Addresses 1031 Henk Birkholz 1032 Fraunhofer SIT 1033 Rheinstrasse 75 1034 Darmstadt 64295 1035 Germany 1037 Email: henk.birkholz@sit.fraunhofer.de 1039 Jarrett Lu 1040 Oracle Corporation 1041 4180 Network Circle 1042 Santa Clara, CA 95054 1043 USA 1045 Email: jarrett.lu@oracle.com 1046 Nancy Cam-Winget 1047 Cisco Systems 1048 3550 Cisco Way 1049 San Jose, CA 95134 1050 USA 1052 Email: ncamwing@cisco.com