draft-ietf-sacm-requirements-07.txt   draft-ietf-sacm-requirements-08.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 8, 2016 Pulse Secure Expires: January 22, 2016 Pulse Secure
July 7, 2015 July 21, 2015
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-07 draft-ietf-sacm-requirements-08
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 8, 2016. This Internet-Draft will expire on January 22, 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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.
SACM defines an architecture and information model focused on SACM defines an architecture and information model focused on
addressing the needs for determining, sharing, and using posture addressing the needs for determining, sharing, and using posture
information via Posture Information Providers and Posture Information information via Posture Information Providers and Posture Information
Consumers mediated by a Controller. With the information model Consumers mediated by a Controller. With the information model
defining assets and attributes to facilitate the guidance, defining assets and attributes to facilitate the guidance,
collection, and assessment of posture, the following tasks should be collection, and assessment of posture, these are some of the tasks
considered: that should be considered:
1. Asset Definition: Define the attributes desired to be collected 1. Asset Classification: Map the assets on the target endpoints to
from an asset. This is what we want to know about an asset. For asset classes. This enables identification of the attributes
instance, organizations will want to know what software is needed to exchange information pertaining to the target endpoint.
installed and its many critical security attributes such as patch
level.
2. Asset Classification: Map the asset to an endpoint class. This 2. Attribute Definition: Define the attributes desired to be
requires populating the attributes needed to exchange information collected from each target endpoint. This is what we want to
pertaining to the assets composing an endpoint. know about a target endpoint. For instance, organizations will
want to know what software is installed and its many critical
security 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 asset policy for acceptable or problematic values of an endpoint
attribute. The expected values of an asset attribute are attribute. The expected values of an endpoint attribute are
determined for later comparison against the actual asset 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 asset attributes that are to be organization can also specify the endpoint attributes that are to
present for a given asset. be present for a given target endpoint.
4. Information Collection: Collect information (attribute values) 4. Information Collection: Collect information (attribute values)
from the endpoint to populate the asset data. from the target endpoint to populate the endpoint data.
5. Endpoint Assessment: Evaluate the actual values of the asset data 5. Endpoint Assessment: Evaluate the actual values of the endpoint
against those expressed in the policy. (An evaluation result may attributes against those expressed in the policy. (An evaluation
become additional asset data). result may become additional endpoint data).
6. Result Reporting: Report the results of the evaluation for use by 6. Result Reporting: Report the results of the evaluation for use by
other components. Examples of use of a report would be other components. Examples of use of a report would be
additional evaluation, network enforcement, vulnerability additional evaluation, network enforcement, vulnerability
detection, and license management. detection, and license management.
7. Access Control Policy: Classes of entities and access control
policies are assigned to generic attributes as well as attributes
for specific endpoints.
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 [I-D.ietf-sacm-use-cases]. To ensure tasks and use cases defined in [I-D.ietf-sacm-use-cases]. 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 transports defined by SACM MUST be designed to allow protocols, and transports defined by SACM MUST be designed to allow
skipping to change at page 8, line 18 skipping to change at page 8, line 13
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.) may specify what data may
be exposed to, or shared by, consumers based on one or more 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 may 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.
IM-006 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
skipping to change at page 9, line 45 skipping to change at page 9, line 39
shared. It is expected that as applications may produce posture shared. It is expected that as applications may produce posture
assessment information, they may share it using a specific data assessment information, they may share it using a specific data
model. Similarly, applications consuming or requesting posture model. Similarly, applications consuming or requesting posture
assessment information, may require it be based on a specific data assessment information, may require it be based on a specific data
model. Thus, while there may exist different data models and model. Thus, while there may exist different data models and
schemas, they should adhere to the SACM information model and meet schemas, they should adhere to the SACM information model and meet
the requirements defined in this section. the requirements defined in this section.
The specific requirements for candidate data models include: The specific requirements for candidate data models include:
DM-001 Unique Association: The data model MUST associate each data DM-001 Element Association: The data model MUST contain a data model
object with exactly one information model element (e.g. endpoint, IP element for each information model element (e.g. endpoint, IP
address, asset). 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
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 may use one module to define endpoints,
and that module will reference other modules that describe the and that module will reference other modules that describe the
various assets associated with the endpoint. Constraints and various assets associated with the endpoint. Constraints and
interfaces may further be defined to resolve or tolerate ambiguity interfaces may further be defined to resolve or tolerate ambiguity
in the references (e.g. same IP address used in two separate in the references (e.g. same IP address used in two separate
networks). 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
skipping to change at page 13, line 28 skipping to change at page 13, line 28
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.
2.6. Requirements for Transport Protocols 2.6. Requirements for SACM Transport Protocols
The requirements for SACM transport protocols include: The requirements for SACM transport protocols include:
T-001 Multiple Transport Protocol Support: Different transport T-001 Multiple Transport Protocol Support: SACM transport protocols
protocols MUST be supported in a deployment to support different MUST support different network transport protocols in a deployment
transport layer requirements, different device capabilities, and to support different transport layer requirements, different device
system configurations dealing with connectivity. capabilities, and system configurations dealing with connectivity.
T-002 Data Integrity: transport protocols MUST be able to ensure T-002 Data Integrity: SACM transport protocols MUST be able to
data integrity for data in transit. ensure data integrity for data in transit.
T-003 Data Confidentiality: 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 SHOULD
ensure data protection for data in transit by encryption to provide ensure data protection for data in transit 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: transport protocols MUST be capable of T-004 Transport Protection: SACM transport protocols MUST be capable
supporting mutual authentication and replay protection. of supporting mutual authentication and replay protection.
T-005 Transport Reliability: transport protocols MUST provide T-005 Transport Reliability: SACM transport 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. fragmentation and reassembly, and to detect replays.
T-006 Transport Layer Requirements: Each transport protocol MUST T-006 Transport Layer Requirements: Each SACM transport protocol
clearly specify the transport layer requirements it needs to operate MUST clearly specify the transport layer requirements it needs to
correctly. Examples of items that may need to be specified include operate correctly. Examples of items that may need to be specified
connectivity requirements, replay requirements, data link encryption include connectivity requirements, replay requirements, data link
requirements, and/or channel binding requirements. These encryption 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. For example, a proxy server between UDP and TCP can
provide a connection that correctly fulfills the connectivity and provide a connection that correctly fulfills the connectivity and
replay requirements as well as data link requirements (through the replay requirements as well as data link requirements (through the
use of TLS and DTLS) but would be unable to provide a channel 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 binding requirement, as that implies there is no MITM to look at the
data. data.
3. Acknowledgements 3. Acknowledgements
skipping to change at page 17, line 21 skipping to change at page 17, line 21
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
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]
Waltermire, D., Montville, A., Harrington, D., Cam-Winget, Birkholz, H., "Secure Automation and Continuous Monitoring
N., Lu, J., Ford, B., and M. Kaeo, "Terminology for (SACM) Terminology", draft-ietf-sacm-terminology-07 (work
Security Assessment", draft-ietf-sacm-terminology-06 (work in progress), July 2015.
in progress), February 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, March 1997.
[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, June 2008. Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<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, January Information Models and Data Models", RFC 3444,
2003. DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
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. 25 change blocks. 
56 lines changed or deleted 54 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/