draft-ietf-sacm-requirements-09.txt   draft-ietf-sacm-requirements-10.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 24, 2016 Pulse Secure Expires: April 3, 2016 Pulse Secure
July 23, 2015 October 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-09 draft-ietf-sacm-requirements-10
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 24, 2016. This Internet-Draft will expire on April 3, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 7 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 8 2.3. Requirements for the Information Model . . . . . . . . . 8
2.4. Requirements for the Data Model . . . . . . . . . . . . . 9 2.4. Requirements for the Data Model . . . . . . . . . . . . . 9
2.5. Requirements for Data Model Operations . . . . . . . . . 12 2.5. Requirements for Data Model Operations . . . . . . . . . 12
2.6. Requirements for SACM Transport Protocols . . . . . . . . 13 2.6. Requirements for SACM Transport Protocols . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. Trust between Provider and Requestor . . . . . . . . . . 15 5.1. Trust between Provider and Requestor . . . . . . . . . . 15
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 16 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Today's environment of rapidly-evolving security threats highlights Today's environment of rapidly-evolving security threats highlights
the need to automate the sharing of such information while protecting the need to automate the sharing of 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
transmit this information. Security threats can be detected in a transmit this information. Security threats can be detected in a
number of ways. SACM's charter focuses on how to collect and share number of ways. SACM's charter focuses on how to collect and share
this information based on use cases that involve posture assessment this information based on use cases that involve posture assessment
of endpoints. of endpoints.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
determine, share, and use this information in a secure, timely, determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture consistent, and automated manner to perform endpoint posture
assessments. assessments.
This document focuses on describing the requirements for facilitating This document focuses on describing the requirements for facilitating
the exchange of posture assessment information in the enterprise, in the exchange of posture assessment information in the enterprise, in
particular, for the use cases as exemplified in particular, for the use cases as exemplified in
[I-D.ietf-sacm-use-cases]. Also, this document uses terminology [I-D.ietf-sacm-use-cases]. Also, this document uses terminology
defined in [I-D.ietf-sacm-terminology]. defined in [I-D.ietf-sacm-terminology].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
When the words appear in lower case, their natural language meaning
is used.
2. Requirements 2. Requirements
This document defines requirements based on the SACM use cases This document defines requirements based on the SACM use cases
defined in [I-D.ietf-sacm-use-cases]. This section describes the defined in [I-D.ietf-sacm-use-cases]. This section describes the
requirements used by SACM to assess and compare candidate data requirements used by SACM to assess and compare candidate data
models, interfaces, and protocols, to suit the SACM architecture. models, interfaces, and protocols, to suit the SACM architecture.
These requirements express characteristics or features that a These requirements express characteristics or features that a
candidate protocol or data model must be capable of offering to candidate protocol or data model must be capable of offering to
ensure security and interoperability. ensure security and interoperability.
skipping to change at page 8, line 33 skipping to change at page 8, line 41
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 Vocabulary: 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 vocabulary should be defined with a clear extensions. The attribute vocabulary should be defined with a clear
mechanism for extensibility to enable future versions of the mechanism for extensibility to enable future versions of the
information model to be interoperably expanded with new attributes. information model to be interoperably expanded with new attributes.
skipping to change at page 10, line 18 skipping to change at page 10, line 27
describe the various assets associated with the endpoint. describe the various assets associated with the endpoint.
Constraints and interfaces might further be defined to resolve or Constraints and interfaces might further be defined to resolve or
tolerate ambiguity in the references (e.g. same IP address used in tolerate ambiguity in the references (e.g. same IP address used in
two separate 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
(updates containing only the changes since the last update) on an (updates containing only the changes since the last update) on an
ongoing basis as new data is generated. ongoing basis as new data is generated.
DM-005 Loose Coupling: The data model SHOULD allow for a loose DM-005 Loose Coupling: The data model SHOULD allow for a loose
coupling between the provider and the consumer, such that the coupling between the provider and the consumer, such that the
consumer can request information without being required to request consumer can request information without being required to request
it from a specific provider, and a provider can publish information it from a specific provider, and a provider can publish information
skipping to change at page 16, line 45 skipping to change at page 17, line 10
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 transport
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
SACM information may contain sensitive information about the target
endpoint as well as revealing identity information of the producer or
consumer of such information. Similarly, as part of the SACM
discovery mechanism, the advertised capabilities (and roles, e.g.
SACM components enabled) by the endpoint may be construed as private
information. There may be applications as well as business and
regulatory practicess 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
short where unecessary data is still transmitted. In those cases,
filtering requirements at the data model such as OP-005 must be
applied to ensure that such data is not disclosed. [RFC6973]
provides guidelines for which SACM protocols and information and data
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.
skipping to change at page 17, line 38 skipping to change at page 18, line 22
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<http://www.rfc-editor.org/info/rfc5209>. <http://www.rfc-editor.org/info/rfc5209>.
7.2. Informative References 7.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Information Models and Data Models", RFC 3444, Morris, J., Hansen, M., and R. Smith, "Privacy
DOI 10.17487/RFC3444, January 2003, Considerations for Internet Protocols", RFC 6973,
<http://www.rfc-editor.org/info/rfc3444>. DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
Authors' Addresses Authors' Addresses
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
US US
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
 End of changes. 12 change blocks. 
15 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/