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