<?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 RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY I-D.ietf-sacm-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-use-cases.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-terminology">
<!ENTITY I-D.handt-sacm-alternate-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.handt-sacm-alternate-architecture.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-camwinget-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 P-->

    <title abbrev="Abbreviated Title">Secure Automation and Continuous Monitoring (SACM) Architecture</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

 
    <author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget" role="editor">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>3550 Cisco Way</street>
	  <city>San Jose</city>
	  <country>US</country>
	  <code>95134</code>
	  <region>CA</region>
      
              <!-- Reorder-->
        </postal>

        <email>ncamwing@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
      
    </author>
    <author fullname="Brian Ford" initials="B." surname="Ford">
        <organization>Cisco Systems</organization>
        <address>
            <postal>
                <street>5507-10 Nesconset Hwy #242</street>
                <city>Mt Sinai</city>
                <country>US</country>
                <code>11766</code>
                <region>NY</region>
            </postal>
            
            <email>brford@cisco.com</email>
        </address>
    </author>
  
    <author fullname="Lisa Lorenzin" initials="L." surname="Lorenzin">
      <organization>Juniper Networks</organization>
      <address>
          <postal>
              <street>3614 Laurel Creek Way</street>
              <city>Durham</city>
              <country>US</country>
              <code>27712</code>
              <region>NC</region>
          </postal>
          
          <email>llorenzin@juniper.net</email>
      </address>
  </author>

  <author fullname="Ira E McDonald" initials="I." surname="McDonald">
    <organization>High North Inc</organization>
    <address>
        <postal>
            <street>PO Box 221</street>
            <city>Grand Marais</city>
            <country>US</country>
            <code>49839</code>
            <region>MI</region>
        </postal>
        
        <email>blueroofmusic@gmail.com</email>
    </address>
  </author>
  
  <author fullname="Aaron Woland" initials="A." surname="Woland">
      <organization>Cisco Systems</organization>
      <address>
          <postal>
              <street>1900 South Blvd. Suite 200</street>
              <city>Charlotte</city>
              <country>US</country>
              <code>28203</code>
              <region>NC</region>
          </postal>
          
          <email>loxx@cisco.com</email>
      </address>
  </author>


    <date month="June" year="2014"/>


    <area>General</area>

    <workgroup>SACM</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>template</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 describes an architecture for standardization of interfaces, protocols and information models related to security automation and continuous monitoring. It describes the basic architecture, components and their interfaces defined to enable the collection, acquisition and verification of Posture and Posture Assessments.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
        <t> Several data models and protocols are in use today that allow different applications to perform the collection, acquisition and assessment of posture.  These applications can vary from being focused on general system and security management to specialized configuration, compliance and control systems.  With an existing varied set of applications, there is a strong desire to standardize data models, protocols and interfaces to better allow for the automation of such data processes.</t>
      
      <t>This document describes an architecture to enable standardized
          collection, acquisition, and verification of Posture and Posture
          Assessments.  The architecture will include the components and interfaces that can be used to better identify the Information Model, type(s) of transport protocols needed for communication, and further, provide a model from which requirements can be drawn.</t>

      <t> This document uses terminology defined in <xref target="I-D.ietf-sacm-terminology"/>.</t>

    </section>
      
    <section anchor="arch" title="Architectural Overview">

