Skip to main content

Secure Automation and Continuous Monitoring (SACM) Requirements
draft-camwinget-sacm-requirements-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Nancy Cam-Winget
Last updated 2013-10-14
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-camwinget-sacm-requirements-00
SACM                                                       N. Cam-Winget
Internet-Draft                                             Cisco Systems
Intended status: Informational                          October 14, 2013
Expires: April 17, 2014

    Secure Automation and Continuous Monitoring (SACM) Requirements
                  draft-camwinget-sacm-requirements-00

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 17, 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 17, 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 . . . . . . . . . . . . . . . . .   3
     3.3.  Architectural Design Tenets . . . . . . . . . . . . . . .   3
   4.  Security Requirements . . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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.  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 requiremens are
   predicated on the following model:

Cam-Winget               Expires April 17, 2014                 [Page 2]
Internet-Draft              Abbreviated Title               October 2013

               +--------+             +-----------+              +---------------------+
               | Asset  | <....A....> | Evaluator | <....B....>  | Assessment Consumer |
               +--------+             +-----------+              +---------------------+
                                +-------|   ^
               +--------+       |           | C
               | Asset  | <-----+           v
               +--------+            +-------------+
                                     | 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  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 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

   TBD.

3.3.  Architectural Design Tenets

Cam-Winget               Expires April 17, 2014                 [Page 3]
Internet-Draft              Abbreviated Title               October 2013

   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 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
       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.">

4.  Security Requirements

   This section describes security requirements as needed to address the
   mechanisms that facilitate secure exchange of posture assessment
   information.

Cam-Winget               Expires April 17, 2014                 [Page 4]
Internet-Draft              Abbreviated Title               October 2013

   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

   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, "Using Security Posture
              Assessment to Grant Access to Enterprise Network
              Resources", draft-ietf-sacm-use-cases-01 (work in
              progress), September 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

Cam-Winget               Expires April 17, 2014                 [Page 5]
Internet-Draft              Abbreviated Title               October 2013

   [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 17, 2014                 [Page 6]