draft-ietf-sacm-requirements-16.txt   draft-ietf-sacm-requirements-17.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: December 17, 2017 Pulse Secure Expires: December 29, 2017 Pulse Secure
June 15, 2017 June 27, 2017
Security Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-16 draft-ietf-sacm-requirements-17
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 transfer protocols. The requirements and scope are based
on the agreed upon use cases. on the agreed upon use cases ([RFC7632]).
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.
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 December 17, 2017. This Internet-Draft will expire on December 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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
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 . . . . . . . . . 9
2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 2.4. Requirements for the Data Model . . . . . . . . . . . . . 10
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transport Protocols . . . . . . . . 14 2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. Trust between Provider and Requestor . . . . . . . . . . 16 5.1. Trust between Provider and Requestor . . . . . . . . . . 16
5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . 18
7.1. Normative 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 security information (such as the need to automate the sharing of security information (such as
posture information) while protecting user information as well as the posture information) while protecting user information and the
systems that store, process, and transmit this information. Security systems that store, process, and transmit this information. Security
threats can be detected in a number of ways. SACM's charter focuses threats can be detected in a number of ways. The Secure Automation
on how to collect and share this information based on use cases that and Continuous Monitoring (SACM) charter focuses on how to collect
involve posture assessment of endpoints. and share this information based on use cases that 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 [RFC7632]. Also, particular, for the use cases as exemplified in [RFC7632]. As
this document uses terminology defined in proposals are evaluated for SACM standardization, their drafts are
expected to include a section that describe how they address each of
the enumerated requirements.
Also, this document uses terminology 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", Use of each capitalized word within a sentence or phrase carries the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this following meaning during the SACM WG's protocol selection process:
document are to be interpreted as described in RFC 2119 [RFC2119].
MUST - indicates an absolute requirement
MUST NOT - indicates something absolutely prohibited
SHOULD - indicates a strong recommendation of a desired result
SHOULD NOT - indicates a strong recommendation against a result
MAY - indicates a willingness to allow an optional outcome
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
described in [RFC7632]. This section describes the requirements used described in [RFC7632]. This section describes the requirements used
by SACM to assess and compare candidate data models, interfaces, and by SACM to assess and compare candidate data models, interfaces, and
protocols, to suit the SACM architecture. These requirements express protocols. These requirements express characteristics or features
characteristics or features that a candidate protocol, information that a candidate protocol, information model, or data model must be
model, or data model must be capable of offering to ensure security capable of offering to ensure security and interoperability.
and interoperability.
Multiple data models, protocols, and transports may be employed in a Multiple data models, protocols, and transfers may be employed in a
SACM environment. A SACM transport protocol is one that runs on top SACM environment. A SACM transfer protocol is one that runs on top
of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries of transport layer protocols such as TCP/IP or internet layer
operations (requests / responses), and moves data. protocols such as HTTP, carries operations (requests / responses),
and moves data.
SACM defines an architecture and information model focused on SACM will define 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 securely. With the information model defining assets and
defining assets and attributes to facilitate the guidance, attributes to facilitate the guidance, collection, and assessment of
collection, and assessment of posture, these are some of the tasks posture, tasks that should be considered include:
that should be considered:
1. Asset Classification: Map the target endpoint and/or the assets 1. Asset Classification: Map the target endpoint and/or the assets
on the target endpoints to asset classes. This enables on the target endpoints to asset classes. This enables
identification of the attributes needed to exchange information identification of the attributes needed to exchange information
pertaining to the target endpoint. 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. For instance, organizations collected from each target endpoint. For instance, organizations
will want to know what software is installed and its critical will want to know what software is installed and its critical
security attributes such as patch level. security attributes such as patch level.
skipping to change at page 4, line 29 skipping to change at page 4, line 41
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 [RFC7632]. 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 transfers defined by SACM MUST be designed to allow
support for future (SACM) extensions. SACM MUST allow support for future (SACM) extensions. SACM MUST allow
implementations to use their own extensions; either proprietary data implementations to use their own extensions; either proprietary data
models, protocols or extensions to SACM data models or protocols models, protocols or extensions to SACM data models or protocols
could be used though they are not considered to be SACM compliant. could be used though they are not considered to be SACM compliant.
1. The information model and programmatic interfaces (see G-012 for 1. The information model and programmatic interfaces (see G-012 for
one example) MUST support the ability to add new operations one example) MUST support the ability to add new operations
while maintaining backwards compatibility. SACM-defined while maintaining backwards compatibility. SACM-defined
transport protocols MUST have extensibility to allow them to transfer protocols MUST have extensibility to allow them to
transport operations that are defined in the future. transfer 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; the retrieval of specific information based on an
based on an event, or on a continuous basis; and the ability to event, or on a continuous basis; and the ability to retrieve
retrieve specific pieces of information, specific types or specific pieces of information, specific types or classes of
classes of information, or the entirety of available information, or the entirety of available information.
information.
3. The information model MUST accommodate the interoperable 3. The information model MUST accommodate the interoperable
addition of new data types and/or schemas. addition of new data types and/or schemas.
G-002 Interoperability: The data models, protocols, and transports G-002 Interoperability: The data models, protocols, and transpors
must be specified with enough details to ensure interoperability. MUST be specified with enough details to ensure interoperability.
G-003 Scalability: SACM needs to support a broad set of deployment G-003 Scalability: SACM needs to support a broad set of deployment
scenarios. The data models, protocols, and transports MUST be scenarios. The data models, protocols, and transports has to be
scalable unless they are specifically defined to apply to a special- scalable unless they are specifically defined to apply to a special-
purpose scenario, such as constrained devices. A SACM transport purpose scenario, such as constrained devices. A SACM transfer
protocol standard SHOULD include a section on scalability protocol standard SHOULD include a section on scalability
considerations that addresses the number of endpoints and amount of considerations that addresses the number of endpoints and amount of
information to which it can reasonably be expected to scale. information to which it can reasonably be expected to scale.
Scalability must be addressed to support: Scalability must be addressed to support:
* Large datagrams: It is possible that the size of posture * Large message: It is possible that the size of posture assessment
assessment information can vary from a single assessment that is information can vary from a single assessment that is small in
small in size to a very large datagram or a very large set of size to a very large message or a very large set of assessments
assessments (up to multiple gigabytes in size). (up to multiple gigabytes in size).
* Large number of datagrams per second: A deployment may involve * Large number of messages per second: A deployment may involve
many rapid or simultaneous events that require processing, many rapid or simultaneous events that require processing,
generating many datagrams per second. generating many messages per second.
* 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 Versatility: 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
skipping to change at page 6, line 5 skipping to change at page 6, line 14
constrained environments. Separate solutions may be necessary to constrained environments. Separate solutions may be necessary to
meet the needs of specific deployment models and scenarios. meet the needs of specific deployment models and scenarios.
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. of attributes.
G-006 Data Integrity: To protect the information being shared, SACM G-006 Data Protection: 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 middle boxes and/or repositories) and and consumers, and through middle boxes and/or repositories) and
data at rest (for information stored on repositories and on data at rest (for information stored on repositories and on
providers / consumers). Mechanisms for this protection are providers / consumers). Mechanisms for this protection are
unspecified but should include industry best practices such as unspecified but should include industry best practices. These
encrypted storage, encrypted transports, data checksums, etc. These
mechanisms are required to be available (i.e. all data-handling mechanisms are required to be available (i.e. all data-handling
components must support them), but are not required to be used in components must support them), but are not required to be used in
all cases. all cases.
G-007 Data Partitioning: A method for partitioning data MUST be G-007 Data Partitioning: A method for partitioning data MUST be
supported to accommodate considerations such as geographic, supported to accommodate considerations such as geographic,
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 transfer 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 capabilities is supported. Negotiation for both versioning and capabilities is
needed to accommodate future growth and ecosystems with mixed needed to accommodate future growth and ecosystems with mixed
capabilities. 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
skipping to change at page 7, line 10 skipping to change at page 7, line 21
Push models. All of the methods of data access MUST support the Push models. All of the methods of data access MUST support the
ability for the initiator to filter the set of posture assessment ability for the initiator to filter the set of posture assessment
information to be delivered. Additionally, the provider of the information to be delivered. Additionally, the provider of the
information MUST be able to filter the set of posture assessment information MUST be able to filter the set of posture assessment
information based on the permissions of the recipient. This information based on the permissions of the recipient. 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 SACM Component Interface: The interfaces by which SACM G-012 SACM Component Interface: The interfaces by which SACM
components communicate to share endpoint posture information MUST be components communicate to share endpoint posture information MUST be
well defined. That is, the interface defines the data model, SACM well defined. That is, the interface defines the data model, SACM
transport protocols, and network transport protocols to enable SACM transfer protocols, and network transfer protocols to enable SACM
components to communicate. components to communicate.
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
skipping to change at page 7, line 33 skipping to change at page 7, line 44
identities MAY be composed of attributes from one or more SACM identities MAY be composed of attributes from one or more SACM
components. components.
G-015 Data Access Control: Methods of access control MUST be G-015 Data Access Control: Methods of access control MUST be
supported to accommodate considerations such as geographic, supported to accommodate considerations such as geographic,
regulatory, operational and federations. Entities accessing or regulatory, operational and federations. Entities accessing or
publishing data MUST identify themselves and pass access policy. publishing data MUST identify themselves and pass access policy.
2.2. Requirements for the Architecture 2.2. Requirements for the Architecture
At the simplest abstraction, the SACM architecture represents the At the simplest abstraction, the SACM architecture MUST represent the
core components and interfaces needed to perform the production and core components and interfaces needed to perform the production and
consumption of posture assessment information. Requirements relating consumption of posture assessment information. Requirements relating
to SACM's architecture include: to SACM's architecture include:
ARCH-001 Scalability: The architectural components MUST account for ARCH-001 Scalability: The architectural components MUST account for
a range of deployments, from very small sets of endpoints to very a range of deployments, from very small sets of endpoints to very
large deployments. large deployments.
ARCH-002 Flexibility: The architectural components MUST account for ARCH-002 Flexibility: The architectural components MUST account for
different deployment scenarios where the architectural components different deployment scenarios where the architectural components
may be implemented, deployed, or used within a single application, may be implemented, deployed, or used within a single application,
service, or network, or may comprise a federated system. service, or network, or may comprise a federated system.
ARCH-003 Separation of Data and Management Functions: SACM MUST ARCH-003 Separation of Data and Management Functions: SACM MUST
define both the configuration and management of the SACM data models define both the configuration and management of the SACM data models
and protocols used to transport and share posture assessment and protocols used to transfer and share posture assessment
information. information.
ARCH-004 Topology Flexibility: Both centralized and decentralized ARCH-004 Topology Flexibility: Both centralized and decentralized
(peer-to-peer) information exchange MUST be supported. Centralized (peer-to-peer) information exchange MUST be supported. Centralized
data exchange enables use of a common data format to bridge together data exchange enables use of a common data format to bridge together
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, transfer 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 20 skipping to change at page 9, line 30
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 or pull model of publication. upon or assume a push or pull model of 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 on the data models and different versions of the operations on the data models and transfer
transport protocols. The SACM information model MUST include the protocols. The SACM information model MUST include the ability to
ability to discover and negotiate the use of a particular data model discover and negotiate the use of a particular data model or any
or any data model. 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. The identifier MUST
identifier MUST contain both an identifier of the data model and a contain both an identifier of the data model and a version indicator
version indicator for the data model. The identifiers SHOULD be for the data model. The identifiers SHOULD be decomposable so that
decomposable so that a customer can query for any version of a a customer can query for any version of a specific data model and
specific data model and compare returned values for older or newer 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
a means to allow data models to include data lifetime management. a means to allow data models to include data lifetime management.
The information model must identify attributes that can allow data The information model must identify attributes that can allow data
models to, at minimum, identify the data's origination time and models to, at minimum, identify the data's origination time and
expected time of next update or data longevity (how long should the expected time of next update or data longevity (how long should the
data be assumed to still be valid). data be assumed to still be valid).
IM-006 Singularity and Modularity: The SACM information model MUST IM-006 Singularity and Modularity: The SACM information model MUST
be singular (i.e. there is only one information model, not multiple be singular (i.e. there is only one information model, not multiple
skipping to change at page 12, line 17 skipping to change at page 12, line 25
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
consumer (solicited), or it may publish posture information driven consumer (solicited), or it may publish posture information driven
by a change in the posture of the endpoint (unsolicited). by a change in the posture of the endpoint (unsolicited).
DM-016 Transport Agnostic: The data model MUST be transport DM-016 tTransfer Agnostic: The data model MUST be transfer agnostic,
agnostic, to allow for the data operations to leverage the most to allow for the data operations to leverage the most appropriate
appropriate SACM transport protocol. SACM transfer protocol.
2.5. Requirements for Data Model Operations 2.5. Requirements for Data Model Operations
Posture information data adhering to a data model must also provide Posture information data adhering to a data model must also provide
interfaces that include operations for access and production of the interfaces that include operations for access and production of the
data. Operations requirements are distinct from transport data. Operations requirements are distinct from transfer
requirements in that operations requirements are requirements on the requirements in that operations requirements are requirements on the
application performing requests and responses, whereas transport application performing requests and responses, whereas transfer
requirements are requirements on the transport protocol carrying the requirements are requirements on the transfer protocol carrying the
requests / responses. The specific requirements for such operations requests / responses. The specific requirements for such operations
include: include:
OP-001 Time Synchronization: Request and response operations MUST be OP-001 Time Synchronization: Request and response operations MUST be
timestamped, and published information SHOULD capture time of timestamped, and published information SHOULD capture time of
publication. Actions or decisions based on time-sensitive data publication. Actions or decisions based on time-sensitive data
(such as user logon/logoff, endpoint connection/disconnection, (such as user logon/logoff, endpoint connection/disconnection,
endpoint behavior events, etc.) are all predicated on a synchronized endpoint behavior events, etc.) are all predicated on a synchronized
understanding of time. A method for detecting and reporting time understanding of time. A method for detecting and reporting time
discrepancies SHOULD be provided. discrepancies SHOULD be provided.
skipping to change at page 14, line 5 skipping to change at page 14, line 14
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.
Provider A) or from a Provider that is in a specific location (e.g. Provider A) or from a Provider that is in a specific location (e.g.
in the Boston office). in the Boston office).
2.6. Requirements for SACM Transport Protocols 2.6. Requirements for SACM Transfer Protocols
The term SACM transfer protocol is intended to be distinguished from The term SACM transfer protocol is intended to be distinguished from
underlying layer 3 and 4 protocols such as TCP/IP, operating at an underlying transport and internet layer protocols such as TCP/IP or
equivalent level as the hyperText transfer protocol (HTTP). The SACM operating at an equivalent level as the HTTP. The SACM transfer
transfer protocol is focused on moving data and performing necessary protocol is focused on moving data and performing necessary access
access control operations; it is agnostic to the data model control operations; it is agnostic to the data model operations.
operations.
The requirements for SACM transport protocols include: The requirements for SACM transfer protocols include:
T-001 Multiple Transport Protocol Support: SACM transfer protocols T-001 Multiple transfer Protocol Support: SACM transfer protocols
will vary depending on the deployment model that relies on different will vary depending on the deployment model that relies on different
transport layer requirements, different device capabilities, and transfer layer requirements, different device capabilities, and
system configurations dealing with connectivity. system configurations dealing with connectivity. For example, where
posture attributes may be collected directly from an endpoint using
NEA's model [RFC5209], different transports may be defined to
collect them using PT-EAP [RFC7171] or PT-TLS [RFC6876] depending on
the deployment scenario.
T-002 Data Integrity: SACM transfer protocols MUST be able to ensure T-002 Data Integrity: SACM transfer protocols MUST be able to ensure
data integrity for data in transit. data integrity for data in transit.
T-003 Data Confidentiality: SACM transfer protocols MUST be able to T-003 Data Confidentiality: SACM transfer protocols MUST be able to
support data confidentiality. SACM transport protocols MUST ensure support data confidentiality. SACM transfer 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 transfer MUST be able to support data
confidentiality, implementations MAY provide a configuration option confidentiality, implementations MAY provide a configuration option
that enables and disables confidentiality in deployments. that enables and disables confidentiality in deployments.
Protection for data at rest is not in scope for transport protocols. Protection for data at rest is not in scope for transfer protocols.
Data protection MAY be used for both privacy and non-privacy Data protection MAY be used for both privacy and non-privacy
scenarios. scenarios.
T-004 Transport Protection: SACM transfer protocols MUST be capable T-004 Transfer Protection: SACM transfer protocols MUST be capable
of supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
T-005 Transport Reliability: SACM transfer protocols MUST provide T-005 Transfer Reliability: SACM transfer 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. The SACM fragmentation and reassembly, and to detect replays. The SACM
transfer may take advantage of reliability features in the network transfer may take advantage of reliability features in the network
transport; however, the network transport may be unreliable (e.g. transport; however, the network transport may be unreliable (e.g.
UDP), in which case the SACM transport running over the unreliable UDP), in which case the SACM transfer running over the unreliable
network transport is responsible for ensuring reliability (i.e. by network transport is responsible for ensuring reliability (i.e. by
provisions such as confirmations and re-transmits). provisions such as confirmations and re-transmits).
T-006 Transport Layer Requirements: Each SACM transfer protocol MUST T-006 Transfer Layer Requirements: Each SACM transfer protocol MUST
clearly specify the transport layer requirements it needs to operate clearly specify the transport layer requirements it needs to operate
correctly. Examples of items that may need to be specified include correctly. Examples of items that may need to be specified include
connectivity requirements, replay requirements, data link encryption connectivity requirements, replay requirements, data link encryption
requirements, and/or channel binding requirements. These requirements, and/or channel binding requirements. These
requirements are needed in order for deployments to be done requirements are needed in order for deployments to be done
correctly. correctly.
3. Acknowledgements 3. Acknowledgments
The authors would like to thank Barbara Fraser, Jim Bieda, and Adam The authors would like to thank Barbara Fraser, Jim Bieda, and Adam
Montville for reviewing and contributing to this draft. In addition, Montville for reviewing and contributing to this draft. In addition,
we recognize valuable comments and suggestions made by Jim Schaad and we recognize valuable comments and suggestions made by Jim Schaad and
Chris Inacio. Chris Inacio.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 16, line 10 skipping to change at page 16, line 20
threat and vulnerability reporting and remediation systems. While threat and vulnerability reporting and remediation systems. While
the goal is to facilitate the flow of information securely, it is the goal is to facilitate the flow of information securely, it is
important to note that participating endpoints may not be cooperative important to note that participating endpoints may not be cooperative
or trustworthy. 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 transfer
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.
In the information transport flow, it is possible that some of the In the information transfer flow, it is possible that some of the
devices may serve as proxies or brokers and as such, may be able to devices may serve as proxies or brokers and as such, may be able to
observe the communications flowing between an information provider observe the communications flowing between an information provider
and requestor. Without appropriate protections, it is possible for and requestor. Without appropriate protections, it is possible for
these proxies and brokers to inject and affect man-in-the-middle these proxies and brokers to inject and affect man-in-the-middle
attacks. attacks.
It is common to, in general, distrust the network service provider, It is common to, in general, distrust the network service provider,
unless the full hop by hop communications process flow is well unless the full hop by hop communications process flow is well
understood. As such, the posture information provider should protect understood. As such, the posture information provider should protect
the posture information data it provides as well as the transport it the posture information data it provides as well as the transfer it
uses. Similarly, while there may be providers whose goal is to uses. Similarly, while there may be providers whose goal is to
openly share its information, there may also be providers whose openly share its information, there may also be providers whose
policy is to grant access to certain posture information based on its policy is to grant access to certain posture information based on its
business or regulatory policy. In those situations, a provider may business or regulatory policy. In those situations, a provider may
require full authentication and authorization of the requestor (or require full authentication and authorization of the requestor (or
set of requestors) and share only the authorized information to the set of requestors) and share only the authorized information to the
authenticated and authorized requestors. authenticated and authorized requestors.
A requestor beyond distrusting the network service provider, must A requestor beyond distrusting the network service provider, must
also account that the information received from the provider may have also account that the information received from the provider may have
been communicated through an undetermined network communications been communicated through an undetermined network communications
system. That is, the posture information may have traversed through system. That is, the posture information may have traversed through
many devices before reaching the requestor. SACM specifications many devices before reaching the requestor. SACM specifications
should provide the means for verifying data origin and data integrity should provide the means for verifying data origin and data integrity
and at minimum, provide endpoint authentication and transport and at minimum, provide endpoint authentication and transfer
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 are described untrustworthy information. The considerations for this are described
skipping to change at page 17, line 15 skipping to change at page 17, line 25
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.
o Authentication and authorization of the provider. o Authentication and authorization of the provider.
o Either or both confidentiality and integrity at the transport o Either or both confidentiality and integrity at the transfer
layer. layer.
o Either or both confidentiality and integrity at the data layer. o Either or both confidentiality and integrity at the data layer.
5.2. Privacy Considerations 5.2. Privacy Considerations
SACM information may contain sensitive information about the target SACM information may contain sensitive information about the target
endpoint as well as revealing identity information of the producer or endpoint as well as revealing identity information of the producer or
consumer of such information. Similarly, as part of the SACM consumer of such information. Similarly, as part of the SACM
discovery mechanism, the advertised capabilities (and roles, e.g. discovery mechanism, the advertised capabilities (and roles, e.g.
SACM components enabled) by the endpoint may be construed as private SACM components enabled) by the endpoint may be construed as private
information. information.
In addition to identity and SACM capabilities information disclosure, In addition to identity and SACM capabilities information disclosure,
the use of time stamps or other attributes that can be used as the use of time stamps (or other attributes that can be used as
identifiers especially as they are coupled with an identity can be identifiers) could be further used to determine a target endpoint or
further used to determine a target endpoint or user's behavioral user's behavioral patterns. Such attributes may also be deemed
patterns. Such attributes may also be deemed sensitive and may sensitive and may required further protection or obfuscation to meet
required further protection or obfuscation to meet privacy concerns. privacy concerns. That is, there may be applications as well as
That is, there may be applications as well as business and regulatory business and regulatory practices that require that aspects of such
practices that require that aspects of such information be hidden information be hidden from any parties that do not need to know it.
from any parties that do not need to know it.
Data confidentiality can provide some level of privacy but may fall Data confidentiality can provide some level of privacy but may fall
short where unecessary data is still transmitted. In those cases, short where unnecessary data is still transmitted. In those cases,
filtering requirements at the data model such as OP-005 must be filtering requirements at the data model such as OP-005 must be
applied to ensure that such data is not disclosed. [RFC6973] applied to ensure that such data is not disclosed. [RFC6973]
provides guidelines for which SACM protocols and information and data provides guidelines for which SACM protocols and information and data
models should follow. models should follow.
6. Change Log 6. References
6.1. -05 to -06
Updated G-005 to clarify the MUST to allow non-standard extensions,
SHOULD avoid collisions and ensure interoperability.
Cleaned up and clarified IM-003, DM-001.
Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments.
Updated some of the text around Editor notes and removed all 'Editor 6.1. Normative References
Note' comments
7. References [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.1. Normative References 6.2. Informative References
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
"Security Automation and Continuous Monitoring (SACM) "Security Automation and Continuous Monitoring (SACM)
Terminology", draft-ietf-sacm-terminology-12 (work in Terminology", draft-ietf-sacm-terminology-12 (work in
progress), March 2017. progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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 [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Posture Assessment: Enterprise Use Cases", RFC 7632, Transport Protocol over TLS (PT-TLS)", RFC 6876,
DOI 10.17487/RFC7632, September 2015, DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc7632>. <http://www.rfc-editor.org/info/rfc6876>.
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, Considerations for Internet Protocols", RFC 6973,
DOI 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>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol for Extensible Authentication Protocol (EAP)
Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
<http://www.rfc-editor.org/info/rfc7171>.
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
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Lisa Lorenzin Lisa Lorenzin
 End of changes. 63 change blocks. 
136 lines changed or deleted 137 lines changed or added

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