draft-ietf-sacm-requirements-01.txt   draft-ietf-sacm-requirements-02.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 13, 2015 Pulse Secure Expires: April 27, 2015 Pulse Secure
October 10, 2014 October 24, 2014
Secure Automation and Continuous Monitoring (SACM) Requirements Secure Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-01 draft-ietf-sacm-requirements-02
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 April 13, 2015. This Internet-Draft will expire on April 27, 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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. Requirements for SACM . . . . . . . . . . . . . . . . . . 3 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 Architecture . . . . . . . . . . . . 6 2.3. Requirements for the Architecture . . . . . . . . . . . . 7
2.4. Requirements for the Information Model . . . . . . . . . 7 2.4. Requirements for the Information Model . . . . . . . . . 7
2.5. Requirements for Transport Protocols . . . . . . . . . . 9 2.5. Requirements for Transport Protocols . . . . . . . . . . 10
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
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 to ensure security and model must be capable of offering to ensure security and
interoperability. interoperability.
2.1. Requirements for SACM
In order to address the needs for determining, sharing and using In order to address the needs for determining, sharing and using
posture information, the following tasks should be considered: posture information, the following tasks should be considered:
1. Define the assets. This is what we want to know about an asset. 1. Define the assets. This is what we want to know about an asset.
For instance, organizations will want to know what software is For instance, organizations will want to know what software is
installed and its many critical security attributes such as patch installed and its many critical security attributes such as patch
level. level.
2. Resolve what assets actually compose an endpoint. This requires 2. Resolve what assets actually compose an endpoint. This requires
populating the data elements and attributes needed to exchange populating the data elements and attributes needed to exchange
skipping to change at page 3, line 35 skipping to change at page 3, line 33
its policy for an acceptable data element or attribute value. A its policy for an acceptable data element or attribute value. A
system administrator can also identify specific data elements and system administrator can also identify specific data elements and
attributes that represent problems, such as vulnerabilities, that attributes that represent problems, such as vulnerabilities, that
need to be detected on an endpoint. need to be detected on an endpoint.
4. Evaluate the collected instances of the asset data against those 4. Evaluate the collected instances of the asset data against those
expressed in the policy. expressed in the policy.
5. Report the results of the evaluation. 5. Report the results of the evaluation.
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 all use deployments, the following requirements are defined for all use
cases: cases:
G-001 Extensibility: The data models, protocols and transports 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.
adding new operations while maintaining backwards compatibility.
The query language must allow general inquiries as well as 1. The transport protocol must support easily adding new operations
expression of specific paths to follow; retrieval of specific while maintaining backwards compatibility.
information based on an event, as well as on a continuous basis; and
the ability to retrieve specific pieces of information, specific 2. The query language must allow general inquiries as well as
classes of information, and/or the entirety of available expression of specific paths to follow; retrieval of specific
information. The information model must accommodate the addition of information based on an event, as well as on a continuous basis;
new data types and/or schemas in a backwards compatible fashion. and the ability to retrieve specific pieces of information,
specific classes of information, and/or the entirety of
available information.
3. The information model must accommodate the addition of 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 of 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. This must be defined by the SACM specifications set of assessments. This must be defined by the SACM
defined. specifications.
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 are suitable to implementations are model, protocols, transports are suitably to implemented to fit into
suitable to fit in different deployment models and scenarios. the different deployment models and scenarios. Considerations for
Considerations for the lightweight implementations of data models the lightweight implementations of data models and transports is
and transports is required. Use cases, especially in the required. Use cases, especially in the vulnerability assessment and
vulnerability assessment and threat defense applications, require threat defense applications, require time criticality in both
time criticality in both obtaining the information as well as obtaining the information as well as consuming (e.g. parsing) the
consuming (e.g. parsing) the data. data.
G-005 / T-001 Transport variability: Moved to the Section 2.5. G-005 / T-001 Transport variability: Moved to the Section 2.5.
G-006 / GN-005 Extensibility: A method for expressing both standard G-006 / GN-005 Extensibility: A method for expressing both standard
and non-standard (implemention-specific) data attributes while and non-standard (implemention-specific) data attributes while
avoiding collisions should be defined. For interoperability and avoiding collisions should be defined. For interoperability and
scope boundary, an explicit set of data attributes as mandatory to scope boundary, an explicit set of data attributes as mandatory to
implement. implement.
G-007 / GN-006/ T-002 Data Integrity: A method for ensuring data G-007 / GN-006/ T-002 Data Integrity: A method for ensuring data
skipping to change at page 6, line 37 skipping to change at page 6, line 48
the means for a requestor to obtain updates or change modifications the means for a requestor to obtain updates or change modifications
asynchronously. Like the query operation, these update asynchronously. Like the query operation, these update
notifications can be set up with a filter to allow for only a subset notifications can be set up with a filter to allow for only a subset
of posture assessment information to be obtained. of posture assessment information to be obtained.
REQ-008 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes REQ-008 Data model scalability: Use Cases 2.1.4 and 2.1.5 describes
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 should distinguish the request for a data attribute for
include enough information to properly identify the item to collect collection versus a request to process, execute or apply the data
but the request could be separate and distinct from the actual attributes for evaluation or analysis. N.B. This requirement is
method or process used to fulfill the request. based on most of the Use Cases in Section of
[I-D.ietf-sacm-use-cases] and defines a requirement about the
Information Model, thus this is the same as IM-014.
2.3. Requirements for the Architecture 2.3. Requirements for the Architecture
At the simplest abstraction, the SACM architecture represents the At the simplest abstraction, the SACM architecture represents the
core components and interfaces needed to perform the production and core components and interfaces needed to perform the production and
consumption of posture assessment information. Requirements relating consumption of posture assessment information. Requirements relating
the SACM's architecture include: the SACM's architecture include:
ARCH-001 Scalability: The architectural components must account for ARCH-001 Scalability: The architectural components must account for
a range of deployments, from very small set of endpoints are used to a range of deployments, from very small set of endpoints are used to
very large deployments of more than several hundreds of thousands of very large deployments.
endpoints.
ARCH-002 Agility: The architectural components must account for ARCH-002 Agility: The architectural components must account for
different deployment scenarios where the architectural components different deployment scenarios where the architectural components
may be implemented, deployed or used within a single application, may be implemented, deployed or used within a single application,
service, network or may comprise a federated system. service, network or may comprise a federated system.
ARCH-003 Separation of Data and Management functions: SACM must ARCH-003 Separation of Data and Management functions: SACM must
define both the configuration and management of the SACM data models define both the configuration and management of the SACM data models
and protocols used to transport and share posture assessment and protocols used to transport and share posture assessment
information. information.
ARCH-004 Topology Flexibility: Both centralized and decentralized ARCH-004 Topology Flexibility: Both centralized and decentralized
(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; systems can utilize an already within a single enterprise domain.
established mutually agreed upon native data format, which may be
standard or implementation-specific.
ARCH-005 Modularity: Announcement and negotiation of functional ARCH-005 Modularity: Announcement and negotiation of functional
capabilities (such as authentication protocols, authorization capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.) must be supported, schemes, data models, transport protocols, etc.) must be supported,
enabling a SACM component to make inquiries about the capabilities enabling a SACM component to make inquiries about the capabilities
of other components in the SACM ecosystem. of other components in the SACM ecosystem.
2.4. Requirements for the Information Model 2.4. Requirements for the Information Model
The SACM information model represents an abstraction for "what" The SACM information model represents an abstraction for "what"
skipping to change at page 7, line 43 skipping to change at page 8, line 4
of other components in the SACM ecosystem. of other components in the SACM ecosystem.
2.4. Requirements for the Information Model 2.4. Requirements for the Information Model
The SACM information model represents an abstraction for "what" The SACM information model represents an abstraction for "what"
information can be communicated and "how" it is to be represented and information can be communicated and "how" it is to be represented and
shared. 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:
IM-001 Uniqueness of objects of reference, such as endpoints, IP IM-001 The information model MUST define the data attributes as
addresses, etc. objects that MUST be uniquely referenced (e.g. endpoint, IP address,
asset).
IM-002 Mechanism to resolve or tolerate ambiguity in referents (e.g. IM-002 The information model may structure data models into modules
same IP address used in two separate networks) and submodules to allow for data references within a module. For
example, an endpoint may be defined as a module that references one
or more submodules that further describe the one or more assets.
Constraints and interfaces may further be defined to resolve or
tolerate ambiguity in the references (e.g. same IP address used in
two separate networks).
IM-003 Support for rootless searches and wildcard searches IM-003 The interfaces and actions in the information model MUST
include support for rootless searches and wildcard searches
IM-004 Ability to start a search anywhere in the tree, rather than IM-004 The search interfaces and actions MUST include the ability to
at a specific leaf start a search anywhere within a data model structure.
IM-005 Data lifetime management (longevity or expiration of data) IM-005 The information model SHOULD include management of the data,
including data lifetime management (longevity or expiration of
data).
IM-006 Data ephemerality (update vs. notify) IM-006 The information model SHOULD include data ephemerality
(update vs. notify).
IM-007 Looseness of coupling between producer and consumer IM-007 The information model SHOULD allow for a loose coupling
between producer and consumer.
IM-008 Ability to identify data from a specific producer IM-008 The interfaces and actions in the information model MUST
include the ability to identify data from a specific producer.
IM-009 Metadata cardinality - single-valued vs. multi-valued IM-009 The structures in the information model MUST account for
metadata cardinality. As Posture information and the tasks for
collection, aggregation or evaluation could comprise one or more
attributes, interfaces and actions must allow and account for such
cardinality as well as whether the attributes are conditional,
optional or mandatory.
IM-010 Capability negotiation - what data types and schemas are IM-010 The interfaces and actions in the information model MUST
supported include capability negotiation to enable discovery of supported and
available data types and schemas.
IM-011 Provenance of data - for example: IM-011 Provenance of data -
* Publisher identity, classification, trustworthiness, * Publisher identity, classification, trustworthiness,
authoritativeness authoritativeness
* Freshness of data * Freshness of data
* 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
skipping to change at page 11, line 18 skipping to change at page 12, line 4
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
Lisa Lorenzin Lisa Lorenzin
Pulse Secure Pulse Secure
3614 Laurel Creek Way 2700 Zanker Rd., Suite 200
Durham, NC 27712 San Jose, CA 95134
US US
Email: llorenzin@pulsesecure.net Email: llorenzin@pulsesecure.net
 End of changes. 28 change blocks. 
59 lines changed or deleted 82 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/