draft-ietf-sacm-requirements-08.txt   draft-ietf-sacm-requirements-09.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: January 22, 2016 Pulse Secure Expires: January 24, 2016 Pulse Secure
July 21, 2015 July 23, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-08 draft-ietf-sacm-requirements-09
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 January 22, 2016. This Internet-Draft will expire on January 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 20 skipping to change at page 2, line 20
2.2. Requirements for the Architecture . . . . . . . . . . . . 7 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 8 2.3. Requirements for the Information Model . . . . . . . . . 8
2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transport Protocols . . . . . . . . 13 2.6. Requirements for SACM Transport Protocols . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Trust between Provider and Requestor . . . . . . . . . . 15 5.1. Trust between Provider and Requestor . . . . . . . . . . 15
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Today's environment of rapidly-evolving security threats highlights Today's environment of rapidly-evolving security threats highlights
the need to automate the sharing of such information while protecting the need to automate the sharing of such information while protecting
user information as well as the systems that store, process, and user information as well as the systems that store, process, and
skipping to change at page 5, line 35 skipping to change at page 5, line 35
constrained environments. constrained environments.
G-005 Information Extensibility: Non-standard (implementation- G-005 Information Extensibility: Non-standard (implementation-
specific) attributes MUST be supported. A method SHOULD be defined specific) attributes MUST be supported. A method SHOULD be defined
for preventing collisions from occurring in the naming of all for preventing collisions from occurring in the naming of all
attributes independent of their source. For interoperability and attributes independent of their source. For interoperability and
scope boundary, the information model MUST define the mandatory set scope boundary, the information model MUST define the mandatory set
of attributes. The set of attributes defined by the information of attributes. The set of attributes defined by the information
model MUST be well defined. model MUST be well defined.
G-006 Data Integrity: A method for ensuring data integrity MUST be G-006 Data Integrity: To protect the information being shared, SACM
provided. This method is required to be available (i.e. all data- components MUST protect the integrity and confidentiality of data in
handling components must support it), but is not required to be used transit (while information is being transferred between providers
in all cases. and consumers, and through proxies and/or repositories) and data at
rest (for information stored on repositories and on providers /
consumers). Mechanisms for this protection are unspecified but
should include industry best practices such as encrypted storage,
encrypted transports, data checksums, etc. These 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 42 skipping to change at page 7, line 48
(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 Modularity: Announcement and negotiation of functional ARCH-005 Capability Negotiation: Announcement and negotiation of
capabilities (such as authentication protocols, authorization functional capabilities (such as authentication protocols,
schemes, data models, transport protocols, etc.) must be supported, authorization schemes, data models, transport protocols, etc.) must
enabling a SACM component to make inquiries about the capabilities be supported, enabling a SACM component to make inquiries about the
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
policies (e.g. business, regulatory, etc.) may specify what data may policies (e.g. business, regulatory, etc.) might specify what data
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 may 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-008 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
for Posture Assessment information to be communicated. SACM data for Posture Assessment information to be communicated. SACM data
models must adhere to and comply with the SACM information model. models must adhere to and comply with the SACM information model.
The requirements for the SACM information model include: The requirements for the SACM information model include:
IM-001 Extensible Attribute Dictionary: the information model MUST IM-001 Extensible Attribute Vocabulary: the information model MUST
define a minimum set of attributes for communicating Posture define a minimum set of attributes for communicating Posture
Information, to ensure interoperability between data models. Information, to ensure interoperability between data models.
(Individual data models may define attributes beyond the mandatory- (Individual data models may define attributes beyond the mandatory-
to-implement minimum set.) The attributes should be defined with a to-implement minimum set.) The attributes should be defined with a
clear mechanism for extensibility to enable data models to adhere to clear mechanism for extensibility to enable data models to adhere to
SACM's required attributes as well as allow for their own SACM's required attributes as well as allow for their own
extensions. The attribute dictionary should be defined with a clear extensions. The attribute vocabulary should be defined with a clear
mechanism for extensibility to enable future versions of the mechanism for extensibility to enable future versions of the
information model to be interoperably expanded with new attributes. information model to be interoperably expanded with new attributes.
IM-002 Posture Data Publication: The information model MUST allow IM-002 Posture Data Publication: The information model MUST allow
for the data to be provided by a SACM component either solicited or for the data to be provided by a SACM component either solicited or
unsolicited. No aspect of the information model should be dependent unsolicited. No aspect of the information model should be dependent
upon or assume a push (unsolicited) or pull (solicited) model of upon or assume a push (unsolicited) or pull (solicited) model of
publication. publication.
IM-003 Data Model Negotiation: SACM's information model MUST allow IM-003 Data Model Negotiation: SACM's information model MUST allow
skipping to change at page 9, line 49 skipping to change at page 10, line 6
DM-001 Element Association: The data model MUST contain a data model DM-001 Element Association: The data model MUST contain a data model
element for each information model element (e.g. endpoint, IP element for each information model element (e.g. endpoint, IP
address, asset). In other words, for every item in the information address, asset). In other words, for every item in the information
model, there must be an item in the data model. The data model can model, there must be an item in the data model. The data model can
also include elements that do not exist in the information model. also include elements that do not exist in the information model.
DM-002 Data Model Structure: The data model can be structured either DM-002 Data Model Structure: The data model can be structured either
as one single module or separated into modules and sub-modules that as one single module or separated into modules and sub-modules that
allow for references between them. The data model structure MAY allow for references between them. The data model structure MAY
reflect structure in the information model, but does not need to. reflect structure in the information model, but does not need to.
For example, the data model may use one module to define endpoints, For example, the data model might use one module to define
and that module will reference other modules that describe the endpoints, and that module might reference other modules that
various assets associated with the endpoint. Constraints and describe the various assets associated with the endpoint.
interfaces may further be defined to resolve or tolerate ambiguity Constraints and interfaces might further be defined to resolve or
in the references (e.g. same IP address used in two separate tolerate ambiguity in the references (e.g. same IP address used in
networks). two separate networks).
DM-003 Search Flexibility: The search interfaces and actions MUST DM-003 Search Flexibility: The search interfaces and actions MUST
include the ability to start a search anywhere within a data model include the ability to start a search anywhere within a data model
structure, and the ability to search based on patterns ("wildcard structure, and the ability to search based on patterns ("wildcard
searches") as well as specific data elements. searches") as well as specific data elements.
DM-004 Full Vs. Partial Updates: The data model SHOULD include the DM-004 Full Vs. Partial Updates: The data model SHOULD include the
ability to allow providers of data to provide the data as a whole, ability to allow providers of data to provide the data as a whole,
or when updates occur. For example, a consumer can request a full or when updates occur. For example, a consumer can request a full
update on initial engagement, then request to receive deltas update on initial engagement, then request to receive deltas
skipping to change at page 13, line 30 skipping to change at page 13, line 30
OP-007 Data Abstraction: The data model MUST allow a SACM component OP-007 Data Abstraction: The data model MUST allow a SACM component
to communicate what data was used to construct the target endpoint's to communicate what data was used to construct the target endpoint's
identity, so other SACM components can determine whether they are identity, so other SACM components can determine whether they are
constructing an equivalent target endpoint (and their identity) and constructing an equivalent target endpoint (and their identity) and
whether they have confidence in that identity. SACM components whether they have confidence in that identity. SACM components
SHOULD have interfaces defined to transmit this data directly or to SHOULD have interfaces defined to transmit this data directly or to
refer to where the information can be retrieved. refer to where the information can be retrieved.
2.6. Requirements for SACM Transport Protocols 2.6. Requirements for SACM Transport Protocols
The term transport protocol is frequently overloaded. The term SACM
transport protocol is intended to be distinguished from underlying
layer 3 and 4 protocols such as TCP/IP and TLS. However, it is
possible that a layer 3 or 4 protocol may be used as a SACM transport
protocol, either alone or as part of a SACM transport protocol (i.e.
using HTTP over TLS with XML as the content). The SACM transport
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 transport protocols
MUST support different network transport protocols in a deployment MUST support different network transport protocols in a deployment
to support different transport layer requirements, different device to support different transport layer requirements, different device
capabilities, and system configurations dealing with connectivity. capabilities, and system configurations dealing with connectivity.
T-002 Data Integrity: SACM transport protocols MUST be able to T-002 Data Integrity: SACM transport protocols MUST be able to
ensure data integrity for data in transit. ensure data integrity for data in transit.
T-003 Data Confidentiality: SACM transport protocols MUST be able to T-003 Data Confidentiality: SACM transport protocols MUST be able to
support data confidentiality. SACM transport protocols SHOULD support data confidentiality. SACM transport protocols MUST ensure
ensure data protection for data in transit by encryption to provide data protection for data in transit (e.g. by encryption) to provide
confidentiality, integrity, and robustness against protocol-based confidentiality, integrity, and robustness against protocol-based
attacks. Note that while the transport MUST be able to support data attacks. Note that while the transport MUST be able to support data
confidentiality, implementations MAY choose to make confidentiality confidentiality, implementations MAY choose to make confidentiality
optional. Protection for data at rest is not in scope for transport optional. Protection for data at rest is not in scope for transport
protocols. Data protection MAY be used for both privacy and non- protocols. Data protection MAY be used for both privacy and non-
privacy scenarios. privacy scenarios.
T-004 Transport Protection: SACM transport protocols MUST be capable T-004 Transport Protection: SACM transport protocols MUST be capable
of supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
skipping to change at page 15, line 15 skipping to change at page 15, line 24
controllers / brokers / data repositories. controllers / brokers / data repositories.
In addition, authorization needs to extend to specific information or In addition, authorization needs to extend to specific information or
resources available in the environment. In other words, resources available in the environment. In other words,
authorization is based on the subject (the information requestor), authorization is based on the subject (the information requestor),
the provider (the information responder), the object (the endpoint the provider (the information responder), the object (the endpoint
the information is being requested on), and the attribute (what piece the information is being requested on), and the attribute (what piece
of data is being requested). The method by which this authorization of data is being requested). The method by which this authorization
is applied is unspecified. is applied is unspecified.
To protect the information being shared, SACM components MUST protect
the integrity and confidentiality of data in transit (while
information is being transferred between providers and consumers, and
through proxies and/or repositories) and data at rest (for
information stored on repositories and on providers / consumers).
Mechanisms for this protection are unspecified but should include
industry best practices such as encrypted storage, encrypted
transports, data checksums, etc.
SACM's charter focuses on the sharing of posture information for SACM's charter focuses on the sharing of posture information for
improving efficacy of security applications such as compliance, improving efficacy of security applications such as compliance,
configuration, assurance and other threat and vulnerability reporting configuration, assurance and other threat and vulnerability reporting
and remediation systems. While the goal is to facilitate the flow of and remediation systems. While the goal is to facilitate the flow of
information securely, it is important to note that participating information securely, it is important to note that participating
endpoints may not be cooperative or trustworthy. endpoints may not be cooperative or trustworthy.
5.1. Trust between Provider and Requestor 5.1. Trust between Provider and Requestor
The information given from the provider to a requestor may come with The information given from the provider to a requestor may come with
skipping to change at page 17, line 31 skipping to change at page 17, line 27
Birkholz, H., "Secure Automation and Continuous Monitoring Birkholz, H., "Secure Automation and Continuous Monitoring
(SACM) Terminology", draft-ietf-sacm-terminology-07 (work (SACM) Terminology", draft-ietf-sacm-terminology-07 (work
in progress), July 2015. in progress), July 2015.
[I-D.ietf-sacm-use-cases] [I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf- Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-10 (work in progress), July 2015. sacm-use-cases-10 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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>.
7.2. Informative References 7.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
 End of changes. 14 change blocks. 
37 lines changed or deleted 45 lines changed or added

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