idnits 2.17.1 draft-waltermire-sacm-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2013) is 4091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Waltermire, Ed. 3 Internet-Draft NIST 4 Intended status: Informational February 11, 2013 5 Expires: August 15, 2013 7 Security Automation and Continuous Monitoring (SACM) Architecture 8 draft-waltermire-sacm-architecture-00 10 Abstract 12 This document identifies the architectural components, data flows, 13 and the supporting standards needed to define an interoperable 14 automation infrastructure required to support timely, accurate and 15 actionable situational awareness over an organization's IT systems. 16 This architecture is based on previous use case and requirements 17 analysis. Automation tools implementing the continuous monitoring 18 approach described in this document will utilize this infrastructure 19 together with existing and emerging event, incident and network 20 management standards to provide visibility into the state of assets, 21 user activities and network behavior. Stakeholders will be able to 22 use these tools to aggregate and analyze relevant security and 23 operational data to understand the organizations security posture, 24 quantify business risk, and make informed decisions that support 25 organizational objectives while protecting critical information. 26 Organizations will be able to use these tools to augment and automate 27 information sharing activities to collaborate with partners to 28 identify and mitigate threats. Other automation tools will be able 29 to integrate with these capabilities to enforce policies based on 30 human decisions to harden systems, prevent misuse and reduce the 31 overall attack surface. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 15, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Functional Components . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Controller . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1.1. Functions . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1.2. Interactions . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. Content Repository . . . . . . . . . . . . . . . . . . . . 6 76 2.3. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.4. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.5. Data Storage . . . . . . . . . . . . . . . . . . . . . . . 6 79 3. Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1. DF1: Content Retrieval . . . . . . . . . . . . . . . . . . 7 81 3.2. DF2: Collection Tasking . . . . . . . . . . . . . . . . . . 7 82 3.3. DF3: Collected Data Publication . . . . . . . . . . . . . . 7 83 3.4. DF4: Collected Data Query . . . . . . . . . . . . . . . . . 7 84 4. Data Exchange Models and Communications Protocols . . . . . . . 7 85 4.1. Data Formats . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.2. Communication Protocols . . . . . . . . . . . . . . . . . . 8 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 90 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 91 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 9 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 1. Introduction 96 This document provides an architectural approach for addressing the 97 orchestration, collection and analysis of endpoint posture. This 98 architecture addresses the SACM Architecture milestone defined in the 99 draft SACM charter. The focus of this architecture is to being to 100 define an interoperable, automation infrastructure required to 101 support timely, accurate and actionable situational awareness over an 102 organization's IT systems. This document enumerates components, data 103 flows and the supporting standards needed to achieve this vision. 105 1.1. Overview 107 The architecture identified in this document provides a foundation 108 for creating interoperable automation tools and continuous monitoring 109 solutions that provide visibility into the state of assets, user 110 activities, and network behavior. Stakeholders will be able to use 111 tools based on this architecture to aggregate and analyze relevant 112 security and operational data pertaining to endpoints to understand 113 the organizations security posture and make informed decisions that 114 support organizational objectives while protecting critical 115 information. Organizations will be able to use tools supporting this 116 architecture to augment and automate information sharing activities 117 to collaborate with partners to identify and mitigate threats. Other 118 automation tools will be able to integrate with these capabilities to 119 enforce policies based on human decisions to harden systems, prevent 120 misuse and reduce the overall attack surface. 122 The architecture diagram in Figure 1 illustrates the overall 123 architecture approach. It identifies the components that participate 124 in the architecture and the data flows (DF) that enable information 125 to be exchanged between them. 127 +-------------+ +--------------+ 128 | | | | 129 | Evaluator |<---DF1--->| Content |<---DF1---------+ 130 | | | Repository | | 131 +-------------+ | | | 132 ^ ^ +--------------+ | 133 | | ^ | 134 | | | | 135 | | DF1 | 136 | | | | 137 | | V V 138 | | +--------------+ +----------+ 139 | | | | | | 140 | +-------DF2--->| Controller |<---DF2--->| Sensor | 141 | | | | | 142 | +--------------+ +----------+ 143 | | | 144 | | | 145 | DF3 | 146 | | | 147 | V | 148 | +-----------+ | 149 | | | | 150 +--------------DF4---->| Data |<-----DF3-alt-----+ 151 | Storage | 152 | | 153 +-----------+ 155 Figure 1 157 1.2. Terminology 159 Add in glossary items from use cases? 161 1.3. Requirements 163 Reference the SACM use cases document. 165 2. Functional Components 167 This section describes the functional components included in this 168 architecture. 170 2.1. Controller 172 The Controller component is responsible for directing collection 173 activities based on organizational security policy and available 174 relevant metadata. It manages data collection tasks it receives, 175 orchestrating sensors as needed to fulfill the tasks. The nature of 176 the tasks received by the Controller may vary. They may be one-time 177 tasks focused on collecting a single data set, reoccurring tasks that 178 occur an a predefined interval, or real-time tasks that continue to 179 collect information based on events 181 2.1.1. Functions 183 The controller provides the following functions: 185 Task Management 187 * The Controller processes incoming data collection task 188 requests. It decomposes each task request into one or more 189 data collection sub-tasks required to be performed by each 190 Sensor. 192 * It creates sub-tasks for any scheduled tasking it is managing 193 at the appropriate intervals. 195 * It tracks all sub-tasks currently being executed by sensors. 197 Sensor Management 199 * It dispatches any sub-tasks to the appropriate sensors. 201 * Collected data provided by the sensor is marshalled to the 202 appropriate data store. 204 2.1.2. Interactions 206 The Controller interacts with other components in this architecture 207 in the following ways: 209 o The Controller receives data collection tasks from the Evaluator 210 describing a new data collection task that needs to be performed. 212 o The Controller retrieves content from the Content Repository that 213 is needed to understand what specific data collections are 214 required to be performed by each Sensor under its management to 215 satisfy a data collection task. 217 o The Controller interacts with each Sensor under its management 218 that is needed to ensure that the appropriate data collection 219 activities on the sensor are performed to address a data 220 collection task. As data is collected and once data collection is 221 complete the Controller receives data collection results from the 222 sensor. 224 2.2. Content Repository 226 A repository of security metadata that can be used to drive security- 227 oriented processes (e.g. vulnerability, configuration, asset data, 228 assessment/collection methods). This is long-lived, infrequently 229 changing information that is provided from a variety of external 230 information sources. 232 The methods used to maintain information in a content repository is 233 currently out of scope. 235 2.3. Evaluator 237 An upstream component that queries collected state information to 238 perform analysis generating measurements and compliances results. 240 2.4. Sensor 242 Responsible for collecting actual system state information (e.g. 243 configurations, software inventory, patch) based on data collection 244 sub-tasks provided by the Controller. It uses data collection 245 instructions provided by the content repository (e.g. SCAP-style 246 assessment content). This could be an agent on an endpoint or a 247 remote collection system with or without privileged access to the 248 endpoint. 250 2.5. Data Storage 252 An upstream component that receives collected state information. 253 This could be a data repository, an information processor that acts 254 on the provided information or a process that routes information to 255 other sources. This component supports SACM use cases UC2 and UC3. 257 3. Data Flows 259 The following data flows, also called interfaces, describe the nature 260 of specific inter-component communications. 262 3.1. DF1: Content Retrieval 264 This data flow is used to provide any digital content and supporting 265 metadata that is needed to drive data collection and analysis 266 processes. 268 The following interactions are supported by this data flow: 270 o The Controller uses this data flow to acquire the information it 271 needs to determine what actions to instruct the sensors to 272 perform. The Controller may also store policy decisions for 273 future use in the content repository for future use. 275 o The sensor uses this data flow to retrieve any data/content that 276 is needed to perform collection activities. 278 o The Evaluator uses this data flow to retrieve any content that 279 describes the expected state and analysis rules needed to make 280 measurements and determine compliance with organizational policy. 282 3.2. DF2: Collection Tasking 284 This is a control channel that is used to enable dynamic management 285 of the information collected by the Sensor. Data collection tasks 286 containing instruction of what to collect, and potentially how to 287 collect, are exchanged using this data flow. These instructions may 288 point to assessment content stored in the Content Repository. 290 3.3. DF3: Collected Data Publication 292 Used to make collected information available to other "upstream" 293 components that archive the information for future use or perform 294 additional analysis/processing. 296 3.4. DF4: Collected Data Query 298 Used by the Evaluator and other external components to query 299 previously collected data. 301 4. Data Exchange Models and Communications Protocols 303 Document where existing work exists, what is currently defined by 304 SDOs, and any gaps that should be addressed. Point to existing 305 standards when available. Describe emerging efforts that may be used 306 for the creation of new standards. For gaps provide insight into 307 what would be a good fit for SACM or another IETF working groups. 309 This will help us to identify what is needed for SACM to work on. 310 This section will help determine which of the specifications can be 311 normatively referenced and what needs to be addressed in the IETF. 312 This should help us determine any protocol or guidance documentation 313 we will need to generate. 315 Things to address: 317 For IETF related efforts, discuss work in NEA and MILE working 318 groups. Address SNMP, NetConf and other efforts as needed. 320 Reference any Security Automation work that is applicable. 322 4.1. Data Formats 324 The functional capabilities described in the SACM Use Cases document 325 require a significant number of models to be selected or defined. A 326 "model" in this sense is a logical arrangement of information that 327 may have more than one syntactic binding. For the purpose of this 328 document, only the logical data model is considered. However, where 329 appropriate, example data models that may have well-defined syntactic 330 expressions may be referenced. 332 4.2. Communication Protocols 334 Document these. 336 5. IANA Considerations 338 This memo includes no request to IANA. 340 All drafts are required to have an IANA considerations section (see 341 RFC 5226 [RFC5226] for a guide). If the draft does not require IANA 342 to do anything, the section contains an explicit statement that this 343 is the case (as above). If there are no requirements for IANA, the 344 section will be removed during conversion into an RFC by the RFC 345 Editor. 347 6. Security Considerations 349 All drafts are required to have a security considerations section. 350 See RFC 3552 [RFC3552] for a guide. 352 7. Acknowledgements 354 The author would like to acknowledge the members of the SACM mailing 355 list for their keen and insightful feedback on the concepts and text 356 within this document. 358 8. Informative References 360 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 361 Text on Security Considerations", BCP 72, RFC 3552, 362 July 2003. 364 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 365 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 366 May 2008. 368 Appendix A. Additional Stuff 370 This becomes an Appendix if needed. 372 Author's Address 374 David Waltermire (editor) 375 National Institute of Standards and Technology 376 100 Bureau Drive 377 Gaithersburg, Maryland 20877 378 USA 380 Phone: 381 Email: david.waltermire@nist.gov