draft-ietf-sacm-requirements-14.txt   draft-ietf-sacm-requirements-15.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: March 22, 2017 Pulse Secure Expires: June 30, 2017 Pulse Secure
September 18, 2016 December 27, 2016
Security Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-14 draft-ietf-sacm-requirements-15
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 March 22, 2017. This Internet-Draft will expire on June 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . 14 2.6. Requirements for SACM Transport Protocols . . . . . . . . 14
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 as well as 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. SACM's charter focuses
on how to collect and share this information based on use cases that on how to collect and share this information based on use cases that
involve posture assessment of endpoints. involve posture assessment of endpoints.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 [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, to suit the SACM architecture. These requirements express
characteristics or features that a candidate protocol, information characteristics or features that a candidate protocol, information
model, or data model must be capable of offering to ensure security model, or data model must be 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 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.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
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 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. This is what we want to collected from each target endpoint. For instance, organizations
know about a target endpoint. For instance, organizations will will want to know what software is installed and its 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 5, line 40 skipping to change at page 5, line 40
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
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. Separate solutions may be necessary to
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 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 middle boxes and/or repositories) and
rest (for information stored on repositories and on providers / data at rest (for information stored on repositories and on
consumers). Mechanisms for this protection are unspecified but providers / consumers). Mechanisms for this protection are
should include industry best practices such as encrypted storage, unspecified but should include industry best practices such as
encrypted transports, data checksums, etc. These mechanisms are encrypted storage, encrypted transports, data checksums, etc. These
required to be available (i.e. all data-handling components must mechanisms are required to be available (i.e. all data-handling
support them), but are not required to be used in all cases. components must support them), but are not required to be used in
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
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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 Transport Protocols
The term transport protocol is frequently overloaded. The term SACM The term SACM transfer protocol is intended to be distinguished from
transport protocol is intended to be distinguished from underlying underlying layer 3 and 4 protocols such as TCP/IP, operating at an
layer 3 and 4 protocols such as TCP/IP and TLS. However, it is equivalent level as the hyperText transfer protocol (HTTP). The SACM
possible that a layer 3 or 4 protocol may be used as a SACM transport transfer protocol is focused on moving data and performing necessary
protocol, either alone or as part of a SACM transport protocol (i.e. access control operations; it is agnostic to the data model
using HTTP over TLS with XML as the content). The SACM transport operations.
protocol is focused on moving data and performing necessary access
control operations; it is agnostic to the data model operations.
The requirements for SACM transport protocols include: The requirements for SACM transport protocols include:
T-001 Multiple Transport Protocol Support: SACM transport protocols T-001 Multiple Transport Protocol Support: SACM transfer protocols
MUST support different network transport protocols in a deployment will vary depending on the deployment model that relies on different
to support different transport layer requirements, different device transport layer requirements, different device capabilities, and
capabilities, and system configurations dealing with connectivity. system configurations dealing with connectivity.
T-002 Data Integrity: SACM transport protocols MUST be able to T-002 Data Integrity: SACM transfer protocols MUST be able to ensure
ensure data integrity for data in transit. data integrity for data in transit.
T-003 Data Confidentiality: SACM transport 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 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 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 transport 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 transport protocols MUST be capable T-004 Transport 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 transport protocols MUST provide T-005 Transport 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
transport 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 transport 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 transport protocol T-006 Transport Layer Requirements: Each SACM transfer protocol MUST
MUST clearly specify the transport layer requirements it needs to clearly specify the transport layer requirements it needs to operate
operate correctly. Examples of items that may need to be specified correctly. Examples of items that may need to be specified include
include connectivity requirements, replay requirements, data link connectivity requirements, replay requirements, data link encryption
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. For example, a proxy server between UDP and TCP can correctly.
provide a connection that correctly fulfills the connectivity and
replay requirements as well as data link requirements (through the
use of TLS and DTLS) but would be unable to provide a channel
binding requirement, as that implies there is no MITM to look at the
data.
3. Acknowledgements 3. Acknowledgements
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.
5. Security Considerations 5. Security Considerations
This document defines the requirements for SACM. As such, it is This document defines the requirements for SACM. As such, it is
expected that several data models, protocols, and transports may be expected that several data models, protocols, and transfer protocols
defined or reused from already existing standards. This section will may be defined or reused from already existing standards.
highlight security considerations that may apply to SACM based on the
architecture and standards applied in SACM. In particular,
highlights to security considerations that may apply to the SACM
reference architecture and standard data models and transports will
be discussed.
To address security and privacy considerations, the data model, To address security and privacy considerations, the data model,
protocols, and transports must consider authorization based on protocols, and transports must consider authorization based on
consumer function and privileges, to only allow authorized consumers consumer function and privileges, to only allow authorized consumers
and providers to access specific information being requested or and providers to access specific information being requested or
published. published.
To enable federation across multiple entities (such as across To enable federation across multiple entities (such as across
organizational or geographic boundaries) authorization must also organizational or geographic boundaries) authorization must also
extend to infrastructure elements themselves, such as central extend to infrastructure elements themselves, such as central
skipping to change at page 17, line 37 skipping to change at page 17, line 27
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. There may be applications as well as business and information.
regulatory practicess that require that aspects of such information
be hidden from any parties that do not need to know it. In addition to identity and SACM capabilities information disclosure,
the use of time stamps or other attributes that can be used as
identifiers especially as they are coupled with an identity can be
further used to determine a target endpoint or user's behavioral
patterns. Such attributes may also be deemed sensitive and may
required further protection or obfuscation to meet privacy concerns.
That is, there may be applications as well as business and regulatory
practices that require that aspects of such information be hidden
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 unecessary 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. Change Log
6.1. -05 to -06 6.1. -05 to -06
Updated G-005 to clarify the MUST to allow non-standard extensions, Updated G-005 to clarify the MUST to allow non-standard extensions,
SHOULD avoid collisions and ensure interoperability. SHOULD avoid collisions and ensure interoperability.
Cleaned up and clarified IM-003, DM-001. Cleaned up and clarified IM-003, DM-001.
Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments. 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 Updated some of the text around Editor notes and removed all 'Editor
 End of changes. 21 change blocks. 
58 lines changed or deleted 56 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/