Network Working Group D. Waltermire, Ed. Internet-Draft NIST Intended status: Informational February 11, 2013 Expires: August 15, 2013 Security Automation and Continuous Monitoring (SACM) Architecture draft-waltermire-sacm-architecture-00 Abstract This document identifies the architectural components, data flows, and the supporting standards needed to define an interoperable automation infrastructure required to support timely, accurate and actionable situational awareness over an organization's IT systems. This architecture is based on previous use case and requirements analysis. Automation tools implementing the continuous monitoring approach described in this document will utilize this infrastructure together with existing and emerging event, incident and network management standards to provide visibility into the state of assets, user activities and network behavior. Stakeholders will be able to use these tools to aggregate and analyze relevant security and operational data to understand the organizations security posture, quantify business risk, and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use these tools to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. 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 15, 2013. Waltermire Expires August 15, 2013 [Page 1]
Internet-Draft SACM Architecture February 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 2. Functional Components . . . . . . . . . . . . . . . . . . . . . 4 2.1. Controller . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Functions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Interactions . . . . . . . . . . . . . . . . . . . . . 5 2.2. Content Repository . . . . . . . . . . . . . . . . . . . . 6 2.3. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . . 6 3. Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. DF1: Content Retrieval . . . . . . . . . . . . . . . . . . 7 3.2. DF2: Collection Tasking . . . . . . . . . . . . . . . . . . 7 3.3. DF3: Collected Data Publication . . . . . . . . . . . . . . 7 3.4. DF4: Collected Data Query . . . . . . . . . . . . . . . . . 7 4. Data Exchange Models and Communications Protocols . . . . . . . 7 4.1. Data Formats . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Communication Protocols . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Waltermire Expires August 15, 2013 [Page 2]
Internet-Draft SACM Architecture February 2013 1. Introduction This document provides an architectural approach for addressing the orchestration, collection and analysis of endpoint posture. This architecture addresses the SACM Architecture milestone defined in the draft SACM charter. The focus of this architecture is to being to define an interoperable, automation infrastructure required to support timely, accurate and actionable situational awareness over an organization's IT systems. This document enumerates components, data flows and the supporting standards needed to achieve this vision. 1.1. Overview The architecture identified in this document provides a foundation for creating interoperable automation tools and continuous monitoring solutions that provide visibility into the state of assets, user activities, and network behavior. Stakeholders will be able to use tools based on this architecture to aggregate and analyze relevant security and operational data pertaining to endpoints to understand the organizations security posture and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use tools supporting this architecture to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. The architecture diagram in Figure 1 illustrates the overall architecture approach. It identifies the components that participate in the architecture and the data flows (DF) that enable information to be exchanged between them. Waltermire Expires August 15, 2013 [Page 3]
Internet-Draft SACM Architecture February 2013 +-------------+ +--------------+ | | | | | Evaluator |<---DF1--->| Content |<---DF1---------+ | | | Repository | | +-------------+ | | | ^ ^ +--------------+ | | | ^ | | | | | | | DF1 | | | | | | | V V | | +--------------+ +----------+ | | | | | | | +-------DF2--->| Controller |<---DF2--->| Sensor | | | | | | | +--------------+ +----------+ | | | | | | | DF3 | | | | | V | | +-----------+ | | | | | +--------------DF4---->| Data |<-----DF3-alt-----+ | Storage | | | +-----------+ Figure 1 1.2. Terminology Add in glossary items from use cases? 1.3. Requirements Reference the SACM use cases document. 2. Functional Components This section describes the functional components included in this architecture. Waltermire Expires August 15, 2013 [Page 4]
Internet-Draft SACM Architecture February 2013 2.1. Controller The Controller component is responsible for directing collection activities based on organizational security policy and available relevant metadata. It manages data collection tasks it receives, orchestrating sensors as needed to fulfill the tasks. The nature of the tasks received by the Controller may vary. They may be one-time tasks focused on collecting a single data set, reoccurring tasks that occur an a predefined interval, or real-time tasks that continue to collect information based on events 2.1.1. Functions The controller provides the following functions: Task Management * The Controller processes incoming data collection task requests. It decomposes each task request into one or more data collection sub-tasks required to be performed by each Sensor. * It creates sub-tasks for any scheduled tasking it is managing at the appropriate intervals. * It tracks all sub-tasks currently being executed by sensors. Sensor Management * It dispatches any sub-tasks to the appropriate sensors. * Collected data provided by the sensor is marshalled to the appropriate data store. 2.1.2. Interactions The Controller interacts with other components in this architecture in the following ways: o The Controller receives data collection tasks from the Evaluator describing a new data collection task that needs to be performed. o The Controller retrieves content from the Content Repository that is needed to understand what specific data collections are required to be performed by each Sensor under its management to satisfy a data collection task. Waltermire Expires August 15, 2013 [Page 5]
Internet-Draft SACM Architecture February 2013 o The Controller interacts with each Sensor under its management that is needed to ensure that the appropriate data collection activities on the sensor are performed to address a data collection task. As data is collected and once data collection is complete the Controller receives data collection results from the sensor. 2.2. Content Repository A repository of security metadata that can be used to drive security- oriented processes (e.g. vulnerability, configuration, asset data, assessment/collection methods). This is long-lived, infrequently changing information that is provided from a variety of external information sources. The methods used to maintain information in a content repository is currently out of scope. 2.3. Evaluator An upstream component that queries collected state information to perform analysis generating measurements and compliances results. 2.4. Sensor Responsible for collecting actual system state information (e.g. configurations, software inventory, patch) based on data collection sub-tasks provided by the Controller. It uses data collection instructions provided by the content repository (e.g. SCAP-style assessment content). This could be an agent on an endpoint or a remote collection system with or without privileged access to the endpoint. 2.5. Data Storage An upstream component that receives collected state information. This could be a data repository, an information processor that acts on the provided information or a process that routes information to other sources. This component supports SACM use cases UC2 and UC3. 3. Data Flows The following data flows, also called interfaces, describe the nature of specific inter-component communications. Waltermire Expires August 15, 2013 [Page 6]
Internet-Draft SACM Architecture February 2013 3.1. DF1: Content Retrieval This data flow is used to provide any digital content and supporting metadata that is needed to drive data collection and analysis processes. The following interactions are supported by this data flow: o The Controller uses this data flow to acquire the information it needs to determine what actions to instruct the sensors to perform. The Controller may also store policy decisions for future use in the content repository for future use. o The sensor uses this data flow to retrieve any data/content that is needed to perform collection activities. o The Evaluator uses this data flow to retrieve any content that describes the expected state and analysis rules needed to make measurements and determine compliance with organizational policy. 3.2. DF2: Collection Tasking This is a control channel that is used to enable dynamic management of the information collected by the Sensor. Data collection tasks containing instruction of what to collect, and potentially how to collect, are exchanged using this data flow. These instructions may point to assessment content stored in the Content Repository. 3.3. DF3: Collected Data Publication Used to make collected information available to other "upstream" components that archive the information for future use or perform additional analysis/processing. 3.4. DF4: Collected Data Query Used by the Evaluator and other external components to query previously collected data. 4. Data Exchange Models and Communications Protocols Document where existing work exists, what is currently defined by SDOs, and any gaps that should be addressed. Point to existing standards when available. Describe emerging efforts that may be used for the creation of new standards. For gaps provide insight into what would be a good fit for SACM or another IETF working groups. Waltermire Expires August 15, 2013 [Page 7]
Internet-Draft SACM Architecture February 2013 This will help us to identify what is needed for SACM to work on. This section will help determine which of the specifications can be normatively referenced and what needs to be addressed in the IETF. This should help us determine any protocol or guidance documentation we will need to generate. Things to address: For IETF related efforts, discuss work in NEA and MILE working groups. Address SNMP, NetConf and other efforts as needed. Reference any Security Automation work that is applicable. 4.1. Data Formats The functional capabilities described in the SACM Use Cases document require a significant number of models to be selected or defined. A "model" in this sense is a logical arrangement of information that may have more than one syntactic binding. For the purpose of this document, only the logical data model is considered. However, where appropriate, example data models that may have well-defined syntactic expressions may be referenced. 4.2. Communication Protocols Document these. 5. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see RFC 5226 [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 6. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. Waltermire Expires August 15, 2013 [Page 8]
Internet-Draft SACM Architecture February 2013 7. Acknowledgements The author would like to acknowledge the members of the SACM mailing list for their keen and insightful feedback on the concepts and text within this document. 8. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Appendix A. Additional Stuff This becomes an Appendix if needed. Author's Address David Waltermire (editor) National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 USA Phone: Email: david.waltermire@nist.gov Waltermire Expires August 15, 2013 [Page 9]