draft-ietf-sacm-requirements-10.txt   draft-ietf-sacm-requirements-11.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: April 3, 2016 Pulse Secure Expires: May 6, 2016 Pulse Secure
October 2015 November 3, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-10 draft-ietf-sacm-requirements-11
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 April 3, 2016. This Internet-Draft will expire on May 6, 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 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 4
2.2. Requirements for the Architecture . . . . . . . . . . . . 7 2.2. Requirements for the Architecture . . . . . . . . . . . . 7
2.3. Requirements for the Information Model . . . . . . . . . 8 2.3. Requirements for the Information Model . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. Trust between Provider and Requestor . . . . . . . . . . 15 5.1. Trust between Provider and Requestor . . . . . . . . . . 15
5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5.2. Privacy Considerations . . . . . . . . . . . . . . . . . 17
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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
without having a specific consumer targeted to receive it. without having a specific consumer targeted to receive it.
DM-006 Provider Identification: The interfaces and actions in the DM-006 Data Cardinality: The data model MUST describe their
data model MUST include the ability to identify data from a specific
provider. For example, a SACM consumer should be able to request
all data to come from a specific provider (e.g. Provider A) as
there can be a larger set of providers.
DM-007 Data Cardinality: The data model MUST describe their
constraints (e.g. cardinality). As posture information and the constraints (e.g. cardinality). As posture information and the
tasks for collection, aggregation, or evaluation, could comprise one tasks for collection, aggregation, or evaluation, could comprise one
or more attributes, interfaces and actions MUST allow and account or more attributes, interfaces and actions MUST allow and account
for such cardinality as well as whether the attributes are for such cardinality as well as whether the attributes are
conditional, optional, or mandatory. conditional, optional, or mandatory.
DM-008 Data Model Negotiation: The interfaces and actions in the DM-007 Data Model Negotiation: The interfaces and actions in the
data model MUST include capability negotiation to enable discovery data model MUST include capability negotiation to enable discovery
of supported and available data types and schemas. of supported and available data types and schemas.
DM-009 Data Origin: The data model MUST include the ability for DM-008 Data Origin: The data model MUST include the ability for
consumers to identify the data origin (provider that collected the consumers to identify the data origin (provider that collected the
data). data).
DM-010 Origination Time: The data model SHOULD allow the provider to DM-009 Origination Time: The data model SHOULD allow the provider to
include the information's origination time. include the information's origination time.
DM-011 Data Generation: The data model MUST allow the provider to DM-010 Data Generation: The data model MUST allow the provider to
include attributes defining how the data was generated (e.g. self- include attributes defining how the data was generated (e.g. self-
reported, reported by aggregator, scan result, etc.). reported, reported by aggregator, scan result, etc.).
DM-012 Data Source: The data model MUST allow the provider to DM-011 Data Source: The data model MUST allow the provider to
include attributes defining the data source (target endpoint from include attributes defining the data source (target endpoint from
which the data was collected) - e.g. hostname, domain (DNS) name or which the data was collected) - e.g. hostname, domain (DNS) name or
application name. application name.
DM-013 Data Updates: The data model SHOULD allow the provider to DM-012 Data Updates: The data model SHOULD allow the provider to
include attributes defining whether the information provided is a include attributes defining whether the information provided is a
delta, partial, or full set of information. delta, partial, or full set of information.
DM-014 Multiple Collectors: The data model MUST support the DM-013 Multiple Collectors: The data model MUST support the
collection of attributes by a variety of collectors, including collection of attributes by a variety of collectors, including
internal collectors, external collectors with an authenticated internal collectors, external collectors with an authenticated
relationship with the endpoint, and external collectors based on relationship with the endpoint, and external collectors based on
network and other observers. network and other observers.
DM-015 Attribute Extensibility: Use Cases in the whole of Section 2 DM-014 Attribute Extensibility: Use Cases in the whole of Section 2
describe the need for an attribute dictionary. With SACM's scope describe the need for an attribute dictionary. With SACM's scope
focused on posture assessment, the data model attribute collection focused on posture assessment, the data model attribute collection
and aggregation MUST have a well-understood set of attributes and aggregation MUST have a well-understood set of attributes
inclusive of their meaning or usage intent. The data model MUST inclusive of their meaning or usage intent. The data model MUST
include all attributes defined in the information model and MAY include all attributes defined in the information model and MAY
include additional attributes beyond those found in the information include additional attributes beyond those found in the information
model. Additional attributes MUST be defined in accordance with the model. Additional attributes MUST be defined in accordance with the
extensibility framework provided in the information model. extensibility framework provided in the information model.
DM-016 Solicited vs. Unsolicited Updates: The data model MUST enable DM-015 Solicited vs. Unsolicited Updates: The data model MUST enable
a provider to publish data either solicited (in response to a a provider to publish data either solicited (in response to a
request from a consumer) or unsolicited (as new data is generated, request from a consumer) or unsolicited (as new data is generated,
without a request required). For example, an external collector can without a request required). For example, an external collector can
publish data in response to a request by a consumer for information publish data in response to a request by a consumer for information
about an endpoint, or can publish data as it observes new about an endpoint, or can publish data as it observes new
information about an endpoint, without any specific consumer request information about an endpoint, without any specific consumer request
triggering the publication; a compliance-server provider may publish triggering the publication; a compliance-server provider may publish
endpoint posture information in response to a request from a endpoint posture information in response to a request from a
consumer (solicited), or it may publish posture information driven consumer (solicited), or it may publish posture information driven
by a change in the posture of the endpoint (unsolicited). by a change in the posture of the endpoint (unsolicited).
DM-017 Transport Agnostic: The data model MUST be transport DM-016 Transport Agnostic: The data model MUST be transport
agnostic, to allow for the data operations to leverage the most agnostic, to allow for the data operations to leverage the most
appropriate SACM transport protocol. appropriate SACM transport protocol.
2.5. Requirements for Data Model Operations 2.5. Requirements for Data Model Operations
Posture information data adhering to a data model must also provide Posture information data adhering to a data model must also provide
interfaces that include operations for access and production of the interfaces that include operations for access and production of the
data. Operations requirements are distinct from transport data. Operations requirements are distinct from transport
requirements in that operations requirements are requirements on the requirements in that operations requirements are requirements on the
application performing requests and responses, whereas transport application performing requests and responses, whereas transport
skipping to change at page 13, line 34 skipping to change at page 13, line 30
large set of targets. large set of targets.
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.
OP-008 Provider Restriction: Request operations MUST include the
ability to restrict the data to be provided by a specific provider
or a provider with specific characteristics. Response operations
MUST include the ability to identify the provider that supplied the
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.
Provider A) or from a Provider that is in a specific location (e.g.
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 transport protocol is frequently overloaded. The term SACM
transport protocol is intended to be distinguished from underlying transport protocol is intended to be distinguished from underlying
layer 3 and 4 protocols such as TCP/IP and TLS. However, it is 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 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. 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 using HTTP over TLS with XML as the content). The SACM transport
protocol is focused on moving data and performing necessary access protocol is focused on moving data and performing necessary access
control operations; it is agnostic to the data model operations. control operations; it is agnostic to the data model operations.
skipping to change at page 17, line 48 skipping to change at page 17, line 50
Updated some of the text around Editor notes and removed all 'Editor Updated some of the text around Editor notes and removed all 'Editor
Note' comments Note' comments
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
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-08 (work
in progress), July 2015. in progress), October 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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, 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
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973, DOI
DOI 10.17487/RFC6973, July 2013, 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <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
 End of changes. 19 change blocks. 
28 lines changed or deleted 31 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/