idnits 2.17.1 draft-ietf-sacm-terminology-11.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 (September 12, 2016) is 2773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 815, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-01 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: March 16, 2017 Oracle Corporation 6 J. Strassner 7 Huawei Technologies 8 N. Cam-Winget 9 Cisco Systems 10 September 12, 2016 12 Secure Automation and Continuous Monitoring (SACM) Terminology 13 draft-ietf-sacm-terminology-11 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 March 16, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 19 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 59 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 60 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 61 8. Informative References . . . . . . . . . . . . . . . . . . . 23 62 Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 24 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 65 1. Introduction 67 Our goal with this document is to improve our agreement on the 68 terminology used in documents produced by the IETF Working Group for 69 Security Automation and Continuous Monitoring. Agreeing on 70 terminology should help reach consensus on which problems we're 71 trying to solve, and propose solutions and decide which ones to use. 73 2. Terms and Definitions 75 This section describes terms that have been defined by other RFC's 76 and defines new ones. The predefined terms will reference the RFC 77 and where appropriate will be annotated with the specific context by 78 which the term is used in SACM. 80 Assertion: Defined by the ITU in [X.1252] as "a statement made by an 81 entity without accompanying evidence of its validity". In the 82 context of SACM, an assertion is a collection result that includes 83 metadata about the data source (and optionally a timestamp 84 indicating the point in time the assertion was created at). The 85 validity of an assertion cannot be verified. 87 Assessment: Defined in [RFC5209] as "the process of collecting 88 posture for a set of capabilities on the endpoint (e.g., host- 89 based firewall) such that the appropriate validators may evaluate 90 the posture against compliance policy." 92 Assessment is a specifc workflow that incorporates the SACM tasks 93 discovery, collection and evaluation. A prominent instance of the 94 assessment workflow is illustrated in the Vulnerability 95 Assessement Scenario [I-D.ietf-sacm-vuln-scenario] 97 Asset: Defined in [RFC4949] as "a system resource that is (a) 98 required to be protected by an information system's security 99 policy, (b) intended to be protected by a countermeasure, or (c) 100 required for a system's mission". In the scope of SACM, an asset 101 can be composed of other assets. Examples of Assets include: 102 Endpoints, Software, Guidance, or X.509 public key certificates. 103 An asset is not necessarily owned by an organization. 105 Asset Management: The process by which assets are provisioned, 106 updated, maintained and deprecated. 108 Attribute: TODO, Update definition. Defined in [RFC5209] as "data 109 element including any requisite meta-data describing an observed, 110 expected, or the operational status of an endpoint feature (e.g., 111 anti-virus software is currently in use)." If not indicated 112 otherwise, attributes in SACM are represented and processed as 113 attribute value pairs. 115 Authentication: Defined in [RFC4949] as "the process of verifying a 116 claim that a system entity or system resource has a certain 117 attribute value." 119 Authorization: Defined in [RFC4949] as "an approval that is granted 120 to a system entity to access a system resource." 122 Broker: A broker is a specific controller type that contains control 123 plane functions to provide and/or connect services on behalf of 124 other SACM components via interfaces on the control plane. A 125 broker may provide, for example, authorization services and find, 126 upon request, SACM components providing requested services. 128 Capability: In [I-D.ietf-i2nsf-terminology] a capability "defines a 129 set of features that are available from a managed entity. 130 Examples of "managed entities" are NSFs and Controllers, where NSF 131 Capabilities and Controller Capabilities define functionality of 132 an NSF and a Controller that may, but do not have to, be used, 133 respectively. All Capabilities are announced through the 134 Registration Interface." 136 In the context of SACM, the extent of a SACM component's ability 137 is enabled by the functions it is composed of. Capabilities are 138 announced by a SACM component via the SACM component registration 139 task and can be discovered by or negotiated with other SACM 140 components. For example, the capability of a SACM Provider may be 141 to provide endpoint management data, or only a subset of that 142 data. 144 The SACM Vulnerability Assessment Scenario 145 [I-D.ietf-sacm-vuln-scenario] defines the terms Endpoint 146 Management Capabilities, Vulnerability Management Capabilities, 147 and Vulnerability Assessment Capabilities, which illustrate 148 specific sets of SACM capabilities, which are required to conduct 149 workflows illustrated by the scenario definition. 151 Collection Result: Information about a target endpoint that is 152 produced by a collector conducting a collection task. A 153 collection result is composed as one or more content-elements. 155 Collection Task: The task by which endpoint attributes and/or 156 corresponding attribute values about a target endpoint are 157 collected. The collection tasks are targeted at specific target 158 endpoints and therefore are targeted tasks. 160 There are three types of frequency collection tasks can be 161 conducted with: 163 ad-hoc, e.g. triggered by a specific event or a query 165 scheduled, e.g. in regular intervals, such as every minute or 166 weekly 168 continuously, e.g. a network behavior observation 170 There are three types of collection methods, each requiring an 171 appropriate set of functions to be included in the SACM component 172 conducting the collection task: 174 Self-Reporting: A SACM component located on the target endpoint 175 itself conducts the collection task. 177 Remote-Acquisition: A SACM component located on an Endpoint 178 different from the target endpoint conducts the collection task 179 via interfaces available on the target endpoint, e.g. SNMP/ 180 NETCONF or WMI. 182 Behavior-Observation: A SACM component located on an Endpoint 183 different from the target endpoint observes network traffic 184 related to the target endpoint and conducts the collection task 185 via interpretation of that network traffic. 187 Collector: A piece of software that acquires information about one 188 or more target endpoints by conducting collection tasks. A 189 collector provides acquired information in the form of collection 190 results via a set of registered capabilities that can be 191 discovered by other SACM components. 193 A collector can be distributed across multiple endpoints, e.g. 194 across a target endpoint and a SACM component. The separate parts 195 of the collector can communicate with a specialized protocol, such 196 as PA-TNC [RFC5792]. At least one part of a distributed collector 197 has to take on the role of a provider of information by providing 198 SACM interfaces to propagate capabilities and to provide SACM 199 content in the form of collection results. 201 Configuration Drift: The discrepancy of endpoint attributes 202 representing the actual composition of a target endpoint (is- 203 state) and its intended composition (should-state) in the scope of 204 a valid target endpoint composition (could-state) due to 205 continuous alteration of a target endpoint's composition over 206 time. Configuration drift exists for both hardware components and 207 software components. Typically, the frequency and scale of 208 configuration drift of software components is significantly higher 209 than the configuration drift of hardware components. 211 Consumer: A consumer is a SACM role that is assigned to a SACM 212 component that contains functions to receive information from 213 other SACM components. 215 Content Element: Content elements constitute the payload data 216 (content) transfered via statement Subjects emitted by providers 217 of information. Every content element Subject includes a specific 218 content Subject and a corresponding content metadata Subject. 220 Content Metadata: Data about content Subjects. Every content- 221 element includes a content metadata Subject. The Subject can 222 include any information element that can annotate the content 223 transefered. Examples include time stamps or data provenance 224 Subjects. 226 Control Plane: Typically used as a term in the context of routing, 227 e.g. [RFC6192]. In the context of SACM, the control plane is an 228 architectural component providing common control functions to all 229 SACM components, including authentication, authorization, 230 capability discovery or negotiation, and registration. The 231 control plane orchestrates the flow on the data plane according to 232 guidance received via the management plane. SACM components with 233 interfaces to the control plane have knowledge of the capabilities 234 of other SACM components within a SACM domain. 236 Controller: A controller is a SACM role that is assigned to a SACM 237 component containing control plane functions that manage and 238 facilitate information sharing or execute on security functions. 239 There are three types of SACM controllers: Broker, Proxy, and 240 Repository. Depending on its type, a controller can also contain 241 functions that have interfaces on the data plane. 243 Data Confidentiality: Defined in [RFC4949] as "the property that 244 data is not disclosed to system entities unless they have been 245 authorized to know the data." 247 Data In Motion: Data that is being transported via a network; also 248 referred to as Data in transit. Data in motion requires a data 249 model to encode the data to be transferred. Typically, data in 250 motion is serialized (marshalling) into a transport encoding by a 251 provider of information and deserialized (unmarshalling) by a 252 consumer of information. 254 SACM architecture and corresponding models focus on data in 255 motion. 257 Data At Rest: Data that is stored in a repository. Data at rest 258 requires a data model to encode the data to be stored. In the 259 context of SACM, data at rest located on a SACM component can be 260 provided to other SACM components via discoverable capabilities. 262 In the context of SACM, data models for data at rest are out of 263 scope. 265 Data Integrity: Defined in [RFC4949] as "the property that data has 266 not been changed, destroyed, or lost in an unauthorized or 267 accidental manner." 269 Data Origin: One or more properties that enable a SACM component to 270 identify the SACM component that initially acquired or produced 271 data about a (target) endpoint (e.g. via collection from a data 272 source). Data Origin is expressed by an endpoint label. 274 Data Plane: Typically used as a term in the context of routing (and 275 used as a synonym for forwarding plane, e.g. [RFC6192]). In the 276 context of SACM, the data plane is an architectural component 277 providing operational functions to enable a SACM component to 278 provide and consume SACM statements and therefore SACM content 279 (the "payload"). The data plane is used to conduct distributed 280 SACM tasks by transporting SACM content using transporting 281 encodings and corresponding operations defined by SACM data 282 models. 284 Data Provenance: A historical record of the sources, origins and 285 evolution of data that is influenced by inputs, entities, 286 functions and processes. 288 Data Source: One or more properties that enable a SACM component to 289 identify an (target) endpoint that is claimed to be the original 290 source of received data. 292 Endpoint: Defined in [RFC5209] as "any computing device that can be 293 connected to a network. Such devices normally are associated with 294 a particular link layer address before joining the network and 295 potentially an IP address once on the network. This includes: 296 laptops, desktops, servers, cell phones, or any device that may 297 have an IP address." 299 To further clarify the [RFC5209] definition, an endpoint is any 300 physical or virtual device that may have a network address. Note 301 that, network infrastructure devices (e.g. switches, routers, 302 firewalls), which fit the definition, are also considered to be 303 endpoints within this document. 305 Physical endpoints are always composites that are composed of 306 hardware components and software components. Virtual endpoints 307 are composed entirely of software components and rely on software 308 components that provide functions equivalent to hardware 309 components. 311 The SACM architecture differentiates two essential categories of 312 endpoints: Endpoints whose security posture is intended to be 313 assessed (target endpoints) and endpoints that are specifically 314 excluded from endpoint posture assessment (excluded endpoints). 316 Based on the definition of an asset, an endpoint is a type of 317 asset. 319 Endpoint Attribute: In the context of SACM, endpoint attributes are 320 information elements that describe a characteristic of a target 321 endpoint. Endpoint Attributes typically constitute Attributes 322 that can be bundled into Subject (e.g. information about a 323 specific network interface can be represented via a set of 324 multiple AVP). 326 Endpoint Characterization: The task by which a profile is composed 327 out of endpoint attributes that describe the desired or expected 328 posture of a type or class of target endpoints or even an 329 individual target endpoint. The result of this task is an 330 endpoint profile that is required as guidance for the tasks of 331 endpoint classification or posture assessment. 333 Endpoint Classification: The task by which a discovered target 334 endpoint is classified. Endpoint classification requires guidance 335 in the form of an endpoint profile, discovery results and 336 potentially collection results. Types, classes or the 337 characteristics of an individual target endpoint are defined via 338 endpoint profiles. 340 Endpoint Label: In a SACM domain, every endpoint can be identified 341 by an endpoint label. There are two prominent uses of endpoint 342 labels in a SACM domain: to identify SACM components and to 343 identify Target Endpoints. Both endpoint labels can be used in 344 SACM content or in content metadata: 346 SACM Components are identified by: SACM component label / Data 347 Origin 349 Target Endpoints are identified by: TE label / Data Source 351 An endpoint label is expressed as an artificially created ID that 352 references a distinct set of identifying attributes (Target 353 Endpoint Identifier). A target endpoint label is unique in a SACM 354 domain and created by a SACM component that provides the 355 appropriate function as a capability. 357 Endpoint Management Capabilities: An enterprise IT department's 358 ability to manage endpoint identity, endpoint information, and 359 associated metadata on an ongoing basis. 361 Evaluation Task: The task by which endpoint attributes are 362 evaluated. 364 Evaluation Result: The resulting value from having evaluated a set 365 of posture attributes. 367 Excluded Endpoint: A specific designation, which is assigned to an 368 endpoint that is not supposed to be the subject of a collection 369 task (and therefore is not a target endpoint). Typically but not 370 necessarily, endpoints that contain a SACM component (and are 371 therefore part of the SACM domain) are designated as excluded 372 endpoints. Target endpoints that contain a SACM component cannot 373 be designated as excluded endpoints and are part of the SACM 374 domain. 376 Expected Endpoint State: The required state of an endpoint that is 377 to be compared against. Sets of expected endpoint states are 378 transported as guidance in target endpoint profiles via the 379 management plane. This, for example, can be a policy, but also a 380 recorded past state. An expected state is represented can be 381 represented via an Attribute or an Subject that represents a set 382 of multiple attribute value pairs. 384 SACM Function: A behavioral aspect or capacity of a particular SACM 385 component, which belies that SACM component's purpose. For 386 example, a SACM function with interfaces on the control plane can 387 provide a brokering function to other SACM components. Via data 388 plane interfaces, a function can act as a provider and/or as a 389 consumer of information. SACM functions can be propagated as the 390 capabilities of a SACM component and can be discovered by or 391 negotiated with other SACM components. 393 Guidance: Input instructions to processes and tasks, such as 394 collection, evaluation or remediation. Guidance influences the 395 behavior of a SACM component and is considered content of the 396 management plane. In the context of SACM, guidance is machine- 397 readable and can be manually or automatically generated or 398 provided. Typically, the tasks that provide guidance to SACM 399 components have a low-frequency and tend to be be sporadic. 401 There are two types of guidance: 403 Declarative Guidance: defines the configuration or state an 404 endpoint is supposed to be in--without providing specific actions 405 or methods to produce that desired state. Examples include Target 406 Endpoint Profiles or network topology based requirements. 408 Imperative Guidance: prescribes specific actions to be conducted 409 or methods to be used in order to achieve an outcome. Examples 410 include a targeted Collection Task or the IP-Address of a SACM 411 Component that provides a registration function. 413 Hardware Component: Hardware components are the distinguishable 414 physical components that compose an endpoint. The composition of 415 an endpoint can be changed over time by adding or removing 416 hardware components. In essence, every physical endpoint is 417 potentially a composite of multiple hardware components, typically 418 resulting in a hierarchical composition of hardware components. 419 The composition of hardware components is based on interconnects 420 provided by specific hardware types (e.g. mainboard is a hardware 421 type that provides local busses as an interconnect). In general, 422 a hardware component can be distinguished by its serial number. 423 Occasionally, hardware components are refered to as power sucking 424 aliens. 426 Hardware Inventory: The list of hardware components that compose a 427 specific endpoint representing its hardware configuration. 429 Hardware Type: Hardware types define specific and distinguishable 430 categories of hardware components that can be part of endpoints, 431 e.g. CPU or 802.11p interface. Typically, hardware types can be 432 distinguished by their vendor assigned names, names of standards 433 used, or a model name. 435 Information Element: 437 A representation of information about physical and virtual "objects 438 of interests". Information elements are the building blocks that 439 constitute the SACM information model. In the context of SACM, an 440 information element that expresses a single value with a specific 441 name is referred to as an Attribute (analogous to an attribute-value- 442 pair). A set of attributes that is bundled into a more complex 443 composite information element is referred to as a Subject. Every 444 information element in the SACM information model has a unique name. 445 Endpoint attributes or time stamps, for example, are represented as 446 information elements in the SACM information model. 448 Information Model: An information model is an abstract 449 representation of data, their properties, relationships between 450 data and the operations that can be performed on the data. While 451 there is some overlap with a data model, [RFC3444] distinguishes 452 an information model as being protocol and implementation neutral 453 whereas a data model would provide such details. The purpose of 454 the SACM information model is to ensure interoperability between 455 SACM data models (that are used as transport encoding) and to 456 provide a standardized set of information elements for 457 communication between SACM components. 459 Interaction Model: For now this is a Place-Holder. Is an 460 interaction model that defines, for example, the operations on the 461 control plane, such as registration or SACM component discovery, 462 required? 464 Internal Collector: Internal Collector: a collector that runs on a 465 target endpoint to acquire information from that target endpoint. 466 (TBD: An internal collector is not a SACM component and therefore 467 not part of a SACM domain). 469 Management Plane: An architectural component providing common 470 functions to steer the behavior of SACM components, e.g. its 471 behavior on the control plane. Prominent examples include: 472 modification of the configuration of a SACM component or updating 473 a target endpoint profile that resides on an evaluator. In 474 essence, guidance is transported via the management plane. 475 Typically, a SACM component can fulfill its purpose without 476 continuous input from the management plane. In contrast, without 477 continuous availability of control plane functions a typical SACM 478 component could not function properly. In general, interaction on 479 the management plane is less frequent and less regular than on the 480 control plane. Input via the management plane can be manual (e.g. 481 via a CLI), or can be automated via management plane functions 482 that are part of other SACM components. 484 Metadata: Data about data. In the SACM information model, data is 485 referred to as Content. Metadata about the content is referred to 486 as Content-Metadata, respectively. Content and Content-Metadata 487 are combined into Subjects called Content-Elements in the SACM 488 information model. Some information elements defined by the SACM 489 information model can be part of the Content or the Content- 490 Metadata. Therefore, if an information element is considered data 491 or data about data depends on which kind of Subject it is 492 associated with. The SACM information model also defines metadata 493 about the data origin via the Subject Statement-Metadata. Typical 494 examples of metadata are time stamps, data origin or data source. 496 Network Address: Network addresses are layer specific and follow 497 layer specific address schemes. Each interface of a specific 498 layer can be associated with one or more addresses appropriate for 499 that layer. There is no guarantee that an address is globally 500 unique. In general, there is a scope to an address in which it is 501 intended to be unique. 503 Examples include: physical Ethernet port with a MAC address, layer 504 2 VLAN interface with a MAC address, layer 3 interface with 505 multiple IPv6 addresses, layer 3 tunnel ingress or egress with an 506 IPv4 address. 508 Network Interface: An endpoint is connected to a network via one or 509 more network interfaces. Network interfaces can be physical or 510 virtual. Network interfaces of an endpoint can operate on 511 different layers, most prominently what is now commonly called 512 layer 2 and 3. Within a layer, interfaces can be nested. 514 On layer 2, a root interface is typically associated with a 515 physical interface port and nested interfaces are virtual 516 interfaces. In the case of a virtual endpoint, a root interface 517 can be a virtual interface. Virtual layer 2 interfaces of one or 518 more endpoints can also constitute an aggregated group of links 519 that act as one. 521 On layer 3, nested interfaces typically constitute virtual tunnels 522 or virtual (mesh) networks. 524 Examples include: physical Ethernet port, layer 2 VLAN interface, 525 a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress. 527 Posture: Defined in [RFC5209] as "configuration and/or status of 528 hardware or software on an endpoint as it pertains to an 529 organization's security policy." 531 This term is used within the scope of SACM to represent the 532 configuration and state information that is collected from a 533 target endpoint in the form of endpoint attributes (e.g. software/ 534 hardware inventory, configuration settings, dynamically assigned 535 addresses). This information may constitute one or more posture 536 attributes. 538 Posture Attributes: Defined in [RFC5209] as "attributes describing 539 the configuration or status (posture) of a feature of the 540 endpoint. A Posture Attribute represents a single property of an 541 observed state. For example, a Posture Attribute might describe 542 the version of the operating system installed on the system." 544 Within this document this term represents a specific assertion 545 about endpoint configuration or state (e.g. configuration setting, 546 installed software, hardware) represented via endpoint attributes. 547 The phrase "features of the endpoint" highlighted above refers to 548 installed software or software components. 550 Provider: A provider is a SACM role that is assigned to a SACM 551 component that contains functions to provide information to other 552 SACM components. 554 Proxy: A proxy is a specific controller type that provides data 555 plane and control plane functions, information, or services on 556 behalf of another component, which is not directly participating 557 in the SACM architecture. 559 Repository: A repository is a specific controller type that contains 560 functions to consume, store and provide information of a 561 particular kind - typically data transported on the data plane, 562 but potentially also data and metadata from the control and 563 management plane. A single repository may provide the functions 564 of more than one specific repository type (i.e. configuration 565 baseline repository, assessment results repository, etc.) 567 SACM Component: A component is defined in 568 [I-D.ietf-i2nsf-terminology] as "an encapsulation of software that 569 communicates using Interfaces. A Component may be implemented by 570 hardware and/or Software, and be represented using a set of 571 classes. In general, a Component encapsulates a set of data 572 structures as well as a set of algorithms that implement the 573 functions that it provides." 574 In the context of SACM, a set of SACM functions composes a SACM 575 component. A SACM component conducts SACM tasks, acting on 576 control plane, data plane and/or management plane via 577 corresponding SACM interfaces. SACM defines a set of standard 578 components (e.g. a collector, a broker, or a data store). A SACM 579 component contains at least a basic set of control plane functions 580 and can contain data plane and management plane functions. A SACM 581 component residing on an endpoint assigns one or more SACM roles 582 to the corresponding endpoint due to the SACM functions it is 583 composed of. A SACM component "resides on" an endpoint and an 584 endpoint "contains" a SACM component, correspondingly. For 585 example, a SACM component that is composed solely of functions 586 that provide information would only take on the role of a 587 provider. 589 SACM Component Discovery: The task of brokering appropriate SACM 590 components according to their capabilities or roles on reques. 592 Input: Query 594 Output: a list of SACM components including metadata 596 SACM Component Label: A specific endpoint label that is used to 597 identify a SACM component. In content-metadata, this label is 598 called data origin. 600 SACM Domain: Endpoints that include a SACM component compose a SACM 601 domain. (To be revised, additional definition content TBD, 602 possible dependencies to SACM architecture) 604 SACM Interface: An interface is defined in 605 [I-D.ietf-i2nsf-terminology] as "A set of operations one object 606 knows it can invoke on, and expose to, another object. This 607 decouples the implementation of the operation from its 608 specification. An interface is a subset of all operations that a 609 given object implements. The same object may have multiple types 610 of interfaces to serve different purposes." 612 In the context of SACM, SACM Funktions provide SACM Interfaces on 613 the management, control, or data plane. Operations a SACM 614 Interface provides are based on corresponding data model defined 615 by SACM. SACM Interfaces are used for communication between SACM 616 components. 618 SACM Role: A role is defined in [I-D.ietf-i2nsf-terminology] as "an 619 abstraction of a Component that models context-specific views and 620 responsibilities of an object as separate role objects that can be 621 statically or dynamically attached to (and removed from) the 622 object that the role object describes. This provides three 623 important benefits. First, it enables different behavior to be 624 supported by the same Component for different contexts. Second, 625 it enables the behavior of a Component to be adjusted dynamically 626 (i.e., at runtime, in response)to changes in context, by using one 627 or more Roles to define the behavior desired for each context. 628 Third, it decouples the Roles of a Component from the Applications 629 that use that Component." 631 In the context of SACM, SACM roles are associated with SACM 632 components and are defined by the set of functions and interfaces 633 a SACM component includes. There are three SACM roles: provider, 634 consumer, and controller. The roles associated with a SACM 635 component are determined by the purpose of the SACM functions and 636 corresponding SACM interfaces the SACM component is composed of. 638 Security Automation: The process of which security alerts can be 639 automated through the use of different tools to monitor, evaluate 640 and analyze endpoint and network traffic for the purposes of 641 detecting misconfigurations, misbehaviors or threats. 643 Software Package: A generic software package (e.g. a text editor). 645 Software Component: A software package installed on an endpoint, 646 including a unique serial number if present (e.g. a text editor 647 associated with a unique license key). 649 Software Instance: A running instance of the software component 650 (e.g. on a multi-user system, one logged-in user has one instance 651 of a text editor running and another logged-in user has another 652 instance of the same text editor running, or on a single-user 653 system, a user could have multiple independent instances of the 654 same text editor running). 656 Statement: An output of a provider, e.g. a report or an assertion 657 about a collection result, that includes content-elements and 658 statement-metadata (e.g. data origin or the point in time at which 659 the statement was created). A statement can be accompanied by 660 evidence of the validity of its metadata. 662 The structure of statements is defined in the SACM information 663 model. 665 Subject: TODO, incorporate definition from SACM IM 667 Supplicant: The entity seeking to be authenticated by the Management 668 Plane for the purpose of participating in the SACM architecture. 670 System Resource: Defined in [RFC4949] as "data contained in an 671 information system; or a service provided by a system; or a system 672 capacity, such as processing power or communication bandwidth; or 673 an item of system equipment (i.e., hardware, firmware, software, 674 or documentation); or a facility that houses system operations and 675 equipment. 677 Target Endpoint: A target endpoint is an "endpoint under assessment" 678 (even if it is not actively under assessment at all times) or 679 "endpoint of interest". Every endpoint that is not specifically 680 designated as an excluded endpoint is a target endpoint. A target 681 endpoint is not part of a SACM domain unless it contains a SACM 682 component (e.g. a SACM component that publishes collection results 683 coming from an internal collector). 685 A target endpoint is similar to a device that is a Target of 686 Evaluation (TOE) as defined in Common Criteria. 688 Target Endpoint Characterization Record: A set of endpoint 689 attributes about a target endpoint that was encountered in a SACM 690 domain, which are associated with a target endpoint by being 691 included in the corresponding record. A characterization record 692 is intended to be a representation of an endpoint. It cannot be 693 assured that a record distinctly represents a single target 694 endpoint unless a set of one or more endpoint attributes that 695 compose a unique set of identifying endpoint attributes are 696 included in the record. Otherwise, the set of identifying 697 attributes included in a record can match more than one target 698 endpoints, which are - in consequence - indistinguishable to a 699 SACM domain until more qualifying endpoint attributes can be 700 acquired and added to the record. A characterization record is 701 maintained over time in order to assert that acquired endpoint 702 attributes are either about an endpoint that was encountered 703 before or an endpoint that has not been encountered before in a 704 SACM domain. A characterization record can include, for example, 705 acquired configuration, state or observed behavior of a specific 706 target endpoint. Multiple and even conflicting instances of this 707 information can be included in a characterization record by using 708 timestamps and/or data origins to differentiate them. The 709 endpoint attributes included in a characterization record can be 710 used to re-identify a distinct target endpoint over time. Classes 711 or profiles can be associated with a characterization record via 712 the Classification Task in order to guide collection, evaluation 713 or remediation tasks. 715 Target Endpoint Characterization Task: An ongoing task of 716 continuously adding acquired endpoint attributes to a 717 corresponding record. The TE characterization task manages the 718 representation of encountered target endpoints in the SACM domain 719 in the form of characterization records. For example, the output 720 of a target endpoint discovery task or a collection task can be 721 processed by the characterization task and added to the record. 722 The TE characterization Task also manages these representations of 723 target endpoints encountered in the SACM domain by splitting or 724 merging the corresponding records as new or more refined endpoint 725 attributes become available. 727 Input: discovered target endpoint attributes, endpoint attribute 728 collection, existing characterization records 730 Output: target endpoint characterization records 732 Target Endpoint Classification Task: The task of associating a class 733 from an extensible list of classes with an endpoint 734 characterization record. TE classes function as guidance for 735 collection, evaluation, remediation and security posture 736 assessment in general. 738 Input: endpoint characterization records (without classification), 739 guidance (how to classify a record) 741 Output: endpoint characterization records (with classification) 743 Target Endpoint Discovery Task: The ongoing task of detecting 744 previously unknown interaction of a potential target endpoint in 745 the SACM domain. TE Discovery is not directly targeted at a 746 specific target endpoint and therefore an un-targeted task. SACM 747 Components conducting the discovery task as a part of their 748 function are typically distributed and located, for example, on 749 infrastructure components or collect from those remotely via 750 appropriate interfaces. Examples of infrastructure components 751 that are of interest to the discovery task include routers, 752 switches, VM hosting or VM managing components, AAA servers, or 753 servers handling dynamic address distribution. 755 Input: endpoint attributes acquired via local or remote interfaces 757 Output: endpoint attributes including metadata such as data source 758 or data origin 760 Target Endpoint Identifier: The target endpoint discovery task and 761 the collection tasks can result in a set of identifying endpoint 762 attributes added to a corresponding Characterization Record. This 763 subset of the endpoint attributes included in the record is used 764 as a target endpoint identifier, by which a specific target 765 endpoint can be referenced. Depending on the available 766 identifying attributes, this reference can be ambiguous and is a 767 "best-effort" mechanism. Every distinct set of identifying 768 endpoint attributes can be associated with a target endpoint label 769 that is unique in a SACM domain. 771 Target Endpoint Label: A specific endpoint label that refers to a 772 target endpoint identifier used to identify a specific target 773 endpoint (also referred to as TE label). In content-metadata, 774 this label is called data source. 776 Target Endpoint Profile: A bundle of expected or desired 777 configurations and states (typically a composition of endpoint 778 attribute value pairs) that can be associated with a target 779 endpoint. The corresponding task by which the association with a 780 target endpoint takes places is the endpoint classification. The 781 task by which an endpoint profile is created is the endpoint 782 characterization. A type or class of target endpoints is defined 783 within a target endpoint profile, e.g. printer, smartphone, or an 784 office PC. 786 SACM Task: A SACM task is conducted by one or more SACM functions 787 that reside on a SACM component (e.g. a collection task or 788 endpoint characterization). A SACM task can be triggered by other 789 operations or functions (e.g. a query from another SACM component 790 or an unsolicited push on the data plane due to an ongoing 791 subscription). A task is part of a SACM process chain. A task 792 starts at a given point in time and ends in a deterministic state. 793 With the exception of a collection task, a SACM task consumes SACM 794 statements provided by other SACM components. The output of a 795 task is a result that can be provided (e.g. published) on the data 796 plane. There following tasks are defined by SACM: 798 Target Endpoint Discovery 800 Target Endpoint Characterization 802 Target Endpoint Classification 804 Collection 806 Evaluation [TBD] 808 Information Sharing [TBD] 810 SACM Component Discovery 812 SACM Component Authentication [TBD] 813 SACM Component Authorization [TBD] 815 SACM Component Registration [TBD] 817 Timestamps : Defined in [RFC4949] as "with respect to a data object, 818 a label or marking in which is recorded the time (time of day or 819 other instant of elapsed time) at which the label or marking was 820 affixed to the data object" and as "with respect to a recorded 821 network event, a data field in which is recorded the time (time of 822 day or other instant of elapsed time) at which the event took 823 place.". 825 This term is used in SACM to describe a recorded point in time at 826 which, for example, an endpoint attribute is created or updated by 827 a target endpoint and observed, transmitted or processed by a SACM 828 component. Timestamps can be created by target endpoints or SACM 829 components and are associated with endpoint attributes provided or 830 consumed by SACM components. Outside of the domain of SACM 831 components the assurance of correctness of time stamps is 832 typically significantly lower than inside a SACM domain. In 833 general, it cannot be simply assumed that the source of time a 834 target endpoint uses is synchronized or trustworthy. 836 Vulnerability Assessment: The process of determining whether a set 837 of endpoints is vulnerable according to the information contained 838 in the vulnerability description information. 840 Vulnerability Description Information: Information pertaining to the 841 existence of a flaw or flaws in software, hardware, and/or 842 firmware, which could potentially have an adverse impact on 843 enterprise IT functionality and/or security. Vulnerability 844 description information should contain enough information to 845 support vulnerability detection. 847 Vulnerability Detection Data: A type of guidance extracted or 848 derived from vulnerability description information that describes 849 the specific mechanisms of vulnerability detection that is used by 850 an enterprise's vulnerability management capabilities to determine 851 if a vulnerability is present on an endpoint. 853 Vulnerability Management Capabilities: An enterprise IT department's 854 ability to manage endpoint vulnerabilities and associated metadata 855 on an ongoing basis by ingesting vulnerability description 856 information and vulnerability detection data, and performing 857 vulnerability assessments. 859 Vulnerability assessment capabilities: An enterprise IT department's 860 ability to determine whether a set of endpoints is vulnerable 861 according to the information contained in the vulnerability 862 description information. 864 Workflow: 866 A workflow is a modular composiion of tasks. A workflow can contain 867 loops, conditionals, multiple starting points and multiple endpoints. 868 The most promiminant workflow in SACM is the assessment workflow. 870 3. IANA Considerations 872 This memo includes no request to IANA. 874 4. Security Considerations 876 This memo documents terminology for security automation. While it is 877 about security, it does not affect security. 879 5. Acknowledgements 881 6. Change Log 883 Changes from version 00 to version 01: 885 o Added simple list of terms extracted from UC draft -05. It is 886 expected that comments will be received on this list of terms as 887 to whether they should be kept in this document. Those that are 888 kept will be appropriately defined or cited. 890 Changes from version 01 to version 02: 892 o Added Vulnerability, Vulnerability Management, xposure, 893 Misconfiguration, and Software flaw. 895 Changes from version 02 to version 03: 897 o Removed Section 2.1. Cleaned up some editing nits; broke terms 898 into 2 sections (predefined and newly defined terms). Added some 899 of the relevant terms per the proposed list discussed in the IETF 900 89 meeting. 902 Changes from version 03 to version 04: 904 o TODO 906 Changes from version 04 to version 05: 908 o TODO 909 Changes from version 05 to version 06: 911 o Updated author information. 913 o Combined "Pre-defined Terms" with "New Terms and Definitions". 915 o Removed "Requirements language". 917 o Removed unused reference to use case draft; resulted in removal of 918 normative references. 920 o Removed introductory text from Section 1 indicating that this 921 document is intended to be temporary. 923 o Added placeholders for missing change log entries. 925 Changes from version 06 to version 07: 927 o Added Contributors section. 929 o Updated author list. 931 o Changed title from "Terminology for Security Assessment" to 932 "Secure Automation and Continuous Monitoring (SACM) Terminology". 934 o Changed abbrev from "SACM-Terms" to "SACM Terminology". 936 o Added appendix The Attic to stash terms for future updates. 938 o Added Authentication, Authorization, Data Confidentiality, Data 939 Integrity, Data Origin, Data Provenance, SACM Component, SACM 940 Component Discovery, Target Endpoint Discovery. 942 o Major updates to Building Block, Function, SACM Role, Target 943 Endpoint. 945 o Minor updates to Broker, Capability, Collection Task, Evaluation 946 Task, Posture. 948 o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, 949 Endpoint Discovery to Endpoint Identification. 951 o Moved Asset Targeting, Client, Endpoint Identification to The 952 Attic. 954 o Endpoint Attributes added as a TODO. 956 o Changed the structure of the Change Log. 958 Changes from version 07 to version 08: 960 o Added Assertion, Collection Result, Collector, Excluded Endpoint, 961 Internal Collector, Network Address, Network Interface, SACM 962 Domain, Statement, Target Endpoint Identifier, Target Endpoint 963 Label, Timestamp. 965 o Major updates to Attributes, Broker, Collection Task, Consumer, 966 Controller, Control Plane, Endpoint Attributes, Expected Endpoint 967 State, SACM Function, Provider, Proxy, Repository, SACM Role, 968 Target Endpoint. 970 o Minor updates to Asset, Building Block, Data Origin, Data Source, 971 Data Provenance, Endpoint, Management Plane, Posture, Posture 972 Attribute, SACM Component, SACM Component Discovery, Target 973 Endpoint Discovery. 975 o Relabeled Function to SACM Function. 977 Changes from version 08 to version 09: 979 o Updated author list. 981 o Added Data Plane, Endpoint Characterization, Endpoint 982 Classification, Guidance, Interaction Model, Software Component, 983 Software Instance, Software Package, Statement, Target Endpoint 984 Profile, SACM Task. 986 o Removed Building Block. 988 o Major updates to Control Plane, Endpoint Attribute, Expected 989 Endpoint State, Information Model, Management Plane. 991 o Minor updates to Attribute, Capabilities, SACM Function, SACM 992 Component, Collection Task. 994 o Moved Asset Characterization to The Attic. 996 Changes from version 09 to version 10: 998 o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint 999 Management Capability, Hardware Component, Hardware Inventory, 1000 Hardware Type, SACM Interface, Target Endpoint Characterization 1001 Record, Target Endpoint Characterization Task, Target Endpoint 1002 Classification Task, Target Endpoint Discovery Task, Vulnerability 1003 Description Information, Vulnerability Detection Data, 1004 Vulnerability Management Capability, Vulnerability Assessment 1006 o Added references to i2nsf definitions in Capability, SACM 1007 Component, SACM Interface, SACM Role 1009 o Added i2nsf Terminology I-D Reference 1011 o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier 1013 o Minor Updates to Guidance, SACM Component Discovery, Target 1014 Endpoint Label, Target Endpoint Profile 1016 o Relabeled SACM Task 1018 o Removed Target Endpoint Discovery 1020 Changes from version 10 to version 11: 1022 o Added Content Element, Content Metadata, Endpoint Label, 1023 Information Element, Metadata, SACM Component Label, Workflow 1025 o Major Updates to Assessment, Capability, Collector, Endpoint 1026 Management Capabilities, Guidance, Vulnerability Assessment 1027 Capabilities, Vulnerability Detection Data, Vulnerability 1028 Assessment Capabilities 1030 o Minor updates to Collection Result, Control Plane, Data in Motion, 1031 Data at Rest, Data Origin, Network Interface, Statement, Target 1032 Endpoint Label, 1034 o Relabeled Endpoint Management Capability, Vulnerability Management 1035 Capability, Vulnerability Assessment 1037 7. Contributors 1038 David Waltermire 1039 National Institute of Standards and Technology 1040 100 Bureau Drive 1041 Gaithersburg, MD 20877 1042 USA 1044 Email: david.waltermire@nist.gov 1046 Adam W. Montville 1047 Center for Internet Security 1048 31 Tech Valley Drive 1049 East Greenbush, NY 12061 1050 USA 1052 Email: adam.w.montville@gmail.com 1054 David Harrington 1055 Effective Software 1056 50 Harding Rd 1057 Portsmouth, NH 03801 1058 USA 1060 Email: ietfdbh@comcast.net 1062 Brian Ford 1063 Lancope 1064 3650 Brookside Parkway, Suite 500 1065 Alpharetta, GA 30022 1066 USA 1068 Email: bford@lancope.com 1070 Merike Kaeo 1071 Double Shot Security 1072 3518 Fremont Avenue North, Suite 363 1073 Seattle, WA 98103 1074 USA 1076 Email: merike@doubleshotsecurity.com 1078 8. Informative References 1080 [I-D.ietf-i2nsf-terminology] 1081 Hares, S., Strassner, J., Lopez, D., and L. Xia, 1082 "Interface to Network Security Functions (I2NSF) 1083 Terminology", draft-ietf-i2nsf-terminology-01 (work in 1084 progress), July 2016. 1086 [I-D.ietf-sacm-vuln-scenario] 1087 Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., 1088 Fitzgerald-McKay, J., and D. Waltermire, "SACM 1089 Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- 1090 scenario-02 (work in progress), September 2016. 1092 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1093 Information Models and Data Models", RFC 3444, 1094 DOI 10.17487/RFC3444, January 2003, 1095 . 1097 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1098 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1099 . 1101 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1102 Tardo, "Network Endpoint Assessment (NEA): Overview and 1103 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1104 . 1106 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 1107 (PA) Protocol Compatible with Trusted Network Connect 1108 (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, 1109 . 1111 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1112 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1113 March 2011, . 1115 [X.1252] "ITU-T X.1252 (04/2010)", n.d.. 1117 Appendix A. The Attic 1119 The following terms are stashed for now and will be updated later: 1121 Asset Characterization: Asset characterization is the process of 1122 defining attributes that describe properties of an identified 1123 asset. 1125 Asset Targeting: Asset targeting is the use of asset identification 1126 and categorization information to drive human-directed, automated 1127 decision making for data collection and analysis in support of 1128 endpoint posture assessment. 1130 Client: An architectural component receiving services from another 1131 architectural component. 1133 Endpoint Identification (TBD per list; was "Endpoint Discovery"): 1134 The process by which an endpoint can be identified. 1136 Authors' Addresses 1138 Henk Birkholz 1139 Fraunhofer SIT 1140 Rheinstrasse 75 1141 Darmstadt 64295 1142 Germany 1144 Email: henk.birkholz@sit.fraunhofer.de 1146 Jarrett Lu 1147 Oracle Corporation 1148 4180 Network Circle 1149 Santa Clara, CA 95054 1150 USA 1152 Email: jarrett.lu@oracle.com 1154 John Strassner 1155 Huawei Technologies 1156 2330 Central Expressway 1157 Santa Clara, CA 95138 1158 USA 1160 Email: john.sc.strassner@huawei.com 1162 Nancy Cam-Winget 1163 Cisco Systems 1164 3550 Cisco Way 1165 San Jose, CA 95134 1166 USA 1168 Email: ncamwing@cisco.com