[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04
draft-ietf-sacm-requirements
SACM N. Cam-Winget
Internet-Draft Cisco Systems
Intended status: Informational February 2, 2014
Expires: August 6, 2014
Secure Automation and Continuous Monitoring (SACM) Requirements
draft-camwinget-sacm-requirements-02
Abstract
This document defines the scope and set of requirements for the
Secure Automation and Continuous Monitoring working group. The
requirements and scope are based on the agreed upon use cases and
architecture defined.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cam-Winget Expires August 6, 2014 [Page 1]
Internet-Draft Abbreviated Title February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Reference Architecture Model . . . . . . . . . . . . . . 2
3.2. General SACM requirements . . . . . . . . . . . . . . . . 4
3.3. Requirements based on Use Cases . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Today's challenges of evolving threats and improved analytics to
address such threats highlight a need to automate the securing of
both information and the systems that store, process and transmit the
information. SACM's charter focuses on addressing some of these
challenges in a narrower scope by bounding the task to address use
cases that pertain to the posture assessment of endpoints.
This document focuses on describing the requirements for facilitating
the exchange of posture assessment information, in particular, for
the use cases as exemplified in [I-D.ietf-sacm-use-cases].
2. Terminology
Currently defined in [I-D.ietf-sacm-terminology].
3. Requirements
This document defines requirements based on the SACM WG's use cases
defined in [I-D.ietf-sacm-use-cases]. This section describes the
requirements used by the SACM WG to assess and compare candidate
information models and protocols to suit the architecture. These
requirements express characteristics or features that a candidate
protocol or data model must be capable of offering so as to ensure
security and interoperability.
3.1. Reference Architecture Model
Until a richer architecture is agreed upon, the requirements are
predicated on the following model:
Cam-Winget Expires August 6, 2014 [Page 2]
Internet-Draft Abbreviated Title February 2014
+-----------+ +-----------+ +---------------------+
| Endpoint | <....A....> | Evaluator | <....B....> | Assessment Consumer |
+-----------+ +-----------+ +---------------------+
+-------| ^ ^
+-----------+ | | C |
| Endpoint | <-----+ v |
+-----------+ +-------------+ |
| Repository | |
+-------------+ |
|
+--------------------+ |
| Posture Assessment |<---------------------+
| Repository |
+--------------------+
Simple Architectural Model
The Architectural Model shown above demonstrates:
o Asset: is the endpoint of interest that is posture validated.
o Evaluator: is the service that evaluates the posture assessment
and stores the posture result into a repository.
o Repository: is the storage component bound to the Evaluator that
contains the posture assessment information.
o Posture Assessment Repository: is another type of repository (or a
Collector) that holds posture assessment information. While not
bound to the Evaluator, it is another source of posture assessment
information (e.g. a data aggregation point aggregating posture
assessment with other attributes) that can provide information to
serve SACM use cases.
o Assessment Consumer: is the service that requires the posture
assessments information of one or more assets.
Using this architectural reference model, the interfaces, data models
and transports used to affect the posture assessment, e.g. A in the
figure above have already been defined by different mechanisms, for
example, an IETF defined one through NEA. As the focus of SACM is
the information exchange to obtain the posture assessment
information, it can be achieved through the interfaces shown as B.
That is, it is not clear that there is a requirement for the
Assessment Consumer to tap directly into the Repository. Similarly,
Cam-Winget Expires August 6, 2014 [Page 3]
Internet-Draft Abbreviated Title February 2014
it is not clear that SACM is chartered to define the interfaces and
data model for how an Evaluator stores and transports the assessment
results to the Repository. Thus, the focus of the requirements will
revolve around the data models, protocols and transports for B, the
communication of posture assessment from an Evaluator to an
Assessment Consumer.
3.2. General SACM requirements
The use cases defined in [I-D.ietf-sacm-use-cases] apply to many
deployment scenarios. To ensure interoperability, scalability and
flexibility in any of these deployments, the following requirements
are defined for all use cases:
G-001 The data models, protocols and transports defined by the SACM
WG must be extensible to allow support for non-standard and future
extensions.
G-002 The data models, protocols and transports must be specified
with enough details and state machine to ensure interoperability.
G-003 SACM must support a broad set of deployment scenarios. As
such, it is possible that the size or posture assessment information
can vary from a single assessment that is small in (record or
datagram) size to a very large datagram or a very large set of
assessments and must be addressed by the SACM specifications
defined. Thus, the data models, protocols and transports must be
scalable.
G-004 Considerations for the lightweight implementations of data
models and transports is required. Use cases, especially in the
vulnerability assessment and threat defense applications require
time criticality in both obtaining the information as well as
consuming (e.g. parsing) the data. The agility requirement is to
ensure that the data model, protocols, transports and its
implementations are suitable to fit in different deployment models
and scenarios.
G-005 Different transports must be supported to address different
deployment and time constraints. Supporting layer 2, layer 3 and
layer 7 transports are to be considered.
G-006 For interoperability and scope boundary, an explicit set of
data attributes as mandatory to implement should be defined. While
the SACM charter defines the focus to be on posture assessment,
attributes corresponding to Posture Assessment should be described.
Cam-Winget Expires August 6, 2014 [Page 4]
Internet-Draft Abbreviated Title February 2014
G-007 To address security and privacy considerations, the data
model, protocols and transport must consider authorization based on
roles to only allow authorized requestors and publishers to access
the information being requested or published.
3.3. Requirements based on Use Cases
This section describes the requirements that may apply to information
models, data models, protocols or transports as identified by the use
cases in [I-D.ietf-sacm-use-cases] and referenced by the section
numbers from that draft.
REQ-001 Use Cases in the whole of Section 2 describe the need for an
Attribute Dictionary. With SACM's scope focused on Posture
Assessment, the attribute collection and aggregation must have a
well understood set of attributes inclusive of their meaning or
usage intent.
REQ-002 Use Case 2.1.1 describes the need for an Information Model
to drive content definition. As the SACM WG will endeavor to reuse
already existing standards which may have their own data models
defined by instantiating an information model, the data models can
be mapped to SACM's information model. See [RFC3444] for a
description and distinctions between an information and data model.
REQ-003 Use Case 2.1.1 describes the need to instantiate a data
model that can map to the SACM protocols for posture content
operations such as publication, query, change detection and
asynchronous notifications.
REQ-004 Use Case 2.1.2 describes the need to discover endpoints and
their composition.
REQ-005 Use Case 2.1.2 describes the need for the data model to
support a query operation based on a set of attributes to facilitate
collection of information such as posture assessment, inventory (of
endpoints or endpoint components) and configuration checklist.
REQ-006 Use Case 2.1.3 describes the need for the data model to
support the means for the information to be collected through a
query mechanism.
REQ-007 Use Cases 2.1.4 and 2.1.5 describe the need for the data
model to support the means for the information to be published
asynchronously. Similarly, the data model must support the means
for a requestor to obtain updates or change modifications
asynchronously.
Cam-Winget Expires August 6, 2014 [Page 5]
Internet-Draft Abbreviated Title February 2014
REQ-008 Use Cases 2.1.4 and 2.1.5 describes the need for the data
model to support scalability. For example, the query operation may
result in a very large set of attributes as well as a large set of
targets.
4. Acknowledgements
The authors would like to thank Barbara Fraser, Jim Bieda and Adam
Montville for reviewing and contributing to this draft.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This document defines the requirements for the SACM WG. As such, it
is expected that several data models, protocols and transports may be
defined or reused from already existing standards. This section will
highlight security considerations that may apply to SACM based on the
architecture and standards applied in SACM.
7. References
7.1. Normative References
[I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., and D. Harrington,
"Terminology for Security Assessment", draft-ietf-sacm-
terminology-01 (work in progress), October 2013.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-05 (work in progress), November 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January
2003.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
Cam-Winget Expires August 6, 2014 [Page 6]
Internet-Draft Abbreviated Title February 2014
Author's Address
Nancy Cam-Winget
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
US
Email: ncamwing@cisco.com
Cam-Winget Expires August 6, 2014 [Page 7]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/