draft-ietf-sacm-requirements-00.txt   draft-ietf-sacm-requirements-01.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: March 12, 2015 Juniper Networks Expires: April 13, 2015 Pulse Secure
September 8, 2014 October 10, 2014
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-00 draft-ietf-sacm-requirements-01
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 working group. The Secure Automation and Continuous Monitoring working group. The
requirements and scope are based on the agreed upon use cases. requirements and scope are based on the agreed upon use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 March 12, 2015. This Internet-Draft will expire on April 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. General SACM requirements . . . . . . . . . . . . . . . . 2 2.1. Requirements for SACM . . . . . . . . . . . . . . . . . . 3
2.2. Requirements based on Use Cases . . . . . . . . . . . . . 5 2.2. Requirements based on Use Cases . . . . . . . . . . . . . 5
2.3. Requirements for the Information Model . . . . . . . . . 6 2.3. Requirements for the Architecture . . . . . . . . . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Requirements for the Information Model . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 2.5. Requirements for Transport Protocols . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Today's challenges of evolving threats and improved analytics Today's environment of rapidly-evolving security threats highlights
highlight a need to automate the securing of both information and the the need to automate the sharing of such information while protecting
systems that store, process and transmit the information that can and user information as well as the systems that store, process, and
is being leveraged to improve on both threats and analytics to detect transmit this information. Security threats can be detected in a
such threats. SACM's charter focuses on addressing some of these number of ways. SACM's charter focuses on how to collect and share
challenges in a narrower scope by bounding the task to address use this information based on use cases that involve posture assessment
cases that pertain to the posture assessment of endpoints. of endpoints.
Scalable and sustainable collection, expression, and evaluation of
endpoint information is foundational to SACM's objectives. To secure
and defend a network one must reliably determine what devices are on
the network, how those devices are configured from a hardware
perspective, what software products are installed on those devices,
and how those products are configured. We need to be able to
determine, share, and use this information in a secure, timely,
consistent, and automated manner to perform endpoint posture
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 particular, for the exchange of posture assessment information, in particular, for
the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this the use cases as exemplified in [I-D.ietf-sacm-use-cases].Also, this
document uses terminology defined in [I-D.ietf-sacm-terminology]. document uses terminology defined in [I-D.ietf-sacm-terminology].
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 information requirements used by SACM to assess and compare candidate information
models and protocols to suit the architecture. These requirements models and protocols to suit the architecture. These requirements
express characteristics or features that a candidate protocol or data express characteristics or features that a candidate protocol or data
model must be capable of offering so as to ensure security and model must be capable of offering to ensure security and
interoperability. interoperability.
2.1. General SACM requirements 2.1. Requirements for SACM
The use cases defined in [I-D.ietf-sacm-use-cases] apply to many In order to address the needs for determining, sharing and using
deployment scenarios. To ensure interoperability, scalability and posture information, the following tasks should be considered:
flexibility in any of these deployments, the following requirements
are defined for all use cases:
G-001 Extensibility: the data models, protocols and transports 1. Define the assets. This is what we want to know about an asset.
For instance, organizations will want to know what software is
installed and its many critical security attributes such as patch
level.
2. Resolve what assets actually compose an endpoint. This requires
populating the data elements and attributes needed to exchange
information pertaining to the assets composing an endpoint.
3. Determine the expected values for the data elements and
attributes that need to be evaluated against the actual collected
instances of asset data. This is how an organization can express
its policy for an acceptable data element or attribute value. A
system administrator can also identify specific data elements and
attributes that represent problems, such as vulnerabilities, that
need to be detected on an endpoint.
4. Evaluate the collected instances of the asset data against those
expressed in the policy.
5. Report the results of the evaluation.
Many deployment scenarios can be instantiated to address the above
tasks and use cases defined in [I-D.ietf-sacm-use-cases]. To ensure
interoperability, scalability and flexibility in any of these
deployments, the following requirements are defined for all use
cases:
G-001 Extensibility: The data models, protocols and transports
defined by SACM must be extensible to allow support for non-standard defined by SACM must be extensible to allow support for non-standard
and future extensions. The transport protocol must support easily and future extensions. The transport protocol must support easily
adding new operations while maintaining backwards compatibility. adding new operations while maintaining backwards compatibility.
The query language must allow general inquiries as well as The query language must allow general inquiries as well as
expression of specific paths to follow; retrieval of specific expression of specific paths to follow; retrieval of specific
information based on an event, as well as on a continuous basis; and information based on an event, as well as on a continuous basis; and
the ability to retrieve specific pieces of information, specific the ability to retrieve specific pieces of information, specific
classes of information, and/or the entirety of available classes of information, and/or the entirety of available
information. The information model must accommodate the addition of information. The information model must accommodate the addition of
new data types and/or schemas in a backwards compatible fashion. new data types and/or schemas in a backwards compatible fashion.
G-002 Interoperability: The data models, protocols and transports G-002 Interoperability: The data models, protocols and transports
must be specified with enough details and state machine to ensure must be specified with enough details and state machine to ensure
interoperability. interoperability.
G-003 Scalability: The data models, protocols and transports must be G-003 Scalability: The data models, protocols and transports must be
scalable. SACM must support a broad set of deployment scenarios. scalable. SACM must support a broad set of deployment scenarios.
As such, it is possible that the size or posture assessment As such, it is possible that the size of posture assessment
information can vary from a single assessment that is small in information can vary from a single assessment that is small in
(record or datagram) size to a very large datagram or a very large (record or datagram) size to a very large datagram or a very large
set of assessments and must be addressed by the SACM specifications set of assessments. This must be defined by the SACM specifications
defined. defined.
G-004 Agility: The agility requirement is to ensure that the data G-004 Agility: The agility requirement is to ensure that the data
model, protocols, transports and its implementations are suitable to model, protocols, transports are suitable to implementations are
fit in different deployment models and scenarios. Considerations suitable to fit in different deployment models and scenarios.
for the lightweight implementations of data models and transports is Considerations for the lightweight implementations of data models
required. Use cases, especially in the vulnerability assessment and and transports is required. Use cases, especially in the
threat defense applications require time criticality in both vulnerability assessment and threat defense applications, require
obtaining the information as well as consuming (e.g. parsing) the time criticality in both obtaining the information as well as
data. consuming (e.g. parsing) the data.
G-005 Transport variability: Different transports must be supported G-005 / T-001 Transport variability: Moved to the Section 2.5.
to address different deployment and time constraints. Supporting
transports at the Layer 2, Layer 3 and higher application layers.
G-006 Extensibility: a method for expressing both standard and non- G-006 / GN-005 Extensibility: A method for expressing both standard
standard (implementer-specific) data attributes while avoiding and non-standard (implemention-specific) data attributes while
collisions should be defined. For interoperability and scope avoiding collisions should be defined. For interoperability and
boundary, an explicit set of data attributes as mandatory to scope boundary, an explicit set of data attributes as mandatory to
implement should be defined and focused on Posture Assessment should implement.
be described to allow for interoprability too.
G-007 Data Integrity: A method for ensuring data integrity must be G-007 / GN-006/ T-002 Data Integrity: A method for ensuring data
provided. This method is required to be available (i.e. all data- integrity must be provided. This method is required to be available
handling components must support it), but is not required to be used (i.e. all data-handling components must support it), but is not
in all cases. required to be used in all cases.
G-008 Data Protection: Transport protocols must ensure data G-008 / T-003 Data Protection: Moved to the Section 2.5.
protection for data in transit by encryption and robustness against
protocol-based attacks (such as reputation or store-and-forward
attacks). Protection for data at rest is not in scope for SACM.
Data protection may be used for both privacy and non-privacy
scenarios.
G-009 Topology Flexibility: Both centralized and decentralized G-009 / ARCH-004 Topology Flexibility: Moved to the Section 2.3.
(peer-to-peer) information exchange must be supported. Centralized
data exchange enables use of a common data format to bridge together
data exchange between diverse systems, and can leverage a virtual
data store that centralizes and offloads all data access, storage,
and maintenance to a dedicated resource. Decentralized data
exchange enables simplicity of sharing data between relatively
uniform systems, and between small numbers of systems, especially
within a single enterprise domain; systems can utilize an already
established mutually agreed upon native data format, which may be
standard or implementation-specific.
G-010 Data Isolation: A method for partitioning of data must be G-010 / GN-007 Data Isolation: A method for partitioning data must
supported, to accommodate considerations such as geographic, be supported, to accommodate considerations such as geographic,
regulatory, overlay boundaries and federation, where an organization regulatory, overlay boundaries and federation, where an organization
may want to differentiate between information that can be shared may want to differentiate between information that can be shared
outside its own domain and information that cannot. As with the outside its own domain and information that cannot. As with the
requirement for data integrity, this method is required to be requirement for data integrity, this method is required to be
available (i.e. all data-handling components must support it), but available (i.e. all data-handling components must support it), but
is not required to be used in all cases. is not required to be used in all cases.
G-011 Modularity: Announcement and negotiation of functional G-011 / ARCH-005 Modularity: has been moved to the Section 2.3.
capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.) must be supported,
enabling a SACM component to make inquiries about the capabilities
of other components in the SACM ecosystem.
G-012 Versioning and Backward Compatibility: Announcement and G-012 / GN-008 Versioning and Backward Compatibility: Announcement
negotiation of versions, includsive of exisiting capabilities (such and negotiation of versions, inclusive of exisiting capabilities
as transport protocols, data models, specific attributes within data (such as transport protocols, data models, specific attributes
models, standar attribute expression sets, etc.) must be supported. within data models, standard attribute expression sets, etc.) must
Negotiation for both versioning and capability negotiation is needed be supported. Negotiation for both versioning and capability is
to accommodate future growth and ecosystems with mixed capabilities. needed to accommodate future growth and ecosystems with mixed
capabilities.
G-013 Discovery: The solution must provide a mechanism for G-013 / GN-009 Discovery: There must be a mechanism for components
components to discover what information is available across the to discover what information is available across the ecosystem (i.e.
ecosystem (i.e. a method for cataloging data available in the a method for cataloging data available in the ecosystem and
ecosystem and advertising it to consumers), and where to go to get a advertising it to consumers), and where to go to get a specific
specific piece of that information. For example, providing a method piece of that information. For example, providing a method by which
by which a node can locate the advertised information so that a node can locate the advertised information so that consumers are
consumers do not have to have a priori knowledge to find available not required to have a priori knowledge to find available
information. information.
G-014 Synchronization: Request and response operations must be G-014 / IM-013 Synchronization: has been moved to the Section 2.4.
timestamped, and published information must capture time of
publication. Actions or decisions based on time-sensitive data
(such as user logon/logoff, endpoint connection/disconnection,
endpoint behavior events, etc.) are all predicated on a synchronized
understanding of time. A method for detecting and reporting time
discrepancies must be provided.
G-015 Collection separation: The request for a data item must G-015 / IM-014 Collection separation: has been moved to the
include enough information to properly identify the item to collect, Section 2.4.
but the request shall not be a command to directly execute nor
directly applied as arguments to a command. The purpose of this
requirement is primarily to reduce the potential attack vectors, but
has the additional benefit of abstracting the request for collection
from the collection method thereby allowing more flexibility in how
collection is implemented.
G-016 Collection composition A collection request can be composed of G-016 / IM-015 Collection composition has been moved to the
other collection requests (which yield collected values). This must Section 2.4.
be able to be expressed as part of the collection request so that
these references can be resolved at the point of collection without
having to interact with the requester.
2.2. Requirements based on Use Cases 2.2. Requirements based on Use Cases
This section describes the requirements that may apply to information This section describes the requirements that may apply to information
models, data models, protocols or transports as identified by the use models, data models, protocols or transports as identified by the use
cases in [I-D.ietf-sacm-use-cases] and referenced by the section cases in [I-D.ietf-sacm-use-cases] and referenced by the section
numbers from that draft. numbers from that draft.
REQ-001 Attribute Dictionary: Use Cases in the whole of Section 2 REQ-001 Attribute Dictionary: 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
skipping to change at page 6, line 46 skipping to change at page 6, line 43
the need for the data model to support scalability. For example, the need for the data model to support scalability. For example,
the query operation may result in a very large set of attributes as the query operation may result in a very large set of attributes as
well as a large set of targets. well as a large set of targets.
REQ-009 Separation of Collection Request and Collection Action: the REQ-009 Separation of Collection Request and Collection Action: the
data model must distinguish the means to request for a data item to data model must distinguish the means to request for a data item to
include enough information to properly identify the item to collect include enough information to properly identify the item to collect
but the request could be separate and distinct from the actual but the request could be separate and distinct from the actual
method or process used to fulfill the request. method or process used to fulfill the request.
2.3. Requirements for the Information Model 2.3. Requirements for the Architecture
At the simplest abstraction, the SACM architecture represents the
core components and interfaces needed to perform the production and
consumption of posture assessment information. Requirements relating
the SACM's architecture include:
ARCH-001 Scalability: The architectural components must account for
a range of deployments, from very small set of endpoints are used to
very large deployments of more than several hundreds of thousands of
endpoints.
ARCH-002 Agility: The architectural components must account for
different deployment scenarios where the architectural components
may be implemented, deployed or used within a single application,
service, network or may comprise a federated system.
ARCH-003 Separation of Data and Management functions: SACM must
define both the configuration and management of the SACM data models
and protocols used to transport and share posture assessment
information.
ARCH-004 Topology Flexibility: Both centralized and decentralized
(peer-to-peer) information exchange must be supported. Centralized
data exchange enables use of a common data format to bridge together
data exchange between diverse systems, and can leverage a virtual
data store that centralizes and offloads all data access, storage,
and maintenance to a dedicated resource. Decentralized data
exchange enables simplicity of sharing data between relatively
uniform systems, and between small numbers of systems, especially
within a single enterprise domain; systems can utilize an already
established mutually agreed upon native data format, which may be
standard or implementation-specific.
ARCH-005 Modularity: Announcement and negotiation of functional
capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.) must be supported,
enabling a SACM component to make inquiries about the capabilities
of other components in the SACM ecosystem.
2.4. Requirements for the Information Model
The SACM information model represents an abstraction for "what"
information can be communicated and "how" it is to be represented and
shared.
It is expected that as applications may produce Posture assessment It is expected that as applications may produce Posture assessment
information, they may share it using a specific data model. information, they may share it using a specific data model.
Similarly, applications consuming or requesting Posture Assessment Similarly, applications consuming or requesting Posture Assessment
information, may require it based on a specific data model. Thus, information, may require it based on a specific data model. Thus,
while there may exist different data models and schemas, they should while there may exist different data models and schemas, they should
adhere to a SACM information model that meets a set of requirements adhere to a SACM information model that meets a set of requirements
defined in this section. defined in this section.
The specific requirements include: The specific requirements include:
skipping to change at page 7, line 49 skipping to change at page 8, line 45
* Method by which data was generated (i.e. self-reported, reported * Method by which data was generated (i.e. self-reported, reported
by aggregator, result of scan, etc.) by aggregator, result of scan, etc.)
* Location of data * Location of data
* Delta results vs. total results * Delta results vs. total results
IM-012 Freshness: Published data must be associated with the time of IM-012 Freshness: Published data must be associated with the time of
origination - separately from the time of publication required in origination - separately from the time of publication required in
G-014 - so consumers can make decisions about the relevance of the IM-013. This allows consumers can make decisions about the
data based on its currency and/or age. relevance of the data based on its currency and/or age.
IM-013 Synchronization: Request and response operations must be
timestamped, and published information must capture time of
publication. Actions or decisions based on time-sensitive data
(such as user logon/logoff, endpoint connection/disconnection,
endpoint behavior events, etc.) are all predicated on a synchronized
understanding of time. A method for detecting and reporting time
discrepancies must be provided.
IM-014 Collection separation: The request for a data item must
include enough information to properly identify the item to collect,
but the request shall not be a command to directly execute nor
directly applied as arguments to a command. The purpose of this
requirement is primarily to reduce the potential attack vectors, but
has the additional benefit of abstracting the request for collection
from the collection method thereby allowing more flexibility in how
collection is implemented.
IM-015 Collection composition A collection request can be composed
of multiple collection requests (which yield collected values).
This must be able to be expressed as part of the collection request
so that the aggregation can be resolved at the point of collection
without having to interact with the requester.
2.5. Requirements for Transport Protocols
The requirements for transport protocols include:
T-001 Transport variability: Different transports must be supported
to address different deployment and time constraints. Supporting
transports may be at the Layer 2, Layer 3 and higher application
layers.
T-002 Data Integrity: A method for ensuring data integrity must be
provided if required at the transport layer.
T-003 Data Protection: Transport protocols must ensure data
protection for data in transit by encryption and robustness against
protocol-based attacks. Protection for data at rest is not in scope
for SACM. Data protection may be used for both privacy and non-
privacy scenarios.
3. Acknowledgements 3. Acknowledgements
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. Montville for reviewing and contributing to this draft.
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 9, line 29 skipping to change at page 11, line 20
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
Lisa Lorenzin Lisa Lorenzin
Juniper Networks Pulse Secure
3614 Laurel Creek Way 3614 Laurel Creek Way
Durham, NC 27712 Durham, NC 27712
US US
Email: llorenzin@juniper.net Email: llorenzin@pulsesecure.net
 End of changes. 29 change blocks. 
110 lines changed or deleted 197 lines changed or added

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