draft-ietf-sacm-terminology-08.txt | draft-ietf-sacm-terminology-09.txt | |||
---|---|---|---|---|
SACM Working Group H. Birkholz | SACM Working Group H. Birkholz | |||
Internet-Draft Fraunhofer SIT | Internet-Draft Fraunhofer SIT | |||
Intended status: Informational October 14, 2015 | Intended status: Informational J. Lu | |||
Expires: April 16, 2016 | Expires: September 22, 2016 Oracle Corporation | |||
N. Cam-Winget | ||||
Cisco Systems | ||||
March 21, 2016 | ||||
Secure Automation and Continuous Monitoring (SACM) Terminology | Secure Automation and Continuous Monitoring (SACM) Terminology | |||
draft-ietf-sacm-terminology-08 | draft-ietf-sacm-terminology-09 | |||
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 31 ¶ | skipping to change at page 1, line 34 ¶ | |||
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 April 16, 2016. | This Internet-Draft will expire on September 22, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 10 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 14 | 8. Informative References . . . . . . . . . . . . . . . . . . . 17 | |||
Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 14 | Appendix A. The Attic . . . . . . . . . . . . . . . . . . . . . 17 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
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 | |||
skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
installed on the endpoint." | installed on the endpoint." | |||
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 Characterization: Asset characterization is the process of | ||||
defining attributes that describe properties of an identified | ||||
asset. | ||||
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: Defined in [RFC5209] as "data element including any | Attribute: Defined in [RFC5209] as "data element including any | |||
requisite meta-data describing an observed, expected, or the | requisite meta-data describing an observed, expected, or the | |||
operational status of an endpoint feature (e.g., anti-virus | operational status of an endpoint feature (e.g., anti-virus | |||
software is currently in use)." If not indicated otherwise, | software is currently in use)." If not indicated otherwise, | |||
attributes in SACM are represented and processed as attribute | attributes in SACM are represented and processed as attribute | |||
value pairs, and the terms attribute and endpoint attribute are | value pairs. | |||
synonyms. | ||||
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 | |||
other SACM components via interfaces on the control plane. A | other SACM components via interfaces on the control plane. A | |||
broker may provide, for example, authorization services and find, | broker may provide, for example, authorization services and find, | |||
upon request, SACM components providing requested services. | upon request, SACM components providing requested services. | |||
Building Block: For SACM, a building block is a unit of | ||||
functionality that is used to compose SACM components. It | ||||
contains SACM functions and may apply to one or more use cases. | ||||
The functions of a building block can have interfaces on the data | ||||
plane, the control plane, or on the management plane. | ||||
Capability: The extent of an SACM component's ability enabled by the | Capability: The extent of an SACM component's ability enabled by the | |||
functions (bundled into building blocks) it is composed of. | functions it is composed of. Capabilities are propagated by a | |||
Capabilities are propagated by a SACM component and can be | SACM component and can be discovered by or negotiated with other | |||
discovered by or negotiated with other SACM components. For | SACM components. For example, the capability of a SACM Provider | |||
example, the capability of a SACM Provider may be to provide | may be to provide endpoint management data, or only a subset of | |||
endpoint management data, or only a subset of that data. | that data. | |||
Collection Result: Information about a target endpoint that is | Collection Result: Information about a target endpoint that is | |||
produced by a collector conducting a collection task. A | produced by a collector conducting a collection task. A | |||
collection result is composed of one or more endpoint attributes. | collection result is composed of one or more endpoint attributes. | |||
Collection Task: The task by which endpoint attributes and/or | Collection Task: The task by which endpoint attributes and/or | |||
corresponding attribute values about a target endpoint are | corresponding attribute values about a target endpoint are | |||
collected. There are three types of collection tasks, each | collected. There are three types of collection tasks, each | |||
requiring an appropriate set of functions to be included in the | requiring an appropriate set of functions to be included in the | |||
SACM component conducting the collection task: | SACM component conducting the collection task: | |||
Self-Reported: A SACM component located on the target endpoint | Self-Reporting: A SACM component located on the target endpoint | |||
itself conducts the collection task. | itself conducts the collection task. | |||
Remote: A SACM component located on an Endpoint different from the | Remote-Acquisition: A SACM component located on an Endpoint | |||
target endpoint conducts the collection task via interfaces | different from the target endpoint conducts the collection task | |||
available on the target endpoint, e.g. SNMP/NETCONF or WMI. | via interfaces available on the target endpoint, e.g. SNMP/ | |||
NETCONF or WMI. | ||||
Observed: A SACM component located on an Endpoint different from | Behavior-Observation: A SACM component located on an Endpoint | |||
the target endpoint observes network traffic related to the target | different from the target endpoint observes network traffic | |||
endpoint and conducts the collection task via interpretation of | related to the target endpoint and conducts the collection task | |||
that network traffic. | via interpretation of that network traffic. | |||
Collector: A piece of software that acquires information about one | Collector: A piece of software that acquires information about one | |||
or more target endpoints by conducting collection tasks. A | or more target endpoints by conducting collection tasks. A | |||
collector provides acquired information to SACM components in the | collector provides acquired information to SACM components in the | |||
form of collection results. A SACM component that consumes | form of collection results. A SACM component that consumes | |||
collection results may take on the role of a provider and publish | collection results may take on the role of a provider and publish | |||
the collection results in a SACM domain. (TBD: A collector may | the collection results in a SACM domain. (TBD: A collector may | |||
not be a SACM component and therefore not part of a SACM domain). | not be a SACM component and therefore not part of a SACM domain). | |||
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. | |||
Control Plane: An architectural component providing common control | Control Plane: Typically used as a term in the context of routing, | |||
functions to all SACM components, including authentication, | e.g. [RFC6192]. In the context of SACM, the control plane is an | |||
authorization, capability discovery or negotiation. The control | architectural component providing common control functions to all | |||
plane orchestrates the flow on the data plane according to | SACM components, including authentication, authorization, | |||
guidance and/or input from the management plane. | capability discovery or negotiation. The control plane | |||
orchestrates the flow on the data plane according to guidance and/ | ||||
or input from 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 | 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 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 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 Origin: One or more properties that enable a SACM component to | Data Origin: One or more properties that enable a SACM component to | |||
identify the SACM component that initially acquired or produced | identify the SACM component that initially acquired or produced | |||
data about a (target) endpoint (e.g. via collection from a data | data about a (target) endpoint (e.g. via collection from a data | |||
source). | source). | |||
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 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. | |||
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. | ||||
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 | |||
that, network infrastructure devices (e.g. switches, routers, | that, network infrastructure devices (e.g. switches, routers, | |||
skipping to change at page 5, line 47 ¶ | skipping to change at page 5, line 49 ¶ | |||
endpoints within this document. | endpoints within this document. | |||
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 attribute is a | Endpoint Attribute: In the context of SACM, endpoint attributes are | |||
synonym for the term attribute. Endpoint Attributes are typically | information elements that describe a characteristic of a target | |||
represented as AVP. | endpoint. Endpoint Attributes typically constitute atomic | |||
information elements (AVP) that can be bundled into composite | ||||
information elements (e.g. information about a specific network | ||||
interface can be represented via a set of multiple AVP). | ||||
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 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 | ||||
characteristics of an individual target endpoint are defined via | ||||
endpoint profiles. | ||||
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. | |||
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. This, for example, can be a policy or a | to be compared against. Sets of expected endpoint states are | |||
recorded past state. A state is represented via a single or an | transported as guidance in target endpoint profiles via the | |||
associated set of attribute value pairs. | management plane. This, for example, can be a policy, but also a | |||
recorded past state. An expected state is represented can be | ||||
represented via a atomic information element or an composite | ||||
information element that represents a set of multiple attribute | ||||
value pairs. | ||||
SACM Function: A behavioral aspect or capacity of a particular | SACM Function: A behavioral aspect or capacity of a particular SACM | |||
building block that is part of a SACM component, which belies that | component, which belies that SACM component's purpose. For | |||
SACM component's purpose. For example, a SACM function with | example, a SACM function with interfaces on the control plane can | |||
interfaces on the control plane can provide a brokering function | provide a brokering function to other SACM components. Via data | |||
to other SACM components. Via data plane interfaces, a function | plane interfaces, a function can act as a provider and/or as a | |||
can act as a provider and/or as a consumer of information. SACM | consumer of information. SACM functions can be propagated as the | |||
functions can be propagated as the capabilities of a SACM | capabilities of a SACM component and can be discovered by or | |||
component and can be discovered by or negotiated with other SACM | negotiated with other SACM components. | |||
components. | ||||
Guidance: Input to processes and tasks, such as collecting, | ||||
assessing or reporting. Guidance influences the behavior of a | ||||
SACM component and is considered content of the management plane. | ||||
Guidance 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. A prominent example | ||||
of guidance are target endpoint profiles, but guidance can have | ||||
many forms, including: | ||||
Configuration, e.g. a SACM component's name, or a CMDB's IPv6 | ||||
address. | ||||
Profiles, e.g. a set of expected states for network behavior | ||||
associated with target endpoints employed by specific users. | ||||
Policies, e.g. an interval to refresh the registration of a SACM | ||||
component, or a list of required capabilities for SACM components | ||||
in a specific location. | ||||
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. | 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? | ||||
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 all SACM participants, including [TBD]. | 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 | ||||
a target endpoint profile that resides on an evaluator. In | ||||
essence, guidance is transported via the management plane. | ||||
Typically, a SACM component can fulfill its purpose without | ||||
continuous input from the management plane. In contrast, without | ||||
continuous availability of control plane functions a typical SACM | ||||
component could not function properly. In general, interaction on | ||||
the management plane is less frequent and less regular than on the | ||||
control plane. Input via the management plane can be manual (e.g. | ||||
via a CLI), or can be automated via management plane functions | ||||
that are part of other SACM components. | ||||
Network Address: Network addresses are layer specific and follow | Network Address: Network addresses are layer specific and follow | |||
layer specific address schemes. Each interface of a specific | layer specific address schemes. Each interface of a specific | |||
layer can be associated with one or more addresses appropriate for | layer can be associated with one or more addresses appropriate for | |||
that layer. There is no guarantee that an address is globally | that layer. There is no guarantee that an address is globally | |||
unique. In general, there is a scope to an address in which it is | unique. In general, there is a scope to an address in which it is | |||
intended to be unique. | intended to be unique. | |||
Examples include: physical Ethernet port with a MAC address, layer | Examples include: physical Ethernet port with a MAC address, layer | |||
2 VLAN interface with a MAC address, layer 3 interface with | 2 VLAN interface with a MAC address, layer 3 interface with | |||
skipping to change at page 8, line 11 ¶ | skipping to change at page 9, line 27 ¶ | |||
Provider: A provider is a SACM role that is assigned to a SACM | Provider: A provider is a SACM role that is assigned to a SACM | |||
component that contains functions to provide information to other | component that contains functions to provide information to other | |||
SACM components. | SACM components. | |||
Proxy: A proxy is a specific controller type that provides data | Proxy: A proxy is a specific controller type that provides data | |||
plane and control plane functions, information, or services on | plane and control plane functions, information, or services on | |||
behalf of another component, which is not directly participating | behalf of another component, which is not directly participating | |||
in the SACM architecture. | in the SACM architecture. | |||
Repository: A repository is a specific controller type that contains | Repository: A repository is a specific controller type that contains | |||
functions to store information of a particular kind - typically | functions to consume, store and provide information of a | |||
data transported on the data plane, but potentially also data and | particular kind - typically data transported on the data plane, | |||
metadata from the control and management plane. A single | but potentially also data and metadata from the control and | |||
repository may provide the functions of more than one specific | management plane. A single repository may provide the functions | |||
repository type (i.e. configuration baseline repository, | of more than one specific repository type (i.e. configuration | |||
assessment results repository, etc.) | baseline repository, assessment results repository, etc.) | |||
SACM Role: SACM roles are associated with SACM components and are | SACM Role: SACM roles are associated with SACM components and are | |||
defined by the set of functions and interfaces a SACM component | defined by the set of functions and interfaces a SACM component | |||
includes. There are three SACM roles: provider, consumer, and | includes. There are three SACM roles: provider, consumer, and | |||
controller. The roles associated with a SACM component are | controller. The roles associated with a SACM component are | |||
determined by the purpose of the functions and corresponding | determined by the purpose of the functions and corresponding | |||
interfaces the SACM component is composed of. | interfaces the SACM component is composed of. | |||
SACM Component: A composition of building blocks that contain SACM | SACM Component: A set of SACM functions composes a SACM component. | |||
functions (acting on control plane, data plane or management | A SACM component conducts SACM tasks, acting on control plane, | |||
plane). SACM defines a set of standard components (e.g. a | data plane and/or management plane via corresponding SACM | |||
interfaces. SACM defines a set of standard components (e.g. a | ||||
collector, a broker, or a data store). A SACM component contains | collector, a broker, or a data store). A SACM component contains | |||
at least a basic set of control plane building blocks and can | at least a basic set of control plane functions and can contain | |||
contain data plane and management plane building blocks. A SACM | data plane and management plane functions. A SACM component | |||
component residing on an endpoint assigns one or more SACM roles | residing on an endpoint assigns one or more SACM roles to the | |||
to the corresponding endpoint due to the SACM functions it is | corresponding endpoint due to the SACM functions it is composed | |||
composed of. A SACM component "resides on" an endpoint and an | of. A SACM component "resides on" an endpoint and an endpoint | |||
endpoint "contains" a SACM component, correspondingly. For | "contains" a SACM component, correspondingly. For example, a SACM | |||
example, a SACM component that is composed solely of building | component that is composed solely of functions that provide | |||
blocks that provide information is a provider. | information would only take on the role of a provider. | |||
SACM Component Discovery: The function by which a SACM component | SACM Component Discovery: The function by which a SACM component | |||
(e.g. by role, capabilities, or data provided/consumed) can be | (e.g. by role, capabilities, or data provided/consumed) can be | |||
discovered. | discovered. | |||
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) | |||
Security Automation: The process of which security alerts can be | Security Automation: The process of which security alerts can be | |||
automated through the use of different tools to monitor, evaluate | automated through the use of different tools to monitor, evaluate | |||
and analyze endpoint and network traffic for the purposes of | and analyze endpoint and network traffic for the purposes of | |||
detecting misconfigurations, misbehaviors or threats. | detecting misconfigurations, misbehaviors or threats. | |||
Software Package: A generic software package (e.g. a text editor). | ||||
Software Component: A software package installed on an endpoint, | ||||
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: The output of a provider, e.g. a report or an assertion | Statement: The output of a provider, e.g. a report or an assertion | |||
acquired via a collection result from a collector, that includes | acquired via a collection result from a collector, that includes | |||
metadata about the data origin and the point in time the statement | metadata about the data origin and the point in time the statement | |||
was created at. A statement can be accompanied by evidence of the | was created at. A statement can be accompanied by evidence of the | |||
validity of its metadata. | validity of its metadata. | |||
Supplicant: The entity seeking to be authenticated by the Management | Supplicant: The entity seeking to be authenticated by the Management | |||
Plane for the purpose of participating in the SACM architecture. | Plane for the purpose of participating in the SACM architecture. | |||
System Resource: Defined in [RFC4949] as "data contained in an | System Resource: Defined in [RFC4949] as "data contained in an | |||
skipping to change at page 9, line 47 ¶ | skipping to change at page 11, line 30 ¶ | |||
referring to a specific target endpoint. Depending on the | referring to a specific target endpoint. Depending on the | |||
available identifying attributes this reference can be ambiguous | available identifying attributes this reference can be ambiguous | |||
and is a "best-effort" mechanism. Every distinct set of | and is a "best-effort" mechanism. Every distinct set of | |||
identifying endpoint attributes can be associated with a unique | identifying endpoint attributes can be associated with a unique | |||
target endpoint label. | target endpoint label. | |||
Target Endpoint Label: An artificially created id that references a | Target Endpoint Label: An artificially created id that references a | |||
distinct set of identifying attributes (Target Endpoint | distinct set of identifying attributes (Target Endpoint | |||
Identifier). A target endpoint label is unique in a SACM domain | Identifier). A target endpoint label is unique in a SACM domain | |||
and created by a SACM component that contains an appropriate | and created by a SACM component that contains an appropriate | |||
building block of functions. | function. | |||
Target Endpoint Profile: A bundle of expected or desired | ||||
configurations and states (typically a composition of endpoint | ||||
attribute value pairs) that can be associated with a target | ||||
endpoint. The corresponding task by which the association with a | ||||
target endpoint takes places is the endpoint classification. The | ||||
task by which a endpoint profile is created is the endpoint | ||||
characterization. A type or class of target endpoints is defined | ||||
within a target endpoint profile, e.g. printer, smartphone, or an | ||||
office PC. | ||||
(SACM) Task: [TBD conflicts in definitions of specific tasks] A SACM | ||||
task is conducted by one or more SACM functions that reside on a | ||||
SACM component (e.g. a collection task or endpoint | ||||
characterization). A SACM task can be triggered by other | ||||
operations or functions (e.g. a query from another SACM component | ||||
or an unsolicited push due to a subscription on the data plane). | ||||
A task is part of a SACM process chain. A task starts at a given | ||||
point in time and ends in a deterministic state. With the | ||||
exception of a collection task, a SACM task consumes SACM content. | ||||
The output of a task is a result that can be provided (e.g. | ||||
published) on the data plane. There are six fundamental tasks | ||||
defined in SACM: | ||||
Asset Classification: Map the assets on the target endpoints to | ||||
asset classes. This enables identification of the attributes | ||||
needed to exchange information pertaining to the target endpoint. | ||||
[the label now conflicts with Endpoint Classification] | ||||
Attribute Definition: Define the attributes desired to be | ||||
collected from each target endpoint. This is what we want to know | ||||
about a target endpoint. For instance, organizations will want to | ||||
know what software is installed and its many critical security | ||||
attributes such as patch level. | ||||
Policy Definition: This is where an organization can express its | ||||
policy for acceptable or problematic values of an endpoint | ||||
attribute. The expected values of an endpoint attribute are | ||||
determined for later comparison against the actual endpoint | ||||
attribute values during the evaluation process. Expected values | ||||
may include both those values which are good as well as those | ||||
values which represent problems, such as vulnerabilities. The | ||||
organization can also specify the endpoint attributes that are to | ||||
be present for a given target endpoint. | ||||
Information Collection: Collect information (attribute values) | ||||
from the target endpoint to populate the endpoint data. | ||||
Endpoint Assessment: Evaluate the actual values of the endpoint | ||||
attributes against those expressed in the policy. (An evaluation | ||||
result may become additional endpoint data). | ||||
Result Reporting: Report the results of the evaluation for use by | ||||
other components. Examples of use of a report would be additional | ||||
evaluation, network enforcement, vulnerability detection, and | ||||
license management. | ||||
Timestamps : Defined in [RFC4949] as "with respect to a data object, | Timestamps : Defined in [RFC4949] as "with respect to a data object, | |||
a label or marking in which is recorded the time (time of day or | a label or marking in which is recorded the time (time of day or | |||
other instant of elapsed time) at which the label or marking was | other instant of elapsed time) at which the label or marking was | |||
affixed to the data object" and as "with respect to a recorded | affixed to the data object" and as "with respect to a recorded | |||
network event, a data field in which is recorded the time (time of | network event, a data field in which is recorded the time (time of | |||
day or other instant of elapsed time) at which the event took | day or other instant of elapsed time) at which the event took | |||
place.". | place.". | |||
This term is used in SACM to describe a recorded point in time at | This term is used in SACM to describe a recorded point in time at | |||
skipping to change at page 12, line 5 ¶ | skipping to change at page 14, line 42 ¶ | |||
o Added Authentication, Authorization, Data Confidentiality, Data | o Added Authentication, Authorization, Data Confidentiality, Data | |||
Integrity, Data Origin, Data Provenance, SACM Component, SACM | Integrity, Data Origin, Data Provenance, SACM Component, SACM | |||
Component Discovery, Target Endpoint Discovery. | Component Discovery, Target Endpoint Discovery. | |||
o Major updates to Building Block, Function, SACM Role, Target | o Major updates to Building Block, Function, SACM Role, Target | |||
Endpoint. | Endpoint. | |||
o Minor updates to Broker, Capability, Collection Task, Evaluation | o Minor updates to Broker, Capability, Collection Task, Evaluation | |||
Task, Posture. | Task, Posture. | |||
o Relabled Role to SACM Role, Endpoint Target to Target Endpoint, | o Relabeled Role to SACM Role, Endpoint Target to Target Endpoint, | |||
Endpoint Discovery to Endpoint Identification. | Endpoint Discovery to Endpoint Identification. | |||
o Moved Asset Targeting, Client, Endpoint Identification to The | o Moved Asset Targeting, Client, Endpoint Identification to The | |||
Attic. | Attic. | |||
o Endpoint Attributes added as a TODO. | o Endpoint Attributes added as a TODO. | |||
o Changed the structure of the Change Log. | o Changed the structure of the Change Log. | |||
Changes from version 07 to version 08: | Changes from version 07 to version 08: | |||
skipping to change at page 12, line 32 ¶ | skipping to change at page 15, line 20 ¶ | |||
o Major updates to Attributes, Broker, Collection Task, Consumer, | o Major updates to Attributes, Broker, Collection Task, Consumer, | |||
Controller, Control Plane, Endpoint Attributes, Expected Endpoint | Controller, Control Plane, Endpoint Attributes, Expected Endpoint | |||
State, SACM Function, Provider, Proxy, Repository, SACM Role, | State, SACM Function, Provider, Proxy, Repository, SACM Role, | |||
Target Endpoint. | Target Endpoint. | |||
o Minor updates to Asset, Building Block, Data Origin, Data Source, | o Minor updates to Asset, Building Block, Data Origin, Data Source, | |||
Data Provenance, Endpoint, Management Plane, Posture, Posture | Data Provenance, Endpoint, Management Plane, Posture, Posture | |||
Attribute, SACM Component, SACM Component Discovery, Target | Attribute, SACM Component, SACM Component Discovery, Target | |||
Endpoint Discovery. | Endpoint Discovery. | |||
o Relabled Function to SACM Function. | o Relabeled Function to SACM Function. | |||
Changes from version 08 to version 09: | ||||
o Updated author list. | ||||
o Added Data Plane, Endpoint Characterization, Endpoint | ||||
Classification, Guidance, Interaction Model, Software Component, | ||||
Software Instance, Software Package, Statement, Target Endpoint | ||||
Profile, SACM Task. | ||||
o Removed Building Block. | ||||
o Major updates to Control Plane, Endpoint Attribute, Expected | ||||
Endpoint State, Information Model, Management Plane. | ||||
o Minor updates to Attribute, Capabilities, SACM Function, SACM | ||||
Component, Collection Task. | ||||
o Moved Asset Characterization to The Attic. | ||||
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 14, line 21 ¶ | skipping to change at page 17, line 24 ¶ | |||
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI | [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI | |||
36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | |||
<http://www.rfc-editor.org/info/rfc4949>. | <http://www.rfc-editor.org/info/rfc4949>. | |||
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. | [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. | |||
Tardo, "Network Endpoint Assessment (NEA): Overview and | Tardo, "Network Endpoint Assessment (NEA): Overview and | |||
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, | Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, | |||
<http://www.rfc-editor.org/info/rfc5209>. | <http://www.rfc-editor.org/info/rfc5209>. | |||
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the | ||||
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, | ||||
March 2011, <http://www.rfc-editor.org/info/rfc6192>. | ||||
[X.1252] "ITU-T X.1252 (04/2010)", n.d.. | [X.1252] "ITU-T X.1252 (04/2010)", n.d.. | |||
Appendix A. The Attic | Appendix A. The Attic | |||
The following terms are stashed for now and will be updated later: | The following terms are stashed for now and will be updated later: | |||
Asset Characterization: Asset characterization is the process of | ||||
defining attributes that describe properties of an identified | ||||
asset. | ||||
Asset Targeting: Asset targeting is the use of asset identification | Asset Targeting: Asset targeting is the use of asset identification | |||
and categorization information to drive human-directed, automated | and categorization information to drive human-directed, automated | |||
decision making for data collection and analysis in support of | decision making for data collection and analysis in support of | |||
endpoint posture assessment. | endpoint posture assessment. | |||
Client: An architectural component receiving services from another | Client: An architectural component receiving services from another | |||
architectural component. | architectural component. | |||
Endpoint Identification (TBD per list; was "Endpoint Discovery"): | Endpoint Identification (TBD per list; was "Endpoint Discovery"): | |||
The process by which an endpoint can be identified. | The process by which an endpoint can be identified. | |||
Author's Address | Authors' Addresses | |||
Henk Birkholz | Henk Birkholz | |||
Fraunhofer SIT | Fraunhofer SIT | |||
Rheinstrasse 75 | Rheinstrasse 75 | |||
Darmstadt 64295 | Darmstadt 64295 | |||
Germany | Germany | |||
Email: henk.birkholz@sit.fraunhofer.de | Email: henk.birkholz@sit.fraunhofer.de | |||
Jarrett Lu | ||||
Oracle Corporation | ||||
4180 Network Circle | ||||
Santa Clara, CA 95054 | ||||
USA | ||||
Email: jarrett.lu@oracle.com | ||||
Nancy Cam-Winget | ||||
Cisco Systems | ||||
3550 Cisco Way | ||||
San Jose, CA 95134 | ||||
USA | ||||
Email: ncamwing@cisco.com | ||||
End of changes. 32 change blocks. | ||||
85 lines changed or deleted | 250 lines changed or added | |||
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |