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]