<t> Figure 1 shows a proposed SACM architecture. Three main functional components are defined: a Posture Assessment Information Consumer (C), a Posture Assessment Information Provider (P) and a Control Plane (CP) used to facilitate some of the security functions such as authentication and authorization and other metadata functions.  </t>
        <figure title="Simple Architectural Model">
          <artwork>
          
            <![CDATA[
                       +-----------------------------------+
                       | +-----------------------------------+
                       | | +-----------------------------------+
                       | | |                                   |
                       +-| |      Posture Assessment           |
                         +-|      Information Consumer (C)     |
                           +-----------------------------------+
                             /    \         /   \        /   \
                            /      \       /     \      /     \
                            -      -       -     -      -     -
                           A |    |         || ||B       |   |C
                             |    |         || ||        |   |
                             |    |        -     -      -     -
                             |    |        \     /      \     /
                             |    |         \   /        \   /
                   /|--------|    |------------------------------------------------ |\
                  /   --------------------------------------------------------------  \
                 /    Broker/Proxy/Repository: AuthZ, Directory, metadata/capability   \
                 \                    [Control Plane (CP)]                             /
                  \   --------------------------------------------------------------  /
                   \|--------|    |------------------------------------------------ |/
                           A |    |         || ||B       |   |C
                             |    |         || ||        |   |
                            -      -       -     -      -     -
                            \      /       \     /      \     /
                             \    /         \   /        \   /
                           +-----------------------------------+
                           |                                   |-+
                           |     Posture Assessment            | |
                           |    Information Provider (P)       | |-+
                           |                                   | | |
                           +-----------------------------------+ | |
                             +-----------------------------------+ |
                               +-----------------------------------+
                             

                                  ]]>
          </artwork>
        </figure>
	<t> The functional components in the proposed architecture are further described in this section.</t>
    
    <section anchor="requestor" title="Posture Assessment Information Consumer">
        <t>As described in Section 2.2 of the SACM Use Cases <xref target="I-D.ietf-sacm-use-cases"/>, several usage scenarios are posed with different application types requesting posture assessment information.  Whether it is a configuration verification system, a checklist verification system, or a system for detecting posture deviations, compliance or vulnerabilities, they all need to acquire information about Posture Assessment.  Thus, the architectural component to enable such requests is defined as a Posture Assessment Information Consumer (C or Consumer).</t>
        
        <t>The Consumer defines the capabilities and functions that must be handled in order to facilitiate a Posture Assessment Information Request.  Requests can be either for a single posture attribute or a set of posture attributes where those attributes can be the raw information or an evaluated or assessed state based upon that information.  The Consumer may further choose to query for the information directly (one-time query), or to request for updates to be provided as the Posture Assessment Information changes (Subscription).  A request could be made directly to an explicitly identified Posture Assessment Information Provider (P or Provider), but a Consumer may also desire to obtain the information without  having to know the available providers.</t>
        
        <t>There may be instances where a Consumer may be requesting information from various Providers and due to its policy or application requirements may need to be better informed of the Providers and their capabilities.  In those use cases, a Consumer may also request to discover the respective capabilities of those Providers.</t>
        
        <t>The Control Plane (described below) must authorize a Consumer to acquire the information it is requesting. The Consumer may also be subject to limits or constraints on the numbers, types, sizes, and rate of requests.</t>
        </section>
        
	 <section anchor="provider" title="Posture Assessment Information Provider">
         <t>The Posture Assessment Information Provider (P or Provider) is the component that contributes Posture Assessment Information either spontaneously or in response to a request.  A Provider can be a Posture Evaluator, Posture Collector, or an application that has aggregated Posture Assessment Information that can be shared.</t>
         
         <t>The Provider defines the capabilities and functions that must be handled to share or provide Posture Assessment information.  A Provider may provide the information spontaneously, or in response to a direct request from a Consumer.  The information may be filtered or truncated to honor the request either by the Consumer's request, or the Providers's ability to filter (or provide only a subset of the requested information) or due to security considerations (e.g. authorization restrictions due to domain segregation, privacy, etc.).</t>
         
         <t>The Provider may only be able to share the Posture Assessment Information using a specific data model and protocol. It may use a standard data model and/or protocol, a non-standard data model and/or protocol, or any combination of standard and non-standard data models and protocols. It may also choose to advertise its capabilities through a metadata abstraction.</t>
         
         <t>The Provider must be authorized to provide the Posture Assessment Information and further, be authorized to do so with the specific data models and protocols.</t>
         </section>
    
    <section anchor="controller" title="Control Plane">
        <t>The Control Plane may be an abstracted component but is distinctly defined as a component to execute on some of the security functions and overall system functions.  Some of the functions include:</t>
        
    <t><list hangIndent="1" style="hanging">
        <t hangText="Authentication:"> with use cases where Consumers may request information independent of knowing the identities of the Providers and Providers may want to share the information unsolicited, the architecture must account for an abstraction where a control plane or a broker may be defined to affect the authentication of the Consumers and Providers independent of the actual information sharing communication channel.</t>
        
        <t hangText="Authorization:"> to address security for how Posture Assessment Information is shared between the Consumers and Providers, at minimum a management function to define those policies are needed.  However, with the introduction of the control plane with use cases where R's may request information independent of knowing the identities of the P's and Providers (P's) wanting to share the information unsolicited, the architecture must account for an abstraction where a control plane or a broker may be defined to affect the authentication of the R's and P's independent of the actual information sharing communication channel.</t>
        
        <t hangText="Identity Management:">  As typically, Identity Management for authentication and
        authorization policies are best defined through a centralized
        component, the Control Plane also provides those services. </t>
        
        <t hangText="Discovery/Registration:"> a discovery mechanism is required to facilitate the interaction of Providers that may have different Posture Assessment Information and potentially limited (or a rich set) of ways in which they can share the information; that is, through the discovery mechanism Consumers can have visibility of the Providers present and the type(s) of Posture Assessment Information that is available and how it can be requested.  Similarly, a Provider may need to register its "capability" for the Posture Assessment Information it can share and how it can share it (e.g. protocol or with filtering capabilities).  Enabling this function through a broker or control plane also allows for the distinct definition of security considerations (e.g. authorized registration of capabilities and of Providers) beyond how a Provider may define its own capability.</t>
    </list></t>
    
    <t>The Control Plane also helps define how to manage an overall SACM system that allows for Consumers to obtain the desired Posture Assessment Information without the need to distinctly know and establish a one (Consumers) to many (Provider) connections.  Note that the Control Plane also allows for the direct discovery and connection between a Consumer and Provider.</t>
    
        </section>
    
    <section anchor="interface" title="Interfaces between Consumers, Providers and Control Plane">
        <t> As shown in Figure 1, communication can proceed with the following interfaces and expected functions and behaviors:</t>
        <t><list hangIndent="1" style="hanging">
            <t hangText="A:"> interface "A" shown in Figure 1 demonstrates the ability and desire for Consumers and Providers to be able to communicate directly when a Provider is sharing Posture Assessment Information directly to a Consumer. The interface allows for the different data models and protocols to be used between a Consumer and a Provider with the expectation that the appropriate authentication and authorization mechanisms have been employed to establish a secure communication link between the  Consumer and the Provider.  Typically, it is expected that the secure link establishment occurs as a management or control function through the abstracted control plane component (e.g. the control plane could be a proxy or could be embedded in a Consumer or a Provider).</t>
            
             <t hangText="B:"> interface "B" shown in Figure 1 handles the management and control functions that are needed to establish, at minimum, a secure communication between Consumers and Providers.  The interface must also handle the functions to allow for the discovery and registration of the Providers as well as the ways in which Posture Assessment Information can be provided (or requested).</t>
             
             
             <t hangText="C:"> interface "C" shown in Figure 1 enables Providers to share their Posture Assessment Information spontaneously; similarly, it enables Consumers to request information without having to know the identities (or reachability) of all the Providers that can fulfill Consumers' requests.</t>
            </list></t>
        </section>
       </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Jessica Fitzgerald-McKay, Trevor Freeman, Jim Bieda and Adam Montville for participating in the architecture
        design discussions that lead to this draft.</t>


    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

          </section>

    <section anchor="Security" title="Security Considerations">
	<t>TBD.  This section will need to cover the AAA and confidentiality/integrity of the data and data transports to be considered.  Also, the considerations for the interfaces (which may be covered in transports) between the Consumers, Providers, and the Control Plane.</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">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC2119;
      &I-D.ietf-sacm-use-cases;
      &I-D.ietf-sacm-terminology;
     
    </references>
     
    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &RFC5209;
      &RFC3444;
     
    </references>



    <!-- Change Log

v00 2014-06-16  NCW   Initial version
     -->
  </back>
</rfc>
