SACM N. Cam-Winget Internet-Draft Cisco Systems Intended status: Informational February 15, 2014 Expires: August 19, 2014 Secure Automation and Continuous Monitoring (SACM) Requirements draft-camwinget-sacm-requirements-03 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 19, 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 19, 2014 [Page 1] Internet-Draft Abbreviated Title February 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Reference Architecture Model . . . . . . . . . . . . . . 2 2.2. General SACM requirements . . . . . . . . . . . . . . . . 4 2.3. Requirements based on Use Cases . . . . . . . . . . . . . 5 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.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 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].Also, this document uses terminology defined in [I-D.ietf-sacm-terminology]. 2. Requirements This document defines requirements based on the SACM use cases defined in [I-D.ietf-sacm-use-cases]. This section describes the requirements used by SACM 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. 2.1. Reference Architecture Model A proposed architecture model is provided to highlight the functions and focus for SACM. More specifically to highlight the transport, protocols and data model by which: o Endpoints cam be discovered for the purpose of collection of posture attributes (or values) by a general collector, a posture Cam-Winget Expires August 19, 2014 [Page 2] Internet-Draft Abbreviated Title February 2014 attribute collector or a posture attribute evaluator. The communications is shown as "A" in the diagram below. o An (Posture) Assessment Consumer (which could also be a collector) can retrieve posture attributes either directly from a Posture Assessment Repository (shown as D below) or indirectly from an Evaluator (shown as B below). How a system determines what posture attributes are to be collected or evaluated is out of scope for SACM. +-----------+ +-----------+ +---------------------+ | Endpoint | <....A....> | Evaluator | <....B....> | Assessment Consumer | +-----------+ | Service | | | +-----------+ +---------------------+ +-------| ^ ^ +-----------+ | | C | | Endpoint | <-----+ v | +-----------+ +-------------+ | | Repository | | +-------------+ | | +--------------------+ D | | Posture Assessment |<---------------------+ | Repository | +--------------------+ Simple Architectural Model The functional components in the proposed architecture are defined as: o Endpoint: is the endpoint of interest that is posture validated. o Evaluator Service: is the service that determines what posture attributes it must collect and evaluate to provide a posture assessment of an endpoint. In order to evaluate posture, this service must determine the posture attributes it must assess; in addition, it may also provide the collection function as needed to evaluate the posture attributes. Conversely, this service need only provide the "collection" function if the posture attribute values are the result of an already determined posture attribute Cam-Winget Expires August 19, 2014 [Page 3] Internet-Draft Abbreviated Title February 2014 evaluation (for instance, if the endpoint can provide that information). 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 type) 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, 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. 2.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 SACM 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 Cam-Winget Expires August 19, 2014 [Page 4] Internet-Draft Abbreviated Title February 2014 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 the link layer, transport and application layers. 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. 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. 2.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 SACM endeavors 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. Cam-Winget Expires August 19, 2014 [Page 5] Internet-Draft Abbreviated Title February 2014 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. Furthermore, the query operation requires filtering capabilities to allow for only a subset of information to be retrieved. The query operation may be a synchronous request or asynchronous request. REQ-007 Use Cases 2.1.3, 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. Like the query operation, these update notifications can be set up with a filter to allow for only a subset of posture assessment information to be obtained. 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. 3. Acknowledgements The authors would like to thank Barbara Fraser, Jim Bieda and Adam Montville for reviewing and contributing to this draft. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This document defines the requirements for SACM. As such, it is expected that several data models, protocols and transports may be defined or reused from already existing standards. This section will Cam-Winget Expires August 19, 2014 [Page 6] Internet-Draft Abbreviated Title February 2014 highlight security considerations that may apply to SACM based on the architecture and standards applied in SACM. 6. References 6.1. Normative References [I-D.ietf-sacm-terminology] Waltermire, D., Montville, A., and D. Harrington, "Terminology for Security Assessment", draft-ietf-sacm- terminology-02 (work in progress), January 2014. [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. 6.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. Author's Address Nancy Cam-Winget Cisco Systems 3550 Cisco Way San Jose, CA 95134 US Email: ncamwing@cisco.com Cam-Winget Expires August 19, 2014 [Page 7]