--- 1/draft-ietf-sacm-terminology-11.txt 2017-03-13 16:14:18.661293172 -0700 +++ 2/draft-ietf-sacm-terminology-12.txt 2017-03-13 16:14:18.717294508 -0700 @@ -1,23 +1,23 @@ SACM Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational J. Lu -Expires: March 16, 2017 Oracle Corporation +Expires: September 14, 2017 Oracle Corporation J. Strassner Huawei Technologies N. Cam-Winget Cisco Systems - September 12, 2016 + March 13, 2017 - Secure Automation and Continuous Monitoring (SACM) Terminology - draft-ietf-sacm-terminology-11 + Security Automation and Continuous Monitoring (SACM) Terminology + draft-ietf-sacm-terminology-12 Abstract This memo documents terminology used in the documents produced by SACM (Security Automation and Continuous Monitoring). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -25,99 +25,102 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 16, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 - 8. Informative References . . . . . . . . . . . . . . . . . . . 23 - Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Informative References . . . . . . . . . . . . . . . . . . . 25 + Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Our goal with this document is to improve our agreement on the terminology used in documents produced by the IETF Working Group for Security Automation and Continuous Monitoring. Agreeing on terminology should help reach consensus on which problems we're trying to solve, and propose solutions and decide which ones to use. 2. Terms and Definitions This section describes terms that have been defined by other RFC's and defines new ones. The predefined terms will reference the RFC and where appropriate will be annotated with the specific context by which the term is used in SACM. Assertion: Defined by the ITU in [X.1252] as "a statement made by an entity without accompanying evidence of its validity". In the - context of SACM, an assertion is a collection result that includes - metadata about the data source (and optionally a timestamp - indicating the point in time the assertion was created at). The - validity of an assertion cannot be verified. + context of SACM, an assertion is the output of a SACM component in + the form of a statement (including metadata about the data source + and data origin, e.g. time stamps). While the validity of an + assertion cannot be verified without, for example, an additional + attestation protocol, an assertion (and therfore a statement, + respectivly) can be accompanied by evidence of the validity of its + metadata provided by a SACM component. Assessment: Defined in [RFC5209] as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host- based firewall) such that the appropriate validators may evaluate the posture against compliance policy." - Assessment is a specifc workflow that incorporates the SACM tasks - discovery, collection and evaluation. A prominent instance of the - assessment workflow is illustrated in the Vulnerability - Assessement Scenario [I-D.ietf-sacm-vuln-scenario] + An assessment is a specifc workflow that incorporates the SACM + tasks discovery, collection and evaluation. A prominent instance + of the assessment workflow is illustrated in the Vulnerability + Assessement Scenario [I-D.ietf-sacm-vuln-scenario]. Asset: Defined in [RFC4949] as "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission". In the scope of SACM, an asset can be composed of other assets. Examples of Assets include: Endpoints, Software, Guidance, or X.509 public key certificates. An asset is not necessarily owned by an organization. Asset Management: The process by which assets are provisioned, updated, maintained and deprecated. - Attribute: TODO, Update definition. Defined in [RFC5209] as "data - element including any requisite meta-data describing an observed, - expected, or the operational status of an endpoint feature (e.g., - anti-virus software is currently in use)." If not indicated - otherwise, attributes in SACM are represented and processed as - attribute value pairs. + Attribute: Defined in [RFC5209] as "data element including any + requisite meta-data describing an observed, expected, or the + operational status of an endpoint feature (e.g., anti-virus + software is currently in use)." In the context of SACM, + attributes are "atomic" information elements and an equivalent to + attribute-value-pairs. Attributes can be components of Subjects. Authentication: Defined in [RFC4949] as "the process of verifying a claim that a system entity or system resource has a certain attribute value." Authorization: Defined in [RFC4949] as "an approval that is granted to a system entity to access a system resource." Broker: A broker is a specific controller type that contains control plane functions to provide and/or connect services on behalf of @@ -191,110 +194,151 @@ discovered by other SACM components. A collector can be distributed across multiple endpoints, e.g. across a target endpoint and a SACM component. The separate parts of the collector can communicate with a specialized protocol, such as PA-TNC [RFC5792]. At least one part of a distributed collector has to take on the role of a provider of information by providing SACM interfaces to propagate capabilities and to provide SACM content in the form of collection results. - Configuration Drift: The discrepancy of endpoint attributes - representing the actual composition of a target endpoint (is- - state) and its intended composition (should-state) in the scope of - a valid target endpoint composition (could-state) due to - continuous alteration of a target endpoint's composition over + Configuration: A non-volatile subset of the endpoint attributes of a + (target) endpoint that is intended to be uneffected by a normal + reboot-cylce. Configuration is a type of imperative guidance that + is stored in files (files dedicated to contain configuration and/ + or files that are software components), directly on block devices, + or on specific hardware components that can be accessed via + corresponding software components. Modification of configuration + can be conducted manually or automatically via management (plane) + interfaces that support management protocols, such as SNMP or WMI. + A change of configuration can occur during both run-time and down- + time of an endpoint. It is common practive to scheduled a change + of configuration during or directly after the completion of a + boot-cycle via corresponding software components located on the + target endpoint itself. + + Exmaples: The static association of an IP address and a MAC + address in a DHCP server configuration, a directory-path that + identifies a log-file directory, a registry entry. + + Configuration Drift: The discrepancy of a target endpoint's endpoint + attributes representing the actual composition of a target + endpoint (is-state) and its intended composition (should-state) in + the scope of a valid target endpoint composition (could-state) due + to continuous alteration of a target endpoint's composition over time. Configuration drift exists for both hardware components and software components. Typically, the frequency and scale of configuration drift of software components is significantly higher than the configuration drift of hardware components. Consumer: A consumer is a SACM role that is assigned to a SACM component that contains functions to receive information from other SACM components. - Content Element: Content elements constitute the payload data - (content) transfered via statement Subjects emitted by providers - of information. Every content element Subject includes a specific + Content Element: Content elements constitute the payload data (SACM + content) transfered via statement Subjects emitted by providers of + information. Every content element Subject includes a specific content Subject and a corresponding content metadata Subject. Content Metadata: Data about content Subjects. Every content- element includes a content metadata Subject. The Subject can include any information element that can annotate the content transefered. Examples include time stamps or data provenance Subjects. Control Plane: Typically used as a term in the context of routing, e.g. [RFC6192]. In the context of SACM, the control plane is an architectural component providing common control functions to all SACM components, including authentication, authorization, - capability discovery or negotiation, and registration. The - control plane orchestrates the flow on the data plane according to - guidance received via the management plane. SACM components with + (capability) discovery or negotiation, registration and + subscription. The control plane orchestrates the flow on the data + plane according to imperative guidance (i.e. configuration) + received via the management plane. SACM components with interfaces to the control plane have knowledge of the capabilities of other SACM components within a SACM domain. Controller: A controller is a SACM role that is assigned to a SACM component containing control plane functions that manage and facilitate information sharing or execute on security functions. There are three types of SACM controllers: Broker, Proxy, and Repository. Depending on its type, a controller can also contain functions that have interfaces on the data plane. Data Confidentiality: Defined in [RFC4949] as "the property that data is not disclosed to system entities unless they have been authorized to know the data." Data In Motion: Data that is being transported via a network; also - referred to as Data in transit. Data in motion requires a data - model to encode the data to be transferred. Typically, data in - motion is serialized (marshalling) into a transport encoding by a - provider of information and deserialized (unmarshalling) by a - consumer of information. + referred to as "Data in Transit" or "Data in Flight". Data in + motion requires a data model to transfer the data using a specific + encoding. Typically, data in motion is serialized (marshalling) + into a transport encoding by a provider of information and + deserialized (unmarshalling) by a consumer of information. The + termination points of provider of information and consumer of + information data is transferred between are interfaces. In regard + to data in motion, the interpretation of the roles consumer of + information and provider of information depends on the + corresponding OSI layer (e.g. on layer2: between interfaces + connected to a broadcast domain, on layer4: between interfaces + that maintain a TCP connection). In the context of SACM, consumer + of information and provider of information are SACM components. - SACM architecture and corresponding models focus on data in + The SACM architecture and corresponding models focus on data in motion. Data At Rest: Data that is stored in a repository. Data at rest requires a data model to encode the data to be stored. In the context of SACM, data at rest located on a SACM component can be provided to other SACM components via discoverable capabilities. In the context of SACM, data models for data at rest are out of scope. Data Integrity: Defined in [RFC4949] as "the property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." - Data Origin: One or more properties that enable a SACM component to - identify the SACM component that initially acquired or produced - data about a (target) endpoint (e.g. via collection from a data - source). Data Origin is expressed by an endpoint label. + Data Origin: One or more properties (i.e. endpoint attributes) that + enable a SACM component to identify the SACM component that + initially acquired or produced data about a (target) endpoint + (e.g. via collection from a data source) and made it available to + a SACM domaini via a SACM statement. Data Origin can be expressed + by an endpoint label information element (e.g. to be used as + metadata in statement). - Data Plane: Typically used as a term in the context of routing (and - used as a synonym for forwarding plane, e.g. [RFC6192]). In the - context of SACM, the data plane is an architectural component - providing operational functions to enable a SACM component to - provide and consume SACM statements and therefore SACM content - (the "payload"). The data plane is used to conduct distributed - SACM tasks by transporting SACM content using transporting - encodings and corresponding operations defined by SACM data - models. + Data Plane (fix statement): Typically used as a term in the context + of routing (and used as a synonym for forwarding plane, e.g. + [RFC6192]). In the context of SACM, the data plane is an + architectural component providing operational functions to enable + a SACM component to provide and consume SACM statements and + therefore SACM content (the "payload"). The data plane is used to + conduct distributed SACM tasks by transporting SACM content using + transporting encodings and corresponding operations defined by + SACM data models. Data Provenance: A historical record of the sources, origins and evolution of data that is influenced by inputs, entities, - functions and processes. + functions and processes. In the context of SACM, data provenance + is expressed as metadata that identifies SACM statements and + corresponding content elements a new statement is created from. + In a downstream process, this references can cascade, creating a + data provenance tree that enables SACM components to trace back + the original data sources involved in the creation of SACM + statements and take into account their characteristics and + trustworthiness. - Data Source: One or more properties that enable a SACM component to - identify an (target) endpoint that is claimed to be the original - source of received data. + Data Source: One or more properties (i.e. endpoint attributes) that + enable a SACM component to identify - and potentially characterize + - a (target) endpoint that is claimed to be the original source of + endpoint attributes in a SACM statement. Data Source can be + expressed as metadata by an endpoint label information element or + a corresponding subject of identifying endpoint attributes. Endpoint: Defined in [RFC5209] as "any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address." To further clarify the [RFC5209] definition, an endpoint is any physical or virtual device that may have a network address. Note @@ -310,37 +354,41 @@ The SACM architecture differentiates two essential categories of endpoints: Endpoints whose security posture is intended to be assessed (target endpoints) and endpoints that are specifically excluded from endpoint posture assessment (excluded endpoints). Based on the definition of an asset, an endpoint is a type of asset. Endpoint Attribute: In the context of SACM, endpoint attributes are - information elements that describe a characteristic of a target - endpoint. Endpoint Attributes typically constitute Attributes - that can be bundled into Subject (e.g. information about a - specific network interface can be represented via a set of + information elements that describe an endpoint characteristic of a + target endpoint. Endpoint Attributes typically constitute + Attributes that can be bundled into Subject (e.g. information + about a specific network interface can be represented via a set of multiple AVP). + Endpoint Characteristic: The state, configuration and composition an + endpoint is in, including observerable behavior, e.g. sys-calls, + log-files, or PDU emission on a network. + Endpoint Characterization: The task by which a profile is composed out of endpoint attributes that describe the desired or expected posture of a type or class of target endpoints or even an individual target endpoint. The result of this task is an - endpoint profile that is required as guidance for the tasks of - endpoint classification or posture assessment. + endpoint profile that is required as declarative guidance for the + tasks of endpoint classification or posture assessment. Endpoint Classification: The task by which a discovered target - endpoint is classified. Endpoint classification requires guidance - in the form of an endpoint profile, discovery results and - potentially collection results. Types, classes or the + endpoint is classified. Endpoint classification requires + declarative guidance in the form of an endpoint profile, discovery + results and potentially collection results. Types, classes or the characteristics of an individual target endpoint are defined via endpoint profiles. Endpoint Label: In a SACM domain, every endpoint can be identified by an endpoint label. There are two prominent uses of endpoint labels in a SACM domain: to identify SACM components and to identify Target Endpoints. Both endpoint labels can be used in SACM content or in content metadata: SACM Components are identified by: SACM component label / Data @@ -357,53 +405,62 @@ Endpoint Management Capabilities: An enterprise IT department's ability to manage endpoint identity, endpoint information, and associated metadata on an ongoing basis. Evaluation Task: The task by which endpoint attributes are evaluated. Evaluation Result: The resulting value from having evaluated a set of posture attributes. + Event: The change of a target endpoint characteristics at a specific + point in time. In the context of SACM, an event is a statement + (and therefore data in motion) that includes the new target + endpoint characteristics and optional also the past ones, + annotated with corresponding metedata (most prominently, the + collection time of the data that constitutes the observation of + the event regarding te target endpoint). + Excluded Endpoint: A specific designation, which is assigned to an endpoint that is not supposed to be the subject of a collection task (and therefore is not a target endpoint). Typically but not necessarily, endpoints that contain a SACM component (and are therefore part of the SACM domain) are designated as excluded endpoints. Target endpoints that contain a SACM component cannot be designated as excluded endpoints and are part of the SACM domain. Expected Endpoint State: The required state of an endpoint that is to be compared against. Sets of expected endpoint states are - transported as guidance in target endpoint profiles via the - management plane. This, for example, can be a policy, but also a - recorded past state. An expected state is represented can be - represented via an Attribute or an Subject that represents a set - of multiple attribute value pairs. + transported as declarative guidance in target endpoint profiles + via the management plane. This, for example, can be a policy, but + also a recorded past state. An expected state is represented can + be represented via an Attribute or an Subject that represents a + set of multiple attribute value pairs. SACM Function: A behavioral aspect or capacity of a particular SACM component, which belies that SACM component's purpose. For example, a SACM function with interfaces on the control plane can provide a brokering function to other SACM components. Via data plane interfaces, a function can act as a provider and/or as a consumer of information. SACM functions can be propagated as the capabilities of a SACM component and can be discovered by or negotiated with other SACM components. - Guidance: Input instructions to processes and tasks, such as - collection, evaluation or remediation. Guidance influences the - behavior of a SACM component and is considered content of the - management plane. In the context of SACM, guidance is machine- - readable and can be manually or automatically generated or - provided. Typically, the tasks that provide guidance to SACM - components have a low-frequency and tend to be be sporadic. + Guidance: Input instructions to processes, such as automated device + management or remediation, and SACM tasks, such as collection or + evaluation. Guidance influences the behavior of a SACM component + and is considered content of the management plane. In the context + of SACM, guidance is machine-readable and can be manually or + automatically generated or provided. Typically, the tasks that + provide guidance to SACM components have a low-frequency and tend + to be be sporadic. There are two types of guidance: Declarative Guidance: defines the configuration or state an endpoint is supposed to be in--without providing specific actions or methods to produce that desired state. Examples include Target Endpoint Profiles or network topology based requirements. Imperative Guidance: prescribes specific actions to be conducted or methods to be used in order to achieve an outcome. Examples @@ -425,48 +483,50 @@ Hardware Inventory: The list of hardware components that compose a specific endpoint representing its hardware configuration. Hardware Type: Hardware types define specific and distinguishable categories of hardware components that can be part of endpoints, e.g. CPU or 802.11p interface. Typically, hardware types can be distinguished by their vendor assigned names, names of standards used, or a model name. - Information Element: - - A representation of information about physical and virtual "objects - of interests". Information elements are the building blocks that - constitute the SACM information model. In the context of SACM, an - information element that expresses a single value with a specific - name is referred to as an Attribute (analogous to an attribute-value- - pair). A set of attributes that is bundled into a more complex - composite information element is referred to as a Subject. Every - information element in the SACM information model has a unique name. - Endpoint attributes or time stamps, for example, are represented as - information elements in the SACM information model. + Information Element: A representation of information about physical + and virtual "objects of interests". Information elements are the + building blocks that constitute the SACM information model. In + the context of SACM, an information element that expresses a + single value with a specific name is referred to as an Attribute + (analogous to an attribute-value-pair). A set of attributes that + is bundled into a more complex composite information element is + referred to as a Subject. Every information element in the SACM + information model has a unique name. Endpoint attributes or time + stamps, for example, are represented as information elements in + the SACM information model. Information Model: An information model is an abstract representation of data, their properties, relationships between data and the operations that can be performed on the data. While there is some overlap with a data model, [RFC3444] distinguishes an information model as being protocol and implementation neutral whereas a data model would provide such details. The purpose of the SACM information model is to ensure interoperability between SACM data models (that are used as transport encoding) and to provide a standardized set of information elements for communication between SACM components. - Interaction Model: For now this is a Place-Holder. Is an - interaction model that defines, for example, the operations on the - control plane, such as registration or SACM component discovery, - required? + Interaction Model: The definition of specific sequences regarding + the exchange of messages (data in motion), including, for exmaple, + conditional branching, thresholds and timers. An interaction + model, for example, can be used to define operations, such as + registration or discovery, on the control plane. A composition of + data models for data in motion and a corresponding interaction + model is a protocol. Internal Collector: Internal Collector: a collector that runs on a target endpoint to acquire information from that target endpoint. (TBD: An internal collector is not a SACM component and therefore not part of a SACM domain). Management Plane: An architectural component providing common functions to steer the behavior of SACM components, e.g. its behavior on the control plane. Prominent examples include: modification of the configuration of a SACM component or updating @@ -590,20 +651,24 @@ components according to their capabilities or roles on reques. Input: Query Output: a list of SACM components including metadata SACM Component Label: A specific endpoint label that is used to identify a SACM component. In content-metadata, this label is called data origin. + SACM Content: The payload provided by SACM components to the SACM + domain on the data plane. SACM content includes the SACM data + models. + SACM Domain: Endpoints that include a SACM component compose a SACM domain. (To be revised, additional definition content TBD, possible dependencies to SACM architecture) SACM Interface: An interface is defined in [I-D.ietf-i2nsf-terminology] as "A set of operations one object knows it can invoke on, and expose to, another object. This decouples the implementation of the operation from its specification. An interface is a subset of all operations that a given object implements. The same object may have multiple types @@ -646,33 +711,51 @@ including a unique serial number if present (e.g. a text editor associated with a unique license key). Software Instance: A running instance of the software component (e.g. on a multi-user system, one logged-in user has one instance of a text editor running and another logged-in user has another instance of the same text editor running, or on a single-user system, a user could have multiple independent instances of the same text editor running). - Statement: An output of a provider, e.g. a report or an assertion - about a collection result, that includes content-elements and - statement-metadata (e.g. data origin or the point in time at which - the statement was created). A statement can be accompanied by - evidence of the validity of its metadata. + State: A volatile subset endpoint attributes of a (target) endpoint + that is affected by a reboot-cycle. Local state is created by the + interaction of components with other components via the control + plane, via processing data plane payload, or via the functional + properties of local hardware and software components. Dynamic + configuration (e.g. IP address distributed dynamically via an + address distribution and management services, such as DHCP) is + considered state that is the result of the interaction with + another component that provides configuration via the control + plane (e.g. provided by a DHCP server with a specific + configuration). - The structure of statements is defined in the SACM information + Exmaples: The static association of an IP address and a MAC + address in a DHCP server configuration, a directory-path that + identifies a log-file directory, a registry entry. + + Statement: A statement is a subject defined in the SACM information model. - Subject: TODO, incorporate definition from SACM IM + When a statement is used to provide content to a SACM domain, it + is a top-level subject that bundles Content Elements into one + subject and includes metadata about the data origin. - Supplicant: The entity seeking to be authenticated by the Management - Plane for the purpose of participating in the SACM architecture. + Subject: A composite information element. Like Attributes, subjects + have a name and are composed of attributes and/or other subjects. + Every IE that is part of a subject can have a quantitiy associated + with it (e.g. zero-one, none-unbounded). The content IE of a + subject can be an unordered or an ordered list. + + Supplicant: A SACM component seeking to be authenticated via the + control plane for the purpose of participating in a SACM domain. System Resource: Defined in [RFC4949] as "data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. Target Endpoint: A target endpoint is an "endpoint under assessment" (even if it is not actively under assessment at all times) or @@ -724,23 +807,23 @@ merging the corresponding records as new or more refined endpoint attributes become available. Input: discovered target endpoint attributes, endpoint attribute collection, existing characterization records Output: target endpoint characterization records Target Endpoint Classification Task: The task of associating a class from an extensible list of classes with an endpoint - characterization record. TE classes function as guidance for - collection, evaluation, remediation and security posture - assessment in general. + characterization record. TE classes function as imperative and + declarative guidance for collection, evaluation, remediation and + security posture assessment in general. Input: endpoint characterization records (without classification), guidance (how to classify a record) Output: endpoint characterization records (with classification) Target Endpoint Discovery Task: The ongoing task of detecting previously unknown interaction of a potential target endpoint in the SACM domain. TE Discovery is not directly targeted at a specific target endpoint and therefore an un-targeted task. SACM @@ -837,25 +921,26 @@ of endpoints is vulnerable according to the information contained in the vulnerability description information. Vulnerability Description Information: Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. - Vulnerability Detection Data: A type of guidance extracted or - derived from vulnerability description information that describes - the specific mechanisms of vulnerability detection that is used by - an enterprise's vulnerability management capabilities to determine - if a vulnerability is present on an endpoint. + Vulnerability Detection Data: A type of imperative guidance + extracted or derived from vulnerability description information + that describes the specific mechanisms of vulnerability detection + that is used by an enterprise's vulnerability management + capabilities to determine if a vulnerability is present on an + endpoint. Vulnerability Management Capabilities: An enterprise IT department's ability to manage endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing vulnerability assessments. Vulnerability assessment capabilities: An enterprise IT department's ability to determine whether a set of endpoints is vulnerable according to the information contained in the vulnerability @@ -997,49 +1083,61 @@ o Added Configuration Drift, Data in Motion, Data at Rest, Endpoint Management Capability, Hardware Component, Hardware Inventory, Hardware Type, SACM Interface, Target Endpoint Characterization Record, Target Endpoint Characterization Task, Target Endpoint Classification Task, Target Endpoint Discovery Task, Vulnerability Description Information, Vulnerability Detection Data, Vulnerability Management Capability, Vulnerability Assessment o Added references to i2nsf definitions in Capability, SACM - Component, SACM Interface, SACM Role + Component, SACM Interface, SACM Role. - o Added i2nsf Terminology I-D Reference + o Added i2nsf Terminology I-D Reference. - o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier + o Major Updates to Endpoint, SACM Task, Target Endpoint Identifier. o Minor Updates to Guidance, SACM Component Discovery, Target - Endpoint Label, Target Endpoint Profile + Endpoint Label, Target Endpoint Profile. o Relabeled SACM Task o Removed Target Endpoint Discovery Changes from version 10 to version 11: o Added Content Element, Content Metadata, Endpoint Label, - Information Element, Metadata, SACM Component Label, Workflow + Information Element, Metadata, SACM Component Label, Workflow. o Major Updates to Assessment, Capability, Collector, Endpoint Management Capabilities, Guidance, Vulnerability Assessment Capabilities, Vulnerability Detection Data, Vulnerability - Assessment Capabilities + Assessment Capabilities. o Minor updates to Collection Result, Control Plane, Data in Motion, Data at Rest, Data Origin, Network Interface, Statement, Target - Endpoint Label, + Endpoint Label. o Relabeled Endpoint Management Capability, Vulnerability Management - Capability, Vulnerability Assessment + Capability, Vulnerability Assessment. + + Changes from verion 11 to version 12: + + o Added Configuration, Endpoint Characteristic, Event, SACM Content, + State, Subject. + + o Major Updates to Asserition, Data in Motion, Data Provenance, Data + Source, Interaction Model. + + o Minor Updates to Attribute, Control Plane, Data Origin, Data + Provenance, Expected Endpoint State, Guidance, Target Endpoint + Classification Task, Vulnerability Detection Data. 7. Contributors David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20877 USA Email: david.waltermire@nist.gov @@ -1071,24 +1169,24 @@ Double Shot Security 3518 Fremont Avenue North, Suite 363 Seattle, WA 98103 USA Email: merike@doubleshotsecurity.com 8. Informative References [I-D.ietf-i2nsf-terminology] - Hares, S., Strassner, J., Lopez, D., and L. Xia, - "Interface to Network Security Functions (I2NSF) - Terminology", draft-ietf-i2nsf-terminology-01 (work in - progress), July 2016. + Hares, S., Strassner, J., Lopez, D., Xia, L., and H. + Birkholz, "Interface to Network Security Functions (I2NSF) + Terminology", draft-ietf-i2nsf-terminology-03 (work in + progress), March 2017. [I-D.ietf-sacm-vuln-scenario] Coffin, C., Cheikes, B., Schmidt, C., Haynes, D., Fitzgerald-McKay, J., and D. Waltermire, "SACM Vulnerability Assessment Scenario", draft-ietf-sacm-vuln- scenario-02 (work in progress), September 2016. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003,