draft-ietf-sacm-requirements-17.txt   draft-ietf-sacm-requirements-18.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 29, 2017 Pulse Secure Expires: February 2, 2018 Pulse Secure
June 27, 2017 August 1, 2017
Security Automation and Continuous Monitoring (SACM) Requirements Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-17 draft-ietf-sacm-requirements-18
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 transfer protocols. The requirements and scope are based model and transfer protocols. The requirements and scope are based
on the agreed upon use cases ([RFC7632]). on the agreed upon use cases ([RFC7632]).
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 December 29, 2017. This Internet-Draft will expire on February 2, 2018.
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 24 skipping to change at page 2, line 24
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14 2.6. Requirements for SACM Transfer Protocols . . . . . . . . 14
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 and 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. The Secure Automation threats can be detected in a number of ways. The Secure Automation
and Continuous Monitoring (SACM) charter focuses on how to collect and Continuous Monitoring (SACM) charter focuses on how to collect
and share this information based on use cases that involve posture and share this information based on use cases that involve posture
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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 transfers 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 for both
implementations to use their own extensions; either proprietary data standardized and proprietary extensions.
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 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
transfer protocols MUST have extensibility to allow them to transfer protocols MUST have extensibility to allow them to
transfer 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; the retrieval of specific information based on an attributes; the retrieval of specific information based on an
skipping to change at page 5, line 45 skipping to change at page 5, line 43
many rapid or simultaneous events that require processing, many rapid or simultaneous events that require processing,
generating many messages 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
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. 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 Protection: 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 (end to end) and data at rest (as information is stored in
and consumers, and through middle boxes and/or repositories) and repositories). Mechanisms for this protection are unspecified but
data at rest (for information stored on repositories and on should include industry best practices. These mechanisms are
providers / consumers). Mechanisms for this protection are required to be available (i.e. all data-handling components must
unspecified but should include industry best practices. These support them), but are not required to be used in all cases.
mechanisms are required to be available (i.e. all data-handling
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 7, line 37 skipping to change at page 7, line 29
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
can be used to compose an identity for a target endpoint. These can be used to compose an identity for a target endpoint. These
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 MUST represent the Following are the requirements for the SACM architecture:
core components and interfaces needed to perform the production and
consumption of posture assessment information. Requirements relating
to SACM's architecture include:
ARCH-001 Scalability: The architectural components MUST account for ARCH-001 Component functions: At the simplest abstraction, the SACM
architecture MUST represent the core components and interfaces
needed to perform the production and consumption of posture
assessment information.
ARCH-002 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-003 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-004 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 transfer and share posture assessment and protocols used to transfer and share posture assessment
information. information.
ARCH-004 Topology Flexibility: Both centralized and decentralized ARCH-005 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.
However, there may be cases where the producer chooses to include
that information due to consumer preference
ARCH-005 Capability Negotiation: Announcement and negotiation of ARCH-006 Capability Negotiation: Announcement and negotiation of
functional capabilities (such as authentication protocols, functional capabilities (such as authentication protocols,
authorization schemes, data models, transfer 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-007 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-008 Context-based Authorization: The SACM architecture MUST be
capable of effecting context-based authorization. Different capable of effecting context-based authorization. Different
policies (e.g. business, regulatory, etc.) might specify what data policies (e.g. business, regulatory, etc.) might specify what data
may be exposed to, or shared by, consumers based on one or more may be exposed to, or shared by, consumers based on one or more
attributes of the consumer. The policy might specify that consumers attributes of the consumer. The policy might specify that consumers
are required to share specific information either back to the system are required to share specific information either back to the system
or to administrators. or to administrators.
ARCH-008 Time Synchronization: Actions or decisions based on time- ARCH-009 Time Synchronization: Actions or decisions based on time-
sensitive data (such as user logon/logoff, endpoint connection/ sensitive data (such as user logon/logoff, endpoint connection/
disconnection, endpoint behavior events, etc.) are all predicated on disconnection, endpoint behavior events, etc.) are all predicated on
a synchronized understanding of time. The SACM architecture MUST a synchronized understanding of time. The SACM architecture MUST
provide a mechanism for all components to synchronize time. A provide a mechanism for all components to synchronize time. A
mechanism for detecting and reporting time discrepancies SHOULD be mechanism for detecting and reporting time discrepancies SHOULD be
provided by the architecture and reflected in the information model. provided by the architecture and reflected in the information model.
2.3. Requirements for the Information Model 2.3. Requirements for the Information Model
The SACM information model represents the abstracted representation The SACM information model represents the abstracted representation
skipping to change at page 15, line 18 skipping to change at page 15, line 18
provisions such as confirmations and re-transmits). provisions such as confirmations and re-transmits).
T-006 Transfer 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.
T-007 Transfer Protocol adoption: SACM SHOULD where reasonably
possible, leverage and use existing IETF transfer protocols versus
defining new ones.
3. Acknowledgments 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 18, line 21 skipping to change at page 18, line 26
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment: Enterprise Use Cases", RFC 7632, Posture Assessment: Enterprise Use Cases", RFC 7632,
DOI 10.17487/RFC7632, September 2015, DOI 10.17487/RFC7632, September 2015,
<http://www.rfc-editor.org/info/rfc7632>. <http://www.rfc-editor.org/info/rfc7632>.
6.2. Informative 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-13 (work in
progress), March 2017. progress), July 2017.
[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>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture [RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", RFC 6876, Transport Protocol over TLS (PT-TLS)", RFC 6876,
DOI 10.17487/RFC6876, February 2013, DOI 10.17487/RFC6876, February 2013,
<http://www.rfc-editor.org/info/rfc6876>. <http://www.rfc-editor.org/info/rfc6876>.
 End of changes. 20 change blocks. 
33 lines changed or deleted 36 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/