[Docs] [txt|pdf|xml|html] [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 October 21, 2013
Expires: April 24, 2014
Secure Automation and Continuous Monitoring (SACM) Requirements
draft-camwinget-sacm-requirements-01
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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 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 April 24, 2014 [Page 1]
Internet-Draft Abbreviated Title October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Reference Architecture Model . . . . . . . . . . . . . . 2
3.2. Data Model requirements . . . . . . . . . . . . . . . . . 4
3.3. Architectural Design Tenets . . . . . . . . . . . . . . . 5
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
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 trasmit 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.dbh-sacm-terminology].
3. Requirements
As the group continues to define an architecture and use cases, some
requirements can already be formed and be used to evolve the
architecture as well. 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
Cam-Winget Expires April 24, 2014 [Page 2]
Internet-Draft Abbreviated Title October 2013
Until a richer architecture is agreed upon, the requiremens are
predicated on the following model:
+--------+ +-----------+ +---------------------+
| Asset | <....A....> | Evaluator | <....B....> | Assessment Consumer |
+--------+ +-----------+ +---------------------+
+-------| ^ ^
+--------+ | | C |
| Asset | <-----+ 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 affects 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 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
Cam-Winget Expires April 24, 2014 [Page 3]
Internet-Draft Abbreviated Title October 2013
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,
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. Data Model requirements
With the use cases spanning the need to collect, verify and update
information about posture assessment, the set of high level
requirements for the data model include:
Extensibility
Posture Assessment includes the posture attributes relating to
the asset configuration but its observed status as well. The use
cases already articulate the many different means in which such
configuration may be queried and will evolve over time. With the
explosion of different assets evolving and means in which the
assets are used and configured, the data model must be extensible
to allow for the support of these new upcoming attributes.
Agility
Considerations for the lightweight representation for these
attributes and the tools used to consume the information will be
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 agility requirement is to ensure that the data model and its
implementations are suitable to fit in different deployment
models and scenarios.
Standards representation
While it is presumed that we can leverage from standards, the
data model must also adhere to Internationalization especially of
display strings where applicable.
Cam-Winget Expires April 24, 2014 [Page 4]
Internet-Draft Abbreviated Title October 2013
Interoperability
To ensure a globalized and interoperable standard, it is
understood that a minimum set of terms and attributes are defined
to address the use cases defined, the expected set of posture
assessments (including the expected posture configuration) and
potential state or assertions.
3.3. Architectural Design Tenets
The protocol requirements must account for different network topology
scenarios to ensure that the information can be (securely) routed.
With the focus of enabling the communication of posture assessment
information, different scenarios must also be accounted for to
address the use cases. The architectural model design tenets or
requirements incude:
Discovery
To address the availability of posture assessment from different
Evaluators that may support different interface (or data model)
versions, a discovery mechanism may be introduced by which
Posture assement Evaluators and Consumers can be registered with
their capabilities (e.g. version support) clearly defined.
Many to Many
The architectural model for designing the security and transport
must account for a many-to-many connections. It is expected that
an Assessment Consumer may probe, request and consume Posture
assessment information from various Evaluators. Similarly,
Evaluators will be providing their Posture assessment information
to many Assessment Consumers.
Asynchronous updates or notifications
Assessment Consumers such as Firewalls or Intrusion Prevention
Systems will require realtime notifications especially of posture
assessment updates.">
Bulk Updates
Just as there is a need to recieve timely updates of Posture
Assessment information, there are applications where Assessment
Consumers will require full state information of an Evaluator's
Posture Assessment repository. As such, the repository may be
Cam-Winget Expires April 24, 2014 [Page 5]
Internet-Draft Abbreviated Title October 2013
very large based on both the number of assets and historical
information stored by that Evaluator's Posture Assessment
Repository; e.g. bulk synchronization or updates will be
required.">
Support for varied network deployments
As applications defined in the use cases may be deployed in
different enterprise scenarios, an enterprise's network
deployment may vary and must be taken into account. In a simple
enterprise scenario, an application may be expected to sit in the
same internet domain; however, in today's enterprise, the
application, while still part of the enterprise, may be in a
different internet domain or hosted on a private cloud. As such,
the transport must account that there data delivery may be
feasible in different OSI transport layers and in some cases, may
be over a limited bandwidth connection.
4. Security Requirements
This section describes security requirements as needed to address the
mechanisms that facilitate secure exchange of posture assessment
information.
o Authentication: all services or entities that either provide or
consume the information must be authenticated to ensure that only
authorized entities can request or provide the posture assessment
information.
o Anti-replay: if the Assessment Consumer recieves the same exact
message twice (e.g. because an attacker has re-intected the
message), it must be detectable and the Assessment Consumer must
reject the replayed message.
o Confidentiality: it should not be possible for any entity other
than the targetted Assessment Consumer to read the message.
5. Acknowledgements
The authors would like to thank Barbara Fraser, Jim Bieda and Adam
Montville for reviewing and contributing to this draft.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
Cam-Winget Expires April 24, 2014 [Page 6]
Internet-Draft Abbreviated Title October 2013
Still to do.
8. References
8.1. Normative References
[I-D.dbh-sacm-terminology]
Waltermire, D., Montville, A., and D. Harrington,
"Terminology for Security Assessment", draft-dbh-sacm-
terminology-00 (work in progress), August 2013.
[I-D.ietf-sacm-use-cases]
Waltermire, D. and D. Harrington, "Endpoint Security
Posture Assessment - Enterprise Use Cases", draft-ietf-
sacm-use-cases-03 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
Author's Address
Nancy Cam-Winget
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
US
Email: ncamwing@cisco.com
Cam-Winget Expires April 24, 2014 [Page 7]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/