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]