draft-ietf-sacm-requirements-11.txt   draft-ietf-sacm-requirements-12.txt 
SACM N. Cam-Winget SACM N. Cam-Winget
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Lorenzin Intended status: Informational L. Lorenzin
Expires: May 6, 2016 Pulse Secure Expires: July 25, 2016 Pulse Secure
November 3, 2015 January 22, 2016
Secure Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-11 draft-ietf-sacm-requirements-12
Abstract Abstract
This document defines the scope and set of requirements for the This document defines the scope and set of requirements for the
Secure Automation and Continuous Monitoring (SACM) architecture, data Secure Automation and Continuous Monitoring (SACM) architecture, data
model and transport protocols. The requirements and scope are based model and transport protocols. The requirements and scope are based
on the agreed upon use cases. on the agreed upon use cases.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 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 May 6, 2016. This Internet-Draft will expire on July 25, 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 7 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 8 2.3. Requirements for the Information Model . . . . . . . . . 8
2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transport Protocols . . . . . . . . 13 2.6. Requirements for SACM Transport Protocols . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. Trust between Provider and Requestor . . . . . . . . . . 15 5.1. Trust between Provider and Requestor . . . . . . . . . . 16
5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Today's environment of rapidly-evolving security threats highlights Today's environment of rapidly-evolving security threats highlights
the need to automate the sharing of such information while protecting the need to automate the sharing of security information (such as
user information as well as the systems that store, process, and posture information) while protecting user information as well as the
transmit this information. Security threats can be detected in a systems that store, process, and transmit this information. Security
number of ways. SACM's charter focuses on how to collect and share threats can be detected in a number of ways. SACM's charter focuses
this information based on use cases that involve posture assessment on how to collect and share this information based on use cases that
of endpoints. involve posture assessment of endpoints.
Scalable and sustainable collection, expression, and evaluation of Scalable and sustainable collection, expression, and evaluation of
endpoint information is foundational to SACM's objectives. To secure endpoint information is foundational to SACM's objectives. To secure
and defend a network, one must reliably determine what devices are on and defend a network, one must reliably determine what devices are on
the network, how those devices are configured from a hardware the network, how those devices are configured from a hardware
perspective, what software products are installed on those devices, perspective, what software products are installed on those devices,
and how those products are configured. We need to be able to and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely, determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture consistent, and automated manner to perform endpoint posture
assessments. assessments.
This document focuses on describing the requirements for facilitating This document focuses on describing the requirements for facilitating
the exchange of posture assessment information in the enterprise, in the exchange of posture assessment information in the enterprise, in
particular, for the use cases as exemplified in particular, for the use cases as exemplified in [RFC7632]. Also,
[I-D.ietf-sacm-use-cases]. Also, this document uses terminology this document uses terminology defined in
defined in [I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
When the words appear in lower case, their natural language meaning When the words appear in lower case, their natural language meaning
is used. is used.
2. Requirements 2. Requirements
This document defines requirements based on the SACM use cases This document defines requirements based on the SACM use cases
defined in [I-D.ietf-sacm-use-cases]. This section describes the defined in [RFC7632]. This section describes the requirements used
requirements used by SACM to assess and compare candidate data by SACM to assess and compare candidate data models, interfaces, and
models, interfaces, and protocols, to suit the SACM architecture. protocols, to suit the SACM architecture. These requirements express
These requirements express characteristics or features that a characteristics or features that a candidate protocol, information
candidate protocol or data model must be capable of offering to model, or data model must be capable of offering to ensure security
ensure security and interoperability. and interoperability.
Multiple data models, protocols, and transports may be employed in a Multiple data models, protocols, and transports may be employed in a
SACM environment. A SACM transport protocol is one that runs on top SACM environment. A SACM transport protocol is one that runs on top
of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries
operations (requests / responses), and moves data. operations (requests / responses), and moves data.
SACM defines an architecture and information model focused on SACM defines an architecture and information model focused on
addressing the needs for determining, sharing, and using posture addressing the needs for determining, sharing, and using posture
information via Posture Information Providers and Posture Information information via Posture Information Providers and Posture Information
Consumers mediated by a Controller. With the information model Consumers mediated by a Controller. With the information model
defining assets and attributes to facilitate the guidance, defining assets and attributes to facilitate the guidance,
collection, and assessment of posture, these are some of the tasks collection, and assessment of posture, these are some of the tasks
that should be considered: that should be considered:
1. Asset Classification: Map the assets on the target endpoints to 1. Asset Classification: Map the target endpoint and/or the assets
asset classes. This enables identification of the attributes on the target endpoints to asset classes. This enables
needed to exchange information pertaining to the target endpoint. identification of the attributes needed to exchange information
pertaining to the target endpoint.
2. Attribute Definition: Define the attributes desired to be 2. Attribute Definition: Define the attributes desired to be
collected from each target endpoint. This is what we want to collected from each target endpoint. This is what we want to
know about a target endpoint. For instance, organizations will know about a target endpoint. For instance, organizations will
want to know what software is installed and its many critical want to know what software is installed and its critical security
security attributes such as patch level. attributes such as patch level.
3. Policy Definition: This is where an organization can express its 3. Policy Definition: This is where an organization can express its
policy for acceptable or problematic values of an endpoint policy for acceptable or problematic values of an endpoint
attribute. The expected values of an endpoint attribute are attribute. The expected values of an endpoint attribute are
determined for later comparison against the actual endpoint determined for later comparison against the actual endpoint
attribute values during the evaluation process. Expected values attribute values during the evaluation process. Expected values
may include both those values which are good as well as those may include both those values which are good as well as those
values which represent problems, such as vulnerabilities. The values which represent problems, such as vulnerabilities. The
organization can also specify the endpoint attributes that are to organization can also specify the endpoint attributes that are to
be present for a given target endpoint. be present for a given target endpoint.
skipping to change at page 4, line 23 skipping to change at page 4, line 24
result may become additional endpoint data). result may become additional endpoint data).
6. Result Reporting: Report the results of the evaluation for use by 6. Result Reporting: Report the results of the evaluation for use by
other components. Examples of use of a report would be other components. Examples of use of a report would be
additional evaluation, network enforcement, vulnerability additional evaluation, network enforcement, vulnerability
detection, and license management. detection, and license management.
2.1. Requirements for SACM 2.1. Requirements for SACM
Many deployment scenarios can be instantiated to address the above Many deployment scenarios can be instantiated to address the above
tasks and use cases defined in [I-D.ietf-sacm-use-cases]. To ensure tasks and use cases defined in [RFC7632]. To ensure
interoperability, scalability, and flexibility in any of these interoperability, scalability, and flexibility in any of these
deployments, the following requirements are defined for proposed SACM deployments, the following requirements are defined for proposed SACM
standards: standards:
G-001 Solution Extensibility: The information model, data models, G-001 Solution Extensibility: The information model, data models,
protocols, and transports defined by SACM MUST be designed to allow protocols, and transports defined by SACM MUST be designed to allow
support for future extensions, including both standard and support for future (SACM) extensions. SACM SHOULD allow
proprietary transport protocols and data models. implementations to use their own extensions; either proprietary data
models, protocols or extensions to SACM data models or protocols
could be used though they are not considered to be SACM compliant.
1. The information model and interfaces MUST support the ability to 1. The information model and programmatic interfaces (see G-012 for
add new operations while maintaining backwards compatibility. one example) MUST support the ability to add new operations
SACM-defined transport protocols MUST have extensibility to while maintaining backwards compatibility. SACM-defined
allow them to transport operations that are defined in the transport protocols MUST have extensibility to allow them to
future. transport operations that are defined in the future.
2. The query language MUST allow for general inquiries, as well as 2. The query language MUST allow for general inquiries, as well as
expression of specific attributes or relationships between expression of specific attributes or relationships between
attributes to follow; the retrieval of specific information attributes to follow; the retrieval of specific information
based on an event, or on a continuous basis; and the ability to based on an event, or on a continuous basis; and the ability to
retrieve specific pieces of information, specific types or retrieve specific pieces of information, specific types or
classes of information, or the entirety of available classes of information, or the entirety of available
information. information.
3. The information model MUST accommodate the interoperable 3. The information model MUST accommodate the interoperable
skipping to change at page 5, line 29 skipping to change at page 5, line 32
small in size to a very large datagram or a very large set of small in size to a very large datagram or a very large set of
assessments (up to multiple gigabytes in size). assessments (up to multiple gigabytes in size).
* Large number of providers and consumers: A deployment may consist * Large number of providers and consumers: A deployment may consist
of a very large number of endpoints requesting and/or producing of a very large number of endpoints requesting and/or producing
posture assessment information. posture assessment information.
* Large number of target endpoints: A deployment may be managing * Large number of target endpoints: A deployment may be managing
information of a very large number of target endpoints. information of a very large number of target endpoints.
G-004 Agility: The data model, protocols, and transports MUST be G-004 Versatility: The data model, protocols, and transports MUST be
suitably specified to enable implementations to fit into different suitably specified to enable implementations to fit into different
deployment models and scenarios, including considerations for deployment models and scenarios, including considerations for
implementations of data models and transports operating in implementations of data models and transports operating in
constrained environments. constrained environments.
G-005 Information Extensibility: Non-standard (implementation- G-005 Information Extensibility: Non-standard (implementation-
specific) attributes MUST be supported. A method SHOULD be defined specific) attributes MUST be supported. A method SHOULD be defined
for preventing collisions from occurring in the naming of all for preventing collisions from occurring in the naming of all
attributes independent of their source. For interoperability and attributes independent of their source. For interoperability and
scope boundary, the information model MUST define the mandatory set scope boundary, the information model MUST define the mandatory set
of attributes. The set of attributes defined by the information of attributes.
model MUST be well defined.
G-006 Data Integrity: To protect the information being shared, SACM G-006 Data Integrity: To protect the information being shared, SACM
components MUST protect the integrity and confidentiality of data in components MUST protect the integrity and confidentiality of data in
transit (while information is being transferred between providers transit (while information is being transferred between providers
and consumers, and through proxies and/or repositories) and data at and consumers, and through proxies and/or repositories) and data at
rest (for information stored on repositories and on providers / rest (for information stored on repositories and on providers /
consumers). Mechanisms for this protection are unspecified but consumers). Mechanisms for this protection are unspecified but
should include industry best practices such as encrypted storage, should include industry best practices such as encrypted storage,
encrypted transports, data checksums, etc. These mechanisms are encrypted transports, data checksums, etc. These mechanisms are
required to be available (i.e. all data-handling components must required to be available (i.e. all data-handling components must
skipping to change at page 6, line 19 skipping to change at page 6, line 21
regulatory, operational requirements, overlay boundaries, and regulatory, operational requirements, overlay boundaries, and
federation (where the data may be collected in multiple locations federation (where the data may be collected in multiple locations
and either centralized or kept in the local region). Where and either centralized or kept in the local region). Where
replication of data is supported, it is required that methods exist replication of data is supported, it is required that methods exist
to prevent update loops. to prevent update loops.
G-008 Versioning and Backward Compatibility: Announcement and G-008 Versioning and Backward Compatibility: Announcement and
negotiation of versions, inclusive of existing capabilities (such as negotiation of versions, inclusive of existing capabilities (such as
transport protocols, data models, specific attributes within data transport protocols, data models, specific attributes within data
models, standard attribute expression sets, etc.) MUST be models, standard attribute expression sets, etc.) MUST be
supported. Negotiation for both versioning and capability is needed supported. Negotiation for both versioning and capabilities is
to accommodate future growth and ecosystems with mixed capabilities. needed to accommodate future growth and ecosystems with mixed
capabilities.
G-009 Information Discovery: There MUST be mechanisms for components G-009 Information Discovery: There MUST be mechanisms for components
to discover what information is available across the ecosystem (i.e. to discover what information is available across the ecosystem (i.e.
a method for cataloging data available in the ecosystem and a method for cataloging data available in the ecosystem and
advertising it to consumers), where to go to get a specific piece of advertising it to consumers), where to go to get a specific piece of
that information (i.e. which provider has the information), and what that information (i.e. which provider has the information), and what
schemas are in use for organizing the information. For example, schemas are in use for organizing the information. For example,
providing a method by which a node can locate the advertised providing a method by which a node can locate the advertised
information so that consumers are not required to have a priori information so that consumers are not required to have a priori
knowledge to find available information. knowledge to find available information.
G-010 Target Endpoint Discovery: SACM MUST define the means by which G-010 Target Endpoint Discovery: SACM MUST define the means by which
target endpoints may be discovered. Use Case 2.1.2 describes the target endpoints may be discovered. Use Case 2.1.2 describes the
need to discover endpoints and their composition. need to discover endpoints and their composition.
G-011 Push and Pull Access: Three methods of data access MUST be G-011 Push and Pull Access: Three methods of data access MUST be
supported: the standard Pull model as well as solicited and supported: a Pull model, a solicited Push model, and an unsolicited
unsolicited Push models. All of the methods of data access MUST Push models. All of the methods of data access MUST support the
support the ability for the initiator to filter the set of posture ability for the initiator to filter the set of posture assessment
assessment information to be delivered. Additionally, the provider information to be delivered. Additionally, the provider of the
of the information MUST be able to filter the set of posture information MUST be able to filter the set of posture assessment
assessment information based on the permissions of the recipient. information based on the permissions of the recipient. This
This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5.
G-012 Device Interface: The interfaces by which SACM components G-012 Device Interface: The interfaces by which SACM components
communicate to share endpoint posture information MUST be well communicate to share endpoint posture information MUST be well
defined. That is, the interface defines the data model, SACM defined. That is, the interface defines the data model, SACM
transport protocols, and network transport protocols to enable SACM transport protocols, and network transport protocols to enable SACM
components to communicate. [Revised per our 6/29 conversation - components to communicate.
does this work? -LL]
G-013 Endpoint Location and Network Topology: The SACM architecture G-013 Endpoint Location and Network Topology: The SACM architecture
and interfaces MUST allow for the target endpoint (network) location and interfaces MUST allow for the target endpoint (network) location
and network topology to be modeled and understood. Where and network topology to be modeled and understood. Where
appropriate, the data model and the interfaces SHOULD allow for appropriate, the data model and the interfaces SHOULD allow for
discovery of the target endpoint location or network topology or discovery of the target endpoint location or network topology or
both. both.
G-014 Target Endpoint Identity: The SACM architecture and interfaces G-014 Target Endpoint Identity: The SACM architecture and interfaces
MUST support the ability of components to provide attributes that MUST support the ability of components to provide attributes that
skipping to change at page 8, line 9 skipping to change at page 8, line 11
data exchange between diverse systems, and can leverage a virtual data exchange between diverse systems, and can leverage a virtual
data store that centralizes and offloads all data access, storage, data store that centralizes and offloads all data access, storage,
and maintenance to a dedicated resource. Decentralized data and maintenance to a dedicated resource. Decentralized data
exchange enables simplicity of sharing data between relatively exchange enables simplicity of sharing data between relatively
uniform systems, and between small numbers of systems, especially uniform systems, and between small numbers of systems, especially
within a single enterprise domain. The fact that a centralized or within a single enterprise domain. The fact that a centralized or
decentralized deployment is used SHOULD be invisible to a consumer. decentralized deployment is used SHOULD be invisible to a consumer.
ARCH-005 Capability Negotiation: Announcement and negotiation of ARCH-005 Capability Negotiation: Announcement and negotiation of
functional capabilities (such as authentication protocols, functional capabilities (such as authentication protocols,
authorization schemes, data models, transport protocols, etc.) must authorization schemes, data models, transport protocols, etc.) MUST
be supported, enabling a SACM component to make inquiries about the be supported, enabling a SACM component to make inquiries about the
capabilities of other components in the SACM ecosystem. capabilities of other components in the SACM ecosystem.
ARCH-006 Role-based Authorization: The SACM architecture MUST be ARCH-006 Role-based Authorization: The SACM architecture MUST be
capable of effecting role-based authorization. Distinction of capable of effecting role-based authorization. Distinction of
endpoints capable of and authorized to provide or consume endpoints capable of and authorized to provide or consume
information is required to address appropriate access controls. information is required to address appropriate access controls.
ARCH-007 Context-based Authorization: The SACM architecture MUST be ARCH-007 Context-based Authorization: The SACM architecture MUST be
capable of effecting context-based authorization. Different capable of effecting context-based authorization. Different
skipping to change at page 9, line 8 skipping to change at page 9, line 10
to-implement minimum set.) The attributes should be defined with a to-implement minimum set.) The attributes should be defined with a
clear mechanism for extensibility to enable data models to adhere to clear mechanism for extensibility to enable data models to adhere to
SACM's required attributes as well as allow for their own SACM's required attributes as well as allow for their own
extensions. The attribute vocabulary should be defined with a clear extensions. The attribute vocabulary should be defined with a clear
mechanism for extensibility to enable future versions of the mechanism for extensibility to enable future versions of the
information model to be interoperably expanded with new attributes. information model to be interoperably expanded with new attributes.
IM-002 Posture Data Publication: The information model MUST allow IM-002 Posture Data Publication: The information model MUST allow
for the data to be provided by a SACM component either solicited or for the data to be provided by a SACM component either solicited or
unsolicited. No aspect of the information model should be dependent unsolicited. No aspect of the information model should be dependent
upon or assume a push (unsolicited) or pull (solicited) model of upon or assume a push or pull model of publication.
publication.
IM-003 Data Model Negotiation: SACM's information model MUST allow IM-003 Data Model Negotiation: SACM's information model MUST allow
support for different data models, data model versions, and support for different data models, data model versions, and
different versions of the operations (and network layer transport). different versions of the operations on the data models and
The SACM information model MUST include the ability to discover and transport protocols. The SACM information model MUST include the
negotiate the use of a particular data model or any data model. ability to discover and negotiate the use of a particular data model
or any data model.
IM-004 Data Model Identification: The information model MUST provide IM-004 Data Model Identification: The information model MUST provide
a means to uniquely identify each data model uniquely. The a means to uniquely identify each data model uniquely. The
identifier MUST contain both an identifier of the data model and a identifier MUST contain both an identifier of the data model and a
version indicator for the data model. The identifiers SHOULD be version indicator for the data model. The identifiers SHOULD be
decomposable so that a customer can query for any version of a decomposable so that a customer can query for any version of a
specific data model and compare returned values for older or newer specific data model and compare returned values for older or newer
than a desired version. than a desired version.
IM-005 Data Lifetime Management: The information model MUST provide IM-005 Data Lifetime Management: The information model MUST provide
skipping to change at page 11, line 17 skipping to change at page 11, line 21
data). data).
DM-009 Origination Time: The data model SHOULD allow the provider to DM-009 Origination Time: The data model SHOULD allow the provider to
include the information's origination time. include the information's origination time.
DM-010 Data Generation: The data model MUST allow the provider to DM-010 Data Generation: The data model MUST allow the provider to
include attributes defining how the data was generated (e.g. self- include attributes defining how the data was generated (e.g. self-
reported, reported by aggregator, scan result, etc.). reported, reported by aggregator, scan result, etc.).
DM-011 Data Source: The data model MUST allow the provider to DM-011 Data Source: The data model MUST allow the provider to
include attributes defining the data source (target endpoint from include attributes identifying the data source (target endpoint from
which the data was collected) - e.g. hostname, domain (DNS) name or which the data was collected) - e.g. hostname, domain (DNS) name or
application name. application name.
DM-012 Data Updates: The data model SHOULD allow the provider to DM-012 Data Updates: The data model SHOULD allow the provider to
include attributes defining whether the information provided is a include attributes defining whether the information provided is a
delta, partial, or full set of information. delta, partial, or full set of information.
DM-013 Multiple Collectors: The data model MUST support the DM-013 Multiple Collectors: The data model MUST support the
collection of attributes by a variety of collectors, including collection of attributes by a variety of collectors, including
internal collectors, external collectors with an authenticated internal collectors, external collectors with an authenticated
skipping to change at page 11, line 39 skipping to change at page 11, line 43
network and other observers. network and other observers.
DM-014 Attribute Extensibility: Use Cases in the whole of Section 2 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2
describe the need for an attribute dictionary. With SACM's scope describe the need for an attribute dictionary. With SACM's scope
focused on posture assessment, the data model attribute collection focused on posture assessment, the data model attribute collection
and aggregation MUST have a well-understood set of attributes and aggregation MUST have a well-understood set of attributes
inclusive of their meaning or usage intent. The data model MUST inclusive of their meaning or usage intent. The data model MUST
include all attributes defined in the information model and MAY include all attributes defined in the information model and MAY
include additional attributes beyond those found in the information include additional attributes beyond those found in the information
model. Additional attributes MUST be defined in accordance with the model. Additional attributes MUST be defined in accordance with the
extensibility framework provided in the information model. extensibility framework provided in the information model (see IM-
001).
DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable
a provider to publish data either solicited (in response to a a provider to publish data either solicited (in response to a
request from a consumer) or unsolicited (as new data is generated, request from a consumer) or unsolicited (as new data is generated,
without a request required). For example, an external collector can without a request required). For example, an external collector can
publish data in response to a request by a consumer for information publish data in response to a request by a consumer for information
about an endpoint, or can publish data as it observes new about an endpoint, or can publish data as it observes new
information about an endpoint, without any specific consumer request information about an endpoint, without any specific consumer request
triggering the publication; a compliance-server provider may publish triggering the publication; a compliance-server provider may publish
endpoint posture information in response to a request from a endpoint posture information in response to a request from a
skipping to change at page 12, line 43 skipping to change at page 12, line 47
purpose of this requirement is primarily to reduce the potential purpose of this requirement is primarily to reduce the potential
attack vectors, but has the additional benefit of abstracting the attack vectors, but has the additional benefit of abstracting the
request for collection from the collection method, thereby allowing request for collection from the collection method, thereby allowing
more flexibility in how collection is implemented. more flexibility in how collection is implemented.
OP-003 Collection Composition: A collection request MAY be composed OP-003 Collection Composition: A collection request MAY be composed
of multiple collection requests (which yield collected values). The of multiple collection requests (which yield collected values). The
desire for multiple values MUST be expressed as part of the desire for multiple values MUST be expressed as part of the
collection request, so that the aggregation can be resolved at the collection request, so that the aggregation can be resolved at the
point of collection without having to interact with the requestor. point of collection without having to interact with the requestor.
This requirement SHOULD NOT be interpreted as preventing a collector This requirement should not be interpreted as preventing a collector
from providing attributes which were not part of the original from providing attributes which were not part of the original
request. request.
OP-004 Attribute-based Query: A query operation is the act of OP-004 Attribute-based Query: A query operation is the act of
requesting data from a provider. Query operations SHOULD be based requesting data from a provider. Query operations SHOULD be based
on a set of attributes. Query operations MUST support both a query on a set of attributes. Query operations MUST support both a query
for specific attributes and a query for all attributes. Use Case for specific attributes and a query for all attributes. Use Case
2.1.2 describes the need for the data model to support a query 2.1.2 describes the need for the data model to support a query
operation based on a set of attributes to facilitate collection of operation based on a set of attributes to facilitate collection of
information such as posture assessment, inventory (of endpoints or information such as posture assessment, inventory (of endpoints or
endpoint components), and configuration checklist. endpoint components), and configuration checklist.
OP-005 Information-based Query with Filtering: The query operation OP-005 Information-based Query with Filtering: The query operation
MUST support filtering. Use Case 2.1.3 describes the need for the MUST support filtering. Use Case 2.1.3 describes the need for the
data model to support the means for the information to be collected data model to support the means for the information to be collected
through a query mechanism. Furthermore, the query operation through a query mechanism. Furthermore, the query operation
requires filtering capabilities to allow for only a subset of requires filtering capabilities to allow for only a subset of
information to be retrieved. The query operation MAY be a information to be retrieved. The query operation MAY be a
synchronous request or asynchronous request. synchronous request or asynchronous request.
OP-006 Data Model Scalability: The operation resulting from a query OP-006 Operation Scalability: The operation resulting from a query
operation MUST be able to handle the return and receipt of large operation MUST be able to handle the return and receipt of large
amounts of data. Use Cases 2.1.4 and 2.1.5 describes the need for amounts of data. Use Cases 2.1.4 and 2.1.5 describe the need for
the data model to support scalability. For example, the query the data model to support scalability. For example, the query
operation may result in a very large set of attributes, as well as a operation may result in a very large set of attributes, as well as a
large set of targets. large set of targets.
OP-007 Data Abstraction: The data model MUST allow a SACM component OP-007 Data Abstraction: The data model MUST allow a SACM component
to communicate what data was used to construct the target endpoint's to communicate what data was used to construct the target endpoint's
identity, so other SACM components can determine whether they are identity, so other SACM components can determine whether they are
constructing an equivalent target endpoint (and their identity) and constructing an equivalent target endpoint (and its identity) and
whether they have confidence in that identity. SACM components whether they have confidence in that identity. SACM components
SHOULD have interfaces defined to transmit this data directly or to SHOULD have interfaces defined to transmit this data directly or to
refer to where the information can be retrieved. refer to where the information can be retrieved.
OP-008 Provider Restriction: Request operations MUST include the OP-008 Provider Restriction: Request operations MUST include the
ability to restrict the data to be provided by a specific provider ability to restrict the data to be provided by a specific provider
or a provider with specific characteristics. Response operations or a provider with specific characteristics. Response operations
MUST include the ability to identify the provider that supplied the MUST include the ability to identify the provider that supplied the
response. For example, a SACM Consumer should be able to request response. For example, a SACM Consumer should be able to request
that all of the data come from a specific provider by identity (e.g. that all of the data come from a specific provider by identity (e.g.
skipping to change at page 14, line 18 skipping to change at page 14, line 24
capabilities, and system configurations dealing with connectivity. capabilities, and system configurations dealing with connectivity.
T-002 Data Integrity: SACM transport protocols MUST be able to T-002 Data Integrity: SACM transport protocols MUST be able to
ensure data integrity for data in transit. ensure data integrity for data in transit.
T-003 Data Confidentiality: SACM transport protocols MUST be able to T-003 Data Confidentiality: SACM transport protocols MUST be able to
support data confidentiality. SACM transport protocols MUST ensure support data confidentiality. SACM transport protocols MUST ensure
data protection for data in transit (e.g. by encryption) to provide data protection for data in transit (e.g. by encryption) to provide
confidentiality, integrity, and robustness against protocol-based confidentiality, integrity, and robustness against protocol-based
attacks. Note that while the transport MUST be able to support data attacks. Note that while the transport MUST be able to support data
confidentiality, implementations MAY choose to make confidentiality confidentiality, implementations MAY provide a configuration option
optional. Protection for data at rest is not in scope for transport that enables and disables confidentiality in deployments.
protocols. Data protection MAY be used for both privacy and non- Protection for data at rest is not in scope for transport protocols.
privacy scenarios. Data protection MAY be used for both privacy and non-privacy
scenarios.
T-004 Transport Protection: SACM transport protocols MUST be capable T-004 Transport Protection: SACM transport protocols MUST be capable
of supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
T-005 Transport Reliability: SACM transport protocols MUST provide T-005 Transport Reliability: SACM transport protocols MUST provide
reliable delivery of data. This includes the ability to perform reliable delivery of data. This includes the ability to perform
fragmentation and reassembly, and to detect replays. fragmentation and reassembly, and to detect replays.
T-006 Transport Layer Requirements: Each SACM transport protocol T-006 Transport Layer Requirements: Each SACM transport protocol
MUST clearly specify the transport layer requirements it needs to MUST clearly specify the transport layer requirements it needs to
skipping to change at page 15, line 39 skipping to change at page 15, line 46
controllers / brokers / data repositories. controllers / brokers / data repositories.
In addition, authorization needs to extend to specific information or In addition, authorization needs to extend to specific information or
resources available in the environment. In other words, resources available in the environment. In other words,
authorization is based on the subject (the information requestor), authorization is based on the subject (the information requestor),
the provider (the information responder), the object (the endpoint the provider (the information responder), the object (the endpoint
the information is being requested on), and the attribute (what piece the information is being requested on), and the attribute (what piece
of data is being requested). The method by which this authorization of data is being requested). The method by which this authorization
is applied is unspecified. is applied is unspecified.
SACM's charter focuses on the sharing of posture information for SACM's charter focuses on the workflow orchestration and the sharing
improving efficacy of security applications such as compliance, of posture information for improving efficacy of security
configuration, assurance and other threat and vulnerability reporting applications such as compliance, configuration, assurance and other
and remediation systems. While the goal is to facilitate the flow of threat and vulnerability reporting and remediation systems. While
information securely, it is important to note that participating the goal is to facilitate the flow of information securely, it is
endpoints may not be cooperative or trustworthy. important to note that participating endpoints may not be cooperative
or trustworthy.
5.1. Trust between Provider and Requestor 5.1. Trust between Provider and Requestor
The information given from the provider to a requestor may come with The information given from the provider to a requestor may come with
different levels of trustworthiness given the different potential different levels of trustworthiness given the different potential
deployment scenarios and compromise either at the provider, the deployment scenarios and compromise either at the provider, the
requesting consumer, or devices that are involved in the transport requesting consumer, or devices that are involved in the transport
between the provider and requestor. This section will describe the between the provider and requestor. This section will describe the
different considerations that may reduce the level of trustworthiness different considerations that may reduce the level of trustworthiness
of the information provided. of the information provided.
skipping to change at page 16, line 42 skipping to change at page 16, line 50
and at minimum, provide endpoint authentication and transport and at minimum, provide endpoint authentication and transport
integrity. integrity.
A requestor may require data freshness indications, both knowledge of A requestor may require data freshness indications, both knowledge of
data origination as well as time of publication so that it can make data origination as well as time of publication so that it can make
more informed decisions about the relevance of the data based on its more informed decisions about the relevance of the data based on its
currency and/or age. currency and/or age.
It is also important to note that endpoint assessment reports, It is also important to note that endpoint assessment reports,
especially as they may be provided by the target endpoint may pose especially as they may be provided by the target endpoint may pose
untrustworthy information. The considerations for this is described untrustworthy information. The considerations for this are described
in Section 8 of [RFC5209]. in Section 8 of [RFC5209].
The trustworthiness of the posture information given by the provider The trustworthiness of the posture information given by the provider
to one or many requestors is dependent on several considerations. to one or many requestors is dependent on several considerations.
Some of these include the requestor requiring: Some of these include the requestor requiring:
o Full disclosure of the network topology path to the provider(s). o Full disclosure of the network topology path to the provider(s).
o Direct (peer to peer) communication with the provider. o Direct (peer to peer) communication with the provider.
skipping to change at page 18, line 5 skipping to change at page 18, line 14
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Birkholz, H., "Secure Automation and Continuous Monitoring Birkholz, H., "Secure Automation and Continuous Monitoring
(SACM) Terminology", draft-ietf-sacm-terminology-08 (work (SACM) Terminology", draft-ietf-sacm-terminology-08 (work
in progress), October 2015. in progress), October 2015.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-10 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>.
7.2. Informative References 7.2. Informative References
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, DOI Considerations for Internet Protocols", RFC 6973,
10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <http://www.rfc-editor.org/info/rfc6973>.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
 End of changes. 36 change blocks. 
84 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/