<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-waltermire-sacm-architecture-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="SACM Architecture">Security Automation and Continuous Monitoring (SACM) Architecture</title>

    <author fullname="David Waltermire" initials="D.W." role="editor"
            surname="Waltermire">
      <organization abbrev="NIST">National Institute of Standards and Technology</organization>

      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>Maryland</region>
          <code>20877</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>david.waltermire@nist.gov</email>
      </address>
    </author>

    <date year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>
<!--
    <workgroup>Internet Engineering Task Force</workgroup>
-->
    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>security automation continuous monitoring architecture</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

      <section title="Overview">
        <t>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.</t>

        <t>The architecture diagram in <xref target="sacm-architecture"/> 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.</t>

        <figure anchor="sacm-architecture"><artwork><![CDATA[
          
+-------------+           +--------------+
|             |           |              |
|  Evaluator  |<---DF1--->|  Content     |<---DF1---------+
|             |           |  Repository  |                |
+-------------+           |              |                |
    ^      ^              +--------------+                |
    |      |                     ^                        |
    |      |                     |                        |
    |      |                    DF1                       |
    |      |                     |                        |
    |      |                     V                        V
    |      |              +--------------+           +----------+
    |      |              |              |           |          |
    |      +-------DF2--->|  Controller  |<---DF2--->|  Sensor  |
    |                     |              |           |          |
    |                     +--------------+           +----------+
    |                            |                        |    
    |                            |                        |
    |                           DF3                       |
    |                            |                        |
    |                            V                        |
    |                      +-----------+                  |
    |                      |           |                  |
    +--------------DF4---->|  Data     |<-----DF3-alt-----+
                           |  Storage  |
                           |           |
                           +-----------+                  

]]></artwork></figure>
      </section>

      <section title="Terminology">
        <t>Add in glossary items from use cases?</t>
      </section>

      <section title="Requirements">
        <t>Reference the SACM use cases document.</t>
      </section>
    </section>

    
    <section title="Functional Components" anchor="sec-funct-comp">
      <t>This section describes the functional components included in this architecture.</t>

      <section title="Controller" anchor="sec-funct-comp-controller">
        <t>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</t>

        <section title="Functions">
          <t>The controller provides the following functions:
            <list>
              <t>Task Management
                <list style="symbols">
                  <t>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 <xref target="sec-funct-comp-sensor" format="title"/>.</t>
                  <t>It creates sub-tasks for any scheduled tasking it is managing at the appropriate intervals.</t>
                  <t>It tracks all sub-tasks currently being executed by sensors.</t>
                </list>
              </t>
              <t>Sensor Management
                <list style="symbols">
                  <t>It dispatches any sub-tasks to the appropriate sensors.</t>
                  <t>Collected data provided by the sensor is marshalled to the appropriate data store.</t>
                </list>
              </t>
            </list>
          </t>
        </section>

        <section title="Interactions">
          <t>The Controller interacts with other components in this architecture in the following ways:
            <list style="symbols">
              <t>The Controller receives data collection tasks from the <xref target="sec-funct-comp-evaluator" format="title"/> describing a new data collection task that needs to be performed.</t>
              <t>The Controller retrieves content from the <xref target="sec-funct-comp-content-repo" format="title"/> that is needed to understand what specific data collections are required to be performed by each <xref target="sec-funct-comp-sensor" format="title"/> under its management to satisfy a data collection task.</t>
              <t>The Controller interacts with each <xref target="sec-funct-comp-sensor" format="title"/> 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.</t>
            </list>
          </t>
        </section>
      </section>
        
      <section title="Content Repository" anchor="sec-funct-comp-content-repo">
        <t>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.</t>
        <t>The methods used to maintain information in a content repository is currently out of scope.</t>
      </section>
      
      <section title="Evaluator" anchor="sec-funct-comp-evaluator">
        <t>An upstream component that queries collected state information to perform analysis generating measurements and compliances results.</t>
      </section>

      <section title="Sensor" anchor="sec-funct-comp-sensor">
        <t>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.</t> 
      </section>
      
      <section title="Data Storage" anchor="sec-funct-comp-data-storage">
        <t>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.</t>
      </section>
    </section>


    <section title="Data Flows" anchor="sec-data-flows">
      <t>The following data flows, also called interfaces, describe the nature of specific inter-component communications.</t>
      <section title="DF1: Content Retrieval" anchor="sec-data-flows-content-retrieval">
        <t>This data flow is used to provide any digital content and supporting metadata that is needed to drive data collection and analysis processes.</t>
        
        <t>The following interactions are supported by this data flow:
          <list style="symbols">
            <t>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.</t>
            <t>The sensor uses this data flow to retrieve any data/content that is needed to perform collection activities.</t> 
            <t>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.</t>
          </list>
        </t>
      </section>

      <section title="DF2: Collection Tasking" anchor="sec-data-flows-collection-tasking">
        <t>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.</t>
      </section>
      
      <section title="DF3: Collected Data Publication" anchor="sec-data-flows-collected-data-publication">
        <t>Used to make collected information available to other "upstream" components that archive the information for future use or perform additional analysis/processing.</t>
      </section>
      
      <section title="DF4: Collected Data Query" anchor="sec-data-flows-collected-data-query">
        <t>Used by the Evaluator and other external components to query previously collected data.</t>
      </section>
    </section>

    <section title="Data Exchange Models and Communications Protocols" anchor="exchange-models-and-protocols">
      <t>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.</t>
      <t>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.</t>
      <t>Things to address:
        <list>
          <t>For IETF related efforts, discuss work in NEA and MILE working groups. Address SNMP, NetConf and other efforts as needed.</t>
          <t>Reference any Security Automation work that is applicable.</t>
        </list>
      </t>
      
      <section title="Data Formats" anchor="data-exchange-models">
        <!-- provide cross reference to SACM Use Cases -->
        <t>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.</t>
      </section>
      
      <section title="Communication Protocols" anchor="communication-protocols">
        <t>Document these.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      <t>All drafts are required to have an IANA considerations section (see
      <xref target="RFC5226">
      RFC 5226</xref> 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.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>All drafts are required to have a security considerations section.
      See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
    </section>

    <section title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->
<!--
    <references title="Normative References">
      &RFC2119;

    </references>
-->
    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      
      &RFC3552;
      &RFC5226;
    </references>

    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix if needed.</t>
    </section>
  </back>
</rfc>

