draft-ietf-sacm-arch.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.16 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-sacm-arch-14" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.11.1 -->
  <front>
    <title abbrev="SACM Architecture">Security Automation and Continuous Monitoring (SACM) Architecture</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-arch-14"/>
    <author initials="A." surname="Montville" fullname="Adam W. Montville">
      <organization abbrev="CIS">Center for Internet Security</organization>
      <address>
        <postal>
          <street>31 Tech Valley Drive</street>
          <city>East Greenbush</city>
          <region>NY</region>
          <code>12061</code>
          <country>USA</country>
        </postal>
        <email>adam.montville.sdo@gmail.com</email>
      </address>
    </author>
    <author initials="B." surname="Munyan" fullname="Bill Munyan">
      <organization abbrev="CIS">Center for Internet Security</organization>
      <address>
        <postal>
          <street>31 Tech Valley Drive</street>
          <city>East Greenbush</city>
          <region>NY</region>
          <code>12061</code>
          <country>USA</country>
        </postal>
        <email>bill.munyan.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="November" day="04"/>
    <area>Security</area>
    <workgroup>SACM Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document defines an architecture enabling a cooperative Security Automation and Continuous Monitoring (SACM) ecosystem.  This work is predicated upon information gleaned from SACM Use Cases and Requirements (<xref target="RFC7632" format="default"/> and <xref target="RFC8248" format="default"/> respectively), and terminology as found in <xref target="I-D.ietf-sacm-terminology" format="default"/>.</t>
      <t>WORKING GROUP: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/sacmwg/ietf-mandm-sacm-arch/.  Instructions are on that page as well.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The purpose of this draft is to define an architectural approach for a SACM Domain, based on the spirit of use cases found in <xref target="RFC7632" format="default"/> and requirements found in <xref target="RFC8248" format="default"/>. This approach gains the most advantage by supporting a variety of collection systems, and intends to enable a cooperative ecosystem of tools from disparate sources with minimal operator configuration.</t>
      <section anchor="requirements-notation" numbered="true" toc="default">
        <name>Requirements notation</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 <xref target="RFC2119" format="default"/>.</t>
      </section>
    </section>
    <section anchor="terms-and-definitions" numbered="true" toc="default">
      <name>Terms and Definitions</name>
      <dl>
        <dt>
Assessment:  </dt>
        <dd>
          <t>Defined in <xref target="RFC5209" format="default"/> as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy."</t>
        </dd>
        <dt>
Asset:  </dt>
        <dd>
          <t>Is a system resource, as defined in <xref target="RFC4949" format="default"/>, that may be composed of other assets.</t>
        </dd>
        <dt/>
        <dd>
          <t>Examples of Assets include: Endpoints, Software, Guidance, or X.509 public key certificates. An asset is not necessarily owned by an organization.</t>
        </dd>
        <dt>
Asset Management:  </dt>
        <dd>
          <t>The IT process by which assets are provisioned, updated, maintained and deprecated.</t>
        </dd>
        <dt>
Attribute:  </dt>
        <dd>
          <t>Is a data element, as defined in <xref target="RFC5209" format="default"/>, that is atomic.</t>
        </dd>
        <dt/>
        <dd>
          <t>In the context of SACM, attributes are "atomic" information elements and an equivalent to attribute-value-pairs.  Attributes can be components of Subjects.</t>
        </dd>
        <dt>
Capability:  </dt>
        <dd>
          <t>A set of features that are available from a SACM Component.</t>
        </dd>
        <dt/>
        <dd>
          <t>See also "capability" in <xref target="I-D.ietf-i2nsf-terminology" format="default"/>.</t>
        </dd>
        <dt>
Collector:  </dt>
        <dd>
          <t>A piece of software that acquires information about one or more target endpoints by conducting collection tasks.</t>
        </dd>
        <dt/>
        <dd>
          <t>A collector can be distributed across multiple endpoints, e.g. across a target endpoint and a SACM component.  The separate parts of the collector can communicate with a specialized protocol, such as PA-TNC [RFC5792].  At least one part of a distributed collector has to take on the role of a provider of information by providing SACM interfaces to propagate capabilities and to provide SACM content in the form of collection results.</t>
        </dd>
        <dt>
Configuration:  </dt>
        <dd>
          <t>A non-volatile subset of the endpoint attributes of a endpoint that is intended to be unaffected by a normal reboot-cycle.</t>
        </dd>
        <dt/>
        <dd>
          <t>Configuration is a type of imperative guidance that is stored in files (files dedicated to contain configuration and/ or files that are software components), directly on block devices, or on specific hardware components that can be accessed via corresponding software components.  Modification of configuration can be conducted manually or automatically via management (plane) interfaces that support management protocols, such as SNMP or WMI. A change of configuration can occur during both run-time and down- time of an endpoint.  It is common practice to scheduled a change of configuration during or directly after the completion of a boot-cycle via corresponding software components located on the target endpoint itself.</t>
        </dd>
        <dt>
Consumer:  </dt>
        <dd>
          <t>A SACM Role that requires a SACM Component to include SACM Functions enabling it to receive information from other SACM Components.</t>
        </dd>
        <dt>
Endpoint:  </dt>
        <dd>
          <t>Defined in <xref target="RFC5209" format="default"/> as "any computing device that can be connected to a network."</t>
        </dd>
        <dt/>
        <dd>
          <t>Additional Information - The <xref target="RFC5209" format="default"/> definition continues, "Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network.  This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."</t>
        </dd>
        <dt/>
        <dd>
          <t>To further clarify the <xref target="RFC5209" format="default"/> definition, an endpoint is any physical or virtual device that may have a network address.  Note that, network infrastructure devices (e.g. switches, routers, firewalls), which fit the definition, are also considered to be endpoints within this document.</t>
        </dd>
        <dt/>
        <dd>
          <t>Physical endpoints are always composites that are composed of hardware components and software components. Virtual endpoints are composed entirely of software components and rely on software components that provide functions equivalent to hardware components.</t>
        </dd>
        <dt/>
        <dd>
          <t>The SACM architecture differentiates two essential categories of endpoints: Endpoints whose security posture is intended to be assessed (target endpoints) and endpoints that are specifically excluded from endpoint posture assessment (excluded endpoints).</t>
        </dd>
        <dt/>
        <dd>
          <t>Based on the definition of an asset, an endpoint is a type of asset.</t>
        </dd>
        <dt>
Endpoint Attribute:  </dt>
        <dd>
          <t>Is a discreet endpoint characteristic that is computably observable.</t>
        </dd>
        <dt/>
        <dd>
          <t>Endpoint Attributes typically constitute Attributes that can be bundled into Subject (e.g. information about a specific network interface can be represented via a set of multiple AVP).</t>
        </dd>
        <dt>
Endpoint Characteristics:  </dt>
        <dd>
          <t>The state, configuration and composition of the software components and (virtual) hardware components a target endpoint is composed of, including observable behavior, e.g. sys-calls, log-files, or PDU emission on a network.</t>
        </dd>
        <dt/>
        <dd>
          <t>In SACM work-flows, (Target) Endpoint Characteristics are represented via Information Elements.</t>
        </dd>
        <dt>
Posture:  </dt>
        <dd>
          <t>Defined in <xref target="RFC5209" format="default"/> as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy."</t>
        </dd>
        <dt/>
        <dd>
          <t>This term is used within the scope of SACM to represent the configuration and state information that is collected from a target endpoint in the form of endpoint attributes (e.g. software/hardware inventory, configuration settings, dynamically assigned addresses).  This information may constitute one or more posture attributes.</t>
        </dd>
        <dt>
Posture Attributes:  </dt>
        <dd>
          <t>Defined in <xref target="RFC5209" format="default"/> as "attributes describing the configuration or status (posture) of a feature of the endpoint.  A Posture Attribute represents a single property of an observed state.  For example, a Posture Attribute might describe the version of the operating system installed on the system."</t>
        </dd>
        <dt/>
        <dd>
          <t>Within this document this term represents a specific assertion about endpoint configuration or state (e.g. configuration setting, installed software, hardware) represented via endpoint attributes.  The phrase "features of the endpoint" highlighted above refers to installed software or software components.</t>
        </dd>
        <dt>
Provider:  </dt>
        <dd>
          <t>A provider is a SACM role assigned to a SACM component that provides role-specific functions to provide information to other SACM components.</t>
        </dd>
        <dt>
Repository:  </dt>
        <dd>
          <t>A repository is a controller that contains functions to consume, store and provide information of a particular kind.</t>
        </dd>
        <dt/>
        <dd>
          <t>Such information is typically data transported on the data plane, but potentially also data and metadata from the control and management plane.  A single repository may provide the functions of more than one specific repository type (i.e. configuration baseline repository, assessment results repository, etc.)</t>
        </dd>
        <dt>
Security Automation:  </dt>
        <dd>
          <t>The process of which security alerts can be automated through the use of different components to monitor, analyze and assess endpoints and network traffic for the purposes of detecting misconfigurations, misbehaviors or threats.</t>
        </dd>
        <dt/>
        <dd>
          <t>Security Automation is intended to identify target endpoints that cannot be trusted (see "trusted" in <xref target="RFC4949" format="default"/>. This goal is achieved by creating and processing evidence (assessment statements) that a target endpoint is not a trusted system <xref target="RFC4949" format="default"/>.</t>
        </dd>
        <dt>
SIEM:  </dt>
        <dd>
          <t>NIST defines SIEM as an "application that provides the ability to gather security data from information system components and present that data as actionalbe information via a single interface" <xref target="NISTSIEM" format="default"/>.</t>
        </dd>
        <dt>
SOAR:  </dt>
        <dd>
          <t>Commonly known as Security Orchestration, Automation, and Response. SOAR is an holistic enterprise capability that exists when threat management, automation of security operations, and incident response are well-coordinated across all security program components in a manner minimizing the need for human intervention.</t>
        </dd>
        <dt>
State:  </dt>
        <dd>
          <t>A volatile set of endpoint attributes of a (target) endpoint that is affected by a reboot-cycle.</t>
        </dd>
        <dt/>
        <dd>
          <t>Local state is created by the interaction of components with other components via the control plane, via processing data plane payload, or via the functional properties of local hardware and software components. Dynamic configuration (e.g.  IP address distributed dynamically via an address distribution and management services, such as DHCP) is considered state that is the result of the interaction with another component (e.g. provided by a DHCP server with a specific configuration).</t>
        </dd>
        <dt>
Target Endpoint:  </dt>
        <dd>
          <t>Is an endpoint that is under assessment at some point in, or region of, time.</t>
        </dd>
        <dt/>
        <dd>
          <t>Every endpoint that is not specifically designated as an excluded endpoint is a target endpoint.  A target endpoint is not part of a SACM domain unless it contains a SACM component (e.g. a SACM component that publishes collection results coming from an internal collector).</t>
        </dd>
        <dt/>
        <dd>
          <t>A target endpoint is similar to a device that is a Target of Evaluation (TOE) as defined in Common Criteria and as referenced by <xref target="RFC4949" format="default"/>.</t>
        </dd>
        <dt>
Vulnerability Assessment:  </dt>
        <dd>
          <t>An assessment specifically tailored to determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information.</t>
        </dd>
        <dt>
Workflow:  </dt>
        <dd>
          <t>A workflow is a modular composition of tasks that can contain loops, conditionals, multiple starting points and multiple endpoints.</t>
        </dd>
        <dt/>
        <dd>
          <t>The most prominent workflow in SACM is the assessment workflow.</t>
        </dd>
      </dl>
      <t>--&gt;</t>
    </section>
    <section anchor="architectural-overview" numbered="true" toc="default">
      <name>Architectural Overview</name>
      <t>The generic approach proposed herein recognizes the need to obtain information from existing and future state collection systems, and makes every attempt to respect <xref target="RFC7632" format="default"/> and <xref target="RFC8248" format="default"/>. At the foundation of any architecture are entities, or components, that need to communicate. They communicate by sharing information, where, in a given flow, one or more components are consumers of information and one or more components are providers of information.  Different roles within a cooperative ecosystem may act as both Producers and Consumers of SACM-relevant information.</t>
      <figure anchor="fig-basic">
        <name>Basic Architectural Structure</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
       +----------------+
       | SACM Component |
       |   (Producer)   |
       +-------+--------+
               |
               |
+--------------v----------------+
|      Integration Service      |
+--------------+----------------+
               |
               |
       +-------v--------+
       | SACM Component |
       |   (Consumer)   |
       +----------------+
]]></artwork>
      </figure>
      <section anchor="producer" numbered="true" toc="default">
        <name>Producer</name>
        <t>A Producer can be described as an abstraction that refers to an entity capable of sending SACM-relevant information to one or many Consumers.  In general, information (a "payload") is produced to a particular topic, subscribed to by one or more Consumers.  Producers need not be concerned about any specifics of the payload it is providing to a given topic.  A Producer may, for example, publish posture collection instructions to collector topics.</t>
      </section>
      <section anchor="consumer" numbered="true" toc="default">
        <name>Consumer</name>
        <t>A Consumer can be described as an abstraction that refers to an entity capable of receiving SACM-relevant information from one or many Producers.  A Consumer acts as a subscriber to a given topic (or set of topics), enabling it to receive event notifications when a Producer provides a payload to that topic or topics.  Consumers receive payloads and act upon them according to their capabilities.  A Consumer may, for example, subscribe to a posture collection topic to receive and act upon, collection instructions.</t>
      </section>
      <section anchor="integration-service" numbered="true" toc="default">
        <name>Integration Service</name>
        <t>The Integration Service acts as the broker between Producers and Consumers; acting as the destination for Producers to publish payloads, and as the source for Consumers subscribing to those payloads.</t>
        <t>SACM Components are intended to interact with other SACM Components. These interactions can be thought of, at the architectural level, as the combination of interfaces with their supported operations.  Each interaction will convey a classified payload of information. This classification of payload information allows Consumers to subscribe to only the classifications to which they are capable of handling.  The payload information should contain subdomain-specific characteristics and/or instructions.</t>
      </section>
      <section anchor="payloadmessage" numbered="true" toc="default">
        <name>Payload/Message</name>
        <t>The payload (sometimes referred to as a "message" or "message payload") is the unit of data involved in any given interaction between two SACM components.  The payload MAY be used to convey the semantic meaning of the operation to be performed.  Protocols such as <xref target="RFC6120" format="default"/> achieves this meaning through XML namespace identification within a <tt>&lt;message/&gt;</tt> or <tt>&lt;iq/&gt;</tt> stanza.  Topic-centric protocols such as <xref target="MQTT" format="default"/> convey the meaning of payloads through topic naming techniques.  Both methods require connected components to verify message payloads according to their respective capabilities.</t>
        <t>With respect to the Integration Service, the payload is simply an array of bytes, so the data contained within it is not required to convey a specific format or meaning to the Integration Service.  The serialization of the payload combined with the payload categorization provides meaning within the SACM context.</t>
      </section>
      <section anchor="payload-categorization" numbered="true" toc="default">
        <name>Payload Categorization</name>
        <t>Within the SACM ecosystem, categorization of payloads and their transport provide the context through which various capabilities are achieved.  Two types of payload categorization can be described.</t>
        <section anchor="topic-centric" numbered="true" toc="default">
          <name>Topic-centric</name>
          <t>Topic-centric payload categorization allows for a broad spectrum of payloads by characterizing those payloads through the Integration Service topic.  In this categorization, the topic name becomes a label attached to the payload to which the Integration Service matches against known subscriptions.  The topic becomes the operational context for the payload.  Topic-centric categorization allows for any payload to be sent to any topic, but requires that SACM consumers parse the payloads to determine whether or not they have the capability to act on those payloads.</t>
          <t>When interacting using a topic-centric payload categorization, topic naming conventions SHOULD provide an adequate amount of information to be deterministic regarding the purpose of the interaction.  For example, a topic named <tt>/notification/collection/oval</tt> would indicate that (a) the topic is a broadcast/notification (publish/subscribe) topic, (b) subscribers to this topic are performing a "collection" action, and (c) the payloads published to the topic are represented using the OVAL serialization format.</t>
        </section>
        <section anchor="payload-centric" numbered="true" toc="default">
          <name>Payload-centric</name>
          <t>Payload-centric categorization encapsulates the intent of an interaction within the message payload itself, using an identifying token, tag, or namespace identifier.  This method allows for the limitation of message types, and therefore increases the extensibility of message payloads.</t>
          <t>Payload-centric categorization allows for modularization and specification of extensions, and for plugin-based support of capabilities based the categorization.  XMPP is an example of utilization of payload-centric categorization, allowing only three distinct "stanzas" (<tt>&lt;message/&gt;</tt>, <tt>&lt;presence/&gt;</tt>, and <tt>&lt;iq/&gt;</tt>), using payloads defined by the various extension protocols maintained by the XMPP standards foundation.</t>
        </section>
      </section>
      <section anchor="capabilities" numbered="true" toc="default">
        <name>Capabilities</name>
        <t>SACM components interact with each other based on their capacity to perform specific actions.  In advertising its capabilities, a SACM component indicates its competence to understand message payloads, perform any payload translation or normalization, and act upon that message.  For example, an Orchestration component receives a message to initiate posture attribute collection.  The Orchestrator may then normalize those instructions to a particular collection system's serialization.  The normalized instructions are then published to the Integration Service, notifying the appropriate subscribers.</t>
        <t>Capabilities are described using Uniform Resource Names (URNs), which will be maintained and enhanced via IANA tables (IANA Considerations). Using topic-centric categorization of message payloads, capability URNs SHOULD be associated with Integration Service topics to which publishers, subscribers, and service handlers, will interact.  Topic naming conventions are considered implementation details and are not considered for standardization.  Given a payload-centric categorization of message payloads, capability URNs SHOULD be used as the identifying token, tag, or namespace in order to distinguish specific payloads.</t>
      </section>
      <section anchor="interaction-categories" numbered="true" toc="default">
        <name>Interaction Categories</name>
        <t>Two categories of interactions SHOULD be supported by the Integration Service: broadcast and directed.  Broadcast interactions are asynchronous by default, and directed interactions may be invoked either synchronously or asynchronously.</t>
        <section anchor="broadcast" numbered="true" toc="default">
          <name>Broadcast</name>
          <t>A broadcast interaction, commonly referred to as publish/subscribe, allows for a wider distribution of a message payload.  When a payload is published to the Integration Service, all subscribers to that payload are alerted and may consume the message payload.  This category of interaction can also be described as a "unicast" interaction when only a single subscriber exists.  An example of a broadcast interaction could be to publish Linux OVAL objects to a posture collection topic.  Subscribing consumers receive the notification, and proceed to collect endpoint configuration posture based on the supplied message payload.</t>
        </section>
        <section anchor="directed" numbered="true" toc="default">
          <name>Directed</name>
          <t>The intent of a directed interaction is to enable point-to-point communications between a producer and consumer, through the standard interfaces provided by the Integration Service.  The provider component indicates which consumer is intended to receive the payload, and the Integration Service routes the payload directly to that consumer.  Two "styles" of directed interaction exist, differing only by the response from the consumer.</t>
          <section anchor="synchronous" numbered="true" toc="default">
            <name>Synchronous</name>
            <t>Synchronous, request/response style interaction requires that the requesting component block and wait for the receiving component to respond, or to time out when that response is delayed past a given time threshold.  A synchronous interaction example may be querying a CMDB for posture attribute information in order to perform an evaluation.</t>
          </section>
          <section anchor="asynchronous" numbered="true" toc="default">
            <name>Asynchronous</name>
            <t>An asynchronous interaction involves the payload producer directing the message to a consumer, but not blocking or waiting for an immediate response.  This style of interaction allows the producer to continue on to other activities without the need to wait for responses.  This style is particularly useful when the interaction payload invokes a potentially long-running task, such as data collection, report generation, or policy evaluation.  The receiving component may reply later via callbacks or further interactions, but it is not mandatory.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sacm-role-based-architecture" numbered="true" toc="default">
      <name>SACM Role-based Architecture</name>
      <t>Within the cooperative SACM ecosystem, a number of roles act in coordination to provide relevant policy/guidance, perform data collection, storage, evaluation, and support downstream analytics and reporting.</t>
      <figure anchor="fig-notional">
        <name>Notional Role-based Architecture</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 +-------------------------------------------+
 |                 Manager                   |
 +-------------------^-----------------------+
                     |
 +-----------------+ |  +--------------------+
 | Orchestrator(s) | |  |  Repository(-ies)  |
 +---------^-------+ |  +----------^---------+
           |         |             |                +--------------------+
           |         |             |                |  Downstream Uses   |
           |         |             |                | +----------------+ |
 +---------v---------v-------------v---------+      | |   Analytics    | |
 |             Integration Service           <------> +----------------+ |
 +-----------^--------------------------^----+      | +----------------+ |
             |                          |           | |   Reporting    | |
             |                          |           | +----------------+ |
 +-----------v-------------------+      |           +--------------------+
 |  Collection Sub-Architecture  |      |
 +-------------------------------+      |
                        +---------------v---------------+
                        |  Evaluation Sub-Architecture  |
                        +-------------------------------+
]]></artwork>
      </figure>
      <t>As shown in <xref target="fig-notional" format="default"/>, the SACM role-based architecture consists of some basic SACM Components communicating using an integration service. The integration service is expected to maximally align with the requirements described in <xref target="RFC8248" format="default"/>, which means that the integration service will support brokered (i.e. point-to-point) and proxied data exchange.</t>
      <section anchor="architectural-rolescomponents" numbered="true" toc="default">
        <name>Architectural Roles/Components</name>
        <t>This document suggests a variety of players in a cooperative ecosystem; known as SACM Components. SACM Components may be composed of other SACM Components, and each SACM Component plays one, or more, of several roles relevant to the ecosystem. Roles may act as providers of information, consumers of information, or both provider and consumer.  <xref target="fig-notional" format="default"/> depicts a number of SACM components which are architecturally significant and therefore warrant discussion and clarification. Each role depicted in <xref target="fig-notional" format="default"/> represents the interface to the component(s) fulfilling that role, not necessarily any specific implementation.  For example, the "Repository" figure represents the interface to persistent storage, and not any particular persistent storage mechanism.</t>
        <section anchor="manager" numbered="true" toc="default">
          <name>Manager</name>
          <t>The Manager acts as the control plane for the SACM ecosystem; a sort of high level component capable of coordinating the actions, notifications, and events between components.  The manager controls the administrative interfaces with the various components of the ecosystem, acting as the central point to which all other components will register and advertise their capabilities.  It is the responsibility of the manager to control a component's access to the ecosystem, maintain an inventory of components attached to the ecosystem, and to initiate the various workflows involved in the collection and/or evaluation of posture attributes.</t>
          <t>The manager should maintain the master set of capabilities that can be supported within the ecosystem.  These are the various collection, evaluation, and persistence capabilities with which components may register.  The manager MAY be responsible for assigning topics for each of the capabilities that are supported, as registering components subsequently subscribe to, or configure service handlers for, those topics.</t>
          <t>The manager may act as the user interface to the ecosystem, providing user dashboards, inventories, component management, or operational controls within the boundary of responsibility.</t>
        </section>
        <section anchor="orchestrators" numbered="true" toc="default">
          <name>Orchestrator(s)</name>
          <t>Orchestration components provide the manager with resources for delegating work across the SACM ecosystem.  Orchestrators are responsible for receiving messages from the manager, e.g. posture attribute collection instructions, and routing those messages to the appropriate "actions".  For example, an orchestrator may support the capability of translating posture collection instructions using the Open Vulnerability and Assessment Language (OVAL) and providing those instructions to OVAL collectors.  An orchestrator may support the capability of initiating policy evaluation.  Where the Manager is configured to ask a particular set of questions, those questions are delegated to Orchestrators, who are then capable of asking those questions using specific dialects.</t>
        </section>
        <section anchor="repositories" numbered="true" toc="default">
          <name>Repositories</name>
          <t><xref target="fig-notional" format="default"/> only includes a single reference to "Repository(-ies)", but in practice, a number of separate data repositories may exist, including posture attribute repositories, policy repositories, local vulnerability definition data repositories, and state assessment results repositories. The diagrammed notion of a repository within the SACM context represents an interface in which payloads are provided (based on the capabilities of the producer), normalized, and persisted.</t>
          <t>These data repositories may exist separately or together in a single representation, and the design of these repositories may be as distinct as their intended purpose, such as the use of relational database management systems (RDBMS), filesystem-based storage, or graph/map implementations.  Each implementation of a SACM repository should focus on the relationships between data elements and implement the SACM information and data model(s).</t>
        </section>
        <section anchor="integration-service-1" numbered="true" toc="default">
          <name>Integration Service</name>
          <t>If each SACM component represents a set of capabilities, then the Integration Service represents the "fabric" by which SACM components are woven together.  The Integration Service acts as a message broker, combining a set of common message categories and infrastructure to allow SACM components to communicate using a shared set of interfaces.  The Integration Service's brokering capabilities enable the exchange of various information payloads, orchestration of component capabilities, message routing, and reliable delivery (within reason - either with persistent messaging mechanisms or by utilizing a timeout after a configurable period of time).  The Integration Service minimizes the dependencies from one system to another through the loose coupling of applications through messaging.  SACM components will "attach" to the Integration Service either through native support for the integration implementation, or through the use of "adapters" which provide a proxied attachment.</t>
          <t>The Integration Service should provide mechanisms for both synchronous and asynchronous request/response-style messaging, and a publish/subscribe mechanism to implement an event-based architecture.  It is the responsibility of the Integration Service to coordinate and manage the sending and receiving of messages.  The Integration Service should allow components to directly connect and produce or consume messages, or connect via message translators which can act as a proxy, transforming messages from a component format to one implementing a SACM data model.</t>
          <t>The Integration Service MUST provide routing capabilities for payloads between producers and consumers.  The Integration Service MAY provide further capabilities within the payload delivery pipeline.  Examples of these capabilities include, but are not limited to, intermediate processing, message transformation, type conversion, validation, or other enterprise integration patterns.</t>
        </section>
      </section>
      <section anchor="downstream-uses" numbered="true" toc="default">
        <name>Downstream Uses</name>
        <t>As depicted by <xref target="fig-notional" format="default"/>, a number of downstream uses exist in the cooperative ecosystem.  Each notional SACM component represents distinct sub-architectures which will exchange information via the integration services, using interactions described in this draft.</t>
        <section anchor="reporting" numbered="true" toc="default">
          <name>Reporting</name>
          <t>The Reporting component represents capabilities outside of the SACM architecture scope dealing with the query and retrieval of collected posture attribute information, evaluation results, etc. in various display formats that are useful to a wide range of stakeholders.</t>
        </section>
        <section anchor="analytics" numbered="true" toc="default">
          <name>Analytics</name>
          <t>The Analytics component represents capabilities outside of the SACM architecture scope dealing with the discovery, interpretation, and communication of any meaningful patterns of data in order to inform effective decision making within the organization.</t>
        </section>
      </section>
      <section anchor="sub-architectures" numbered="true" toc="default">
        <name>Sub-Architectures</name>
        <t><xref target="fig-notional" format="default"/> shows two components representing sub-architectural roles involved in a cooperative ecosystem of SACM components for the purpose of posture assessment: Collection and Evaluation.</t>
        <section anchor="collection-sub-architecture" numbered="true" toc="default">
          <name>Collection Sub-Architecture</name>
          <t>The Collection sub-architecture is, in a SACM context, the mechanism by which posture attributes are collected from applicable endpoints and persisted to a repository, such as a configuration management database (CMDB).  Control plane functions initiated by the Manager will coordinate the necessary orchestration components, who will choreograph endpoint data collection via defined interactions, using the Integration Service as a message broker.  Instructions to perform endpoint data collection are directed to a Posture Collection Service capable of performing collection activities utilizing any number of protocols, such as SNMP, NETCONF/RESTCONF, SCAP, SSH, WinRM, packet capture, or host-based.  Instructions are orchestrated with the appropriate Posture Collection Services using serializations supported according to the collector's capabilities.</t>
          <figure anchor="fig-collection">
            <name>Decomposed Collection Sub-Architecture</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
  +----------------------------------------------------------+
  |                       Manager                            |
  +-----------+----------------------------------------------+
              |
          Orchestrate
          Collection
              |
  +-----------v-------------+ +------------------------------+
  |      Orchestrator(s)    | | Posture Attribute Repository |
  +-----------+-------------+ +--------------^---------------+
              |                              |
           Perform                           |
          Collection                  Collected Data
              |                              ^
              |                              |
  +-----------v------------------------------+---------------+
  |                    Integration Service                   |
  +----+------------------^------------------------------^---+
       |                  |           |                  |
       v                  +           v                  |
    Perform           Collected    Perform           Collected
   Collection           Data      Collection           Data
       |                  ^           |                  ^
       |                  |           |                  |
  +----v-----------------------+ +------------------------------+
  | Posture Collection Service | |    |     Endpoint     |      |
  +---^------------------------+ | +--v------------------+----+ |
      |                   |      | |Posture Collection Service| |
      |                   |      | +--------------------------+ |
    Events             Queries   +------------------------------+
      ^                   |          (PCS resides on Endpoint)
      |                   |
  +---+-------------------v----+
  |          Endpoint          |
  +----------------------------+
(PCS does not reside on Endpoint)

]]></artwork>
          </figure>
          <section anchor="posture-collection-service" numbered="true" toc="default">
            <name>Posture Collection Service</name>
            <t>The Posture Collection Service (PCS) is a SACM component responsible for the collection of posture attributes from an endpoint or set of endpoints.  A single PCS MAY be responsible for management of posture attribute collection from many endpoints.  The PCS will interact with the Integration Service to receive collection instructions, and to provide collected posture attributes for persistence to one or more Posture Attribute Repositories.  Collection instructions may be supplied in a variety of forms, including subscription to a publish/subscribe topic to which the Integration Service has published instructions, or via request/response-style messaging (either synchronous or asynchronous).</t>
            <t>Four classifications of posture collections MAY be supported.</t>
            <section anchor="ad-hoc" numbered="true" toc="default">
              <name>Ad-Hoc</name>
              <t>Ad-Hoc collection is defined as a single colletion of posture attributes, collected at a particular time.  An example of ad-hoc collection is the single collection of a specific registry key.</t>
            </section>
            <section anchor="continuousscheduled" numbered="true" toc="default">
              <name>Continuous/Scheduled</name>
              <t>Continuous/Scheduled collection is defined as the ongoing, periodic collection of posture attributes.  An example of scheduled collection is the collection of a specific registry key value every day at a given time.</t>
            </section>
            <section anchor="observational" numbered="true" toc="default">
              <name>Observational</name>
              <t>This classification of collection is triggered by the observation, external to an endpoint, of information asserting posture attribute values for that endpoint.  An example of observational collection is examination of netflow data for particular packet captures and/or specific information within those captures.</t>
            </section>
            <section anchor="event-based" numbered="true" toc="default">
              <name>Event-based</name>
              <t>Event-based collection may be triggered either internally or externally to the endpoint.  Internal event-based collection is triggered when a posture attribute of interest is added, removed, or modified on an endpoint.  This modification indicates a change in the current state of the endpoint, potentially affecting its adherence to some defined policy.  Modification of the endpoint's minimum password length is an example of an attribute change which could trigger collection.</t>
              <t>External event-based collection can be described as a collector being subscribed to an external source of information, receiving events from that external source on a periodic or continuous basis.  An example of event-based collection is subscription to YANG Push notifications.</t>
            </section>
          </section>
          <section anchor="endpoint" numbered="true" toc="default">
            <name>Endpoint</name>
            <t>Building upon <xref target="I-D.ietf-sacm-terminology" format="default"/>, the SACM Collection Sub-Architecture augments the definition of an Endpoint as a component within an organization's management domain from which a Posture Collection Service will collect relevant posture attributes.</t>
          </section>
          <section anchor="posture-attribute-repository" numbered="true" toc="default">
            <name>Posture Attribute Repository</name>
            <t>The Posture Attribute Repository is a SACM component responsible for the persistent storage of posture attributes collected via interactions between the Posture Collection Service and Endpoints.</t>
          </section>
          <section anchor="posture-collection-workflow" numbered="true" toc="default">
            <name>Posture Collection Workflow</name>
            <t>Posture collection may be triggered from a number of components, but commonly begin either via event-based triggering on an endpoint or through manual orchestration, both illustrated in <xref target="fig-collection" format="default"/> above.  Once orchestration has provided the directive to perform collection, posture collection services consume the directives.  Posture collection is invoked for those endpoints overseen by the respective posture collection services.  Collected data is then provided to the Integration Service, with a directive to store that information in an appropriate repository.</t>
          </section>
        </section>
        <section anchor="evaluation-sub-architecture" numbered="true" toc="default">
          <name>Evaluation Sub-Architecture</name>
          <t>The Evaluation Sub-Architecture, in the SACM context, is the mechanism by which policy, expressed in the form of expected state, is compared with collected posture attributes to yield an evaluation result, that result being contextually dependent on the policy being evaluated.</t>
          <figure anchor="fig-evaluation">
            <name>Decomposed Evaluation Sub-Architecture</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
+------------------+
|     Manager      |
+-------+----------+
        |
   Orchestrate        +------------------+
    Evaluation        |    Collection    |    +-------------------------------+
        |             | Sub+Architecture |    | Evaluation Results Repository |
 +------v----------+  +--------^---------+    +-----------------^-------------+
 | Orchestrator(s) |           |                                |
 +------+----------+     (Potentially)                          |
        |                   Perform                 Store Evaluation Results
     Perform               Collection                           |
    Evaluation                 |                                |
        |                      |                                |
 +------v----------------------v--------------------------------+-------------+
 |                             Integration Service                            |
 +--------^----------------------^-----------------------^--------------------+
          |                      |                       |
          |                      |                       |
          |               Retrieve Posture            Perform
   Retrieve Policy           Attributes              Evaluation
          |                      |                       |
          |                      |                       |
   +------v-----+          +-----v------+       +--------v-------------------+
   |   Policy   |          |  Posture   |       | Posture Evaluation Service |
   | Repository |          | Attribute  |       +----------------------------+
   +------------+          | Repository |
                           +------------+

]]></artwork>
          </figure>
          <section anchor="posture-evaluation-service" numbered="true" toc="default">
            <name>Posture Evaluation Service</name>
            <t>The Posture Evaluation Service (PES) represents the SACM component responsible for coordinating the policy to be evaluated and the collected posture attributes relevant to that policy, as well as the comparison engine responsible for correctly determining compliance with the expected state.</t>
          </section>
          <section anchor="policy-repository" numbered="true" toc="default">
            <name>Policy Repository</name>
            <t>The Policy Repository represents a persistent storage mechanism for the policy to be assessed against collected posture attributes to determine if an endpoint meets the desired expected state.  Examples of information contained in a Policy Repository would be Vulnerability Definition Data or configuration recommendations as part of a CIS Benchmark or DISA STIG.</t>
          </section>
          <section anchor="evaluation-results-repository" numbered="true" toc="default">
            <name>Evaluation Results Repository</name>
            <t>The Evaluation Results Repository persists the information representing the results of a particular posture assessment, indicating those posture attributes collected from various endpoints which either meet or do not meet the expected state defined by the assessed policy.  Consideration should be made for the context of individual results.  For example, meeting the expected state for a configuration attribute indicates a correct configuration of the endpoint, whereas meeting an expected state for a vulnerable software version indicates an incorrect configuration.</t>
          </section>
          <section anchor="posture-evaluation-workflow" numbered="true" toc="default">
            <name>Posture Evaluation Workflow</name>
            <t>Posture evaluation is orchestrated through the Integration Service to the appropriate Posture Evaluation Service (PES).  The PES will, using interactions defined by the applicable taxonomy, query both the Posture Attribute Repository and the Policy Repository to obtain relevant state data for comparison.  If necessary, the PES may be required to invoke further posture collection.  Once all relevant posture information has been collected, it is compared to expected state based on applicable policy.  Comparison results are then persisted to an evaluation results repository for further downstream use and analysis.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="ecosystem-interactions" numbered="true" toc="default">
      <name>Ecosystem Interactions</name>
      <t>Ecosystem interactions describe the various functions between SACM components, including manager requirements, the onboarding of components, capability advertisement, administrative actions, and status updates, among others. The Manager component acts as the administrative "lead" for the SACM ecosystem, and must maintain records of registered components, manage capabilities, and more.</t>
      <section anchor="manager-1" numbered="true" toc="default">
        <name>Manager</name>
        <t>The Manager, being a specialized role in the architecture, enables the onboarding and capability management of the various SACM component roles.  The Manager must support the set of capabilities needed to operate the SACM ecosystem.</t>
        <t>With this in mind, the Manager must first authenticate to the Integration Service.  Once authentication has succeeded, the Manager MUST establish a service handler capable of performing SACM component registration/onboarding activities (Component Registration Operation).  The Manager MUST also establish a subscription to an ecosystem-wide status notification mechanism,  in order to receive published status updates from other SACM components.</t>
        <t>The following requirements exist for the Manager to establish service handlers supporting the component registration taxonomy (Component Registration Operation):</t>
        <ul spacing="normal">
          <li>The Manager MUST enable the capability to receive onboarding requests,</li>
          <li>The Manager MUST have the capability to generate, manage, and persist unique identifiers for all registered components,</li>
          <li>The Manager MUST maintain the relationships between capabilities and payload categorizations (such as topic names or specific payload identifiers),</li>
          <li>The Manager MUST have the capability to inventory and manage its "roster" (the list of registered components),</li>
          <li>The Manager MUST have the capability to manage its roster's advertised capabilities, including those endpoints to which those capabilities apply.</li>
          <li>In addition to supporting component registration, the Manager is responsible for many of the operational functions of the architecture, including initiating collection or evaluation, queries for repository data, or the assembly of information for downstream use.</li>
          <li>The Manager MUST support making directed requests to registered components over the component's administrative interface.  Administrative interface functions are described by their taxonomy, below.</li>
          <li>The Manager MUST support each of the interaction categories as described above.</li>
        </ul>
      </section>
      <section anchor="component-registration" numbered="true" toc="default">
        <name>Component Registration</name>
        <t>Component registration describes how an individual component becomes part of the SACM ecosystem; authenticating to the Integration Service, registering and establishing its administrative interface with, the Manager.</t>
        <t>The component onboarding workflow involves multiple steps:</t>
        <ul spacing="normal">
          <li>The component first authenticates to the Integration Service.</li>
          <li>The component initiates registration with the Manager, per the component registration operation (Component Registration Operation).</li>
          <li>The component handles the response from the Manager to configure a service handler allowing the component to receive directed messages over the  administrative interface with the Manager.</li>
        </ul>
      </section>
      <section anchor="administrative-interface" numbered="true" toc="default">
        <name>Administrative Interface</name>
        <t>The administrative interface represents a direct communication channel between the Manager and any registered Component.  This interface allows the Manager to make directed requests to a component in order to perform specific actions.</t>
        <section anchor="capability-advertisement-handshake" numbered="true" toc="default">
          <name>Capability Advertisement Handshake</name>
          <t>Capability Advertisement is the mechanism by which components initially indicate their capabilities to the Manager. This handshake is completed using the administrative interface with the Manager.  It becomes the Manager's responsibility to persist component/capability relationships, and to provide the component the information necessary to receive and process message payloads specific to the supported capabilities.</t>
        </section>
        <section anchor="health-check" numbered="true" toc="default">
          <name>Health Check</name>
          <t>The administrative "health check" is a mechanism by which the Manager queries for the "liveness" of its roster of components, and to possibly alert users or other systems when components are no longer present.  The Manager MAY enable a periodic message to each component to determine if that component is still listening to the Administrative Interface. The Health Check interaction MAY include a request for "Capability Refresh", to reinitiate the Capability Advertisement Handshake. This interaction is similar to the "Heartbeat" interaction, but is initiated by the Manager.</t>
        </section>
        <section anchor="heartbeat" numbered="true" toc="default">
          <name>Heartbeat</name>
          <t>The administrative "heartbeat" is a mechanism by which a Component indicates to the Manager that the Component remains connected to the ecosystem. The Heartbeat differs from the Health Check interaction in that the Component initiates the interaction, and that no response from the Manager is required.</t>
        </section>
        <section anchor="capability-specific-requests" numbered="true" toc="default">
          <name>Capability-specific Requests</name>
          <t>Any number of capability-specific requests can be enabled through the administrative interface that allow the Manager to direct actions to be performed by a specific component.  Utilizing the interface from a component to the Manager, this interface can be used to indicate a component has come back online, or to provide an updated capability advertisement, potentially resulting in updates to subscriptions or service handlers.</t>
        </section>
      </section>
      <section anchor="status-notifications" numbered="true" toc="default">
        <name>Status Notifications</name>
        <t>A generic status notifications mechanism SHOULD be configured to which (a) the Manager is subscribed, and (b) all onboarded components can publish.  Status notifications may be used by the Manager to update user interfaces, to provide notification of the start, finish, success or failure of ecosystem operations, or as events to trigger subsequent activities.</t>
      </section>
      <section anchor="component-interactions" numbered="true" toc="default">
        <name>Component Interactions</name>
        <t>Component interactions describe functionality between components relating to collection, evaluation, or other downstream processes.  The following component interactions begin with the Manager providing a set of instructions to an Orchestrator or set of Orchestrators that have registered with the SACM ecosystem indicating the appropriate capabilities, such as collection or evaluation.  Subscribing Orchestrator(s) MAY translate, manipulate, filter, augment, or otherwise transform the Manager's instructions into content supported through the Orchestrator's capabilities.</t>
        <section anchor="initiate-ad-hoc-collection" numbered="true" toc="default">
          <name>Initiate Ad-Hoc Collection</name>
          <t>The Orchestrator supplies a payload of collection instructions to a Posture Collection Service either through direct or broadcast mechanisms.  The receiving PCS components perform the required collection based on their capabilities.  Each PCS then forms a payload of collected posture attributes (including endpoint identifying information) and provides that payload to the Posture Attribute Repository interface, for persistence.</t>
        </section>
        <section anchor="coordinate-periodic-collection" numbered="true" toc="default">
          <name>Coordinate Periodic Collection</name>
          <t>Similar to ad-hoc collection, the Orchestrator supplies a payload of collection instructions similar to those of ad-hoc collection.  Additional information elements containing collection identification and periodicity are included.</t>
          <section anchor="schedule-periodic-collection" numbered="true" toc="default">
            <name>Schedule Periodic Collection</name>
            <t>To enable operations on periodic collection, the scheduling payload MUST include both a unique identifier for the set of collection instructions, as well as a periodicity expression to enable the collection schedule.  An optional "immediate collection" flag will indicate to the collection component that, upon receipt of the collection instructions, a collection will automatically be initiated prior to engagement of the scheduled collection.</t>
          </section>
          <section anchor="cancel-periodic-collection" numbered="true" toc="default">
            <name>Cancel Periodic Collection</name>
            <t>The Orchestrator disables the periodic collection of posture attributes by supplying collector(s) the unique identifier of previously scheduled collection instructions.  An optional "final collection" flag will indicate to the collection component that, upon receipt of the cancellation instructions, a final ad-hoc collection is to take place.</t>
          </section>
        </section>
        <section anchor="coordinate-observationalevent-based-collection" numbered="true" toc="default">
          <name>Coordinate Observational/Event-based Collection</name>
          <t>In these scenarios, the Posture Collection Service acts as the "observer".  Interactions with the observer could specify a time period of observation and potentially information intended to filter observed posture attributes to aid the PCS in determining those attributes that are applicable for collection and persistence to the Posture Attribute Repository.</t>
          <section anchor="initiate-observationalevent-based-collection" numbered="true" toc="default">
            <name>Initiate Observational/Event-based Collection</name>
            <t>The Orchestrator supplies a payload of instructions to a topic or set of topics to which Posture Collection Services (observers) are subscribed.  This payload could include specific instructions based on the observer's capabilities to determine specific posture attributes to observe and collect.</t>
          </section>
          <section anchor="cancel-observationalevent-based-collection" numbered="true" toc="default">
            <name>Cancel Observational/Event-based Collection</name>
            <t>The Orchestrator supplies a payload of instructions to a topic or set of topics to which Posture Collection Services are subscribed.  The receiving PCS components cancel the identified observational/event-based collection executing on those PCS components.</t>
          </section>
        </section>
        <section anchor="persist-collected-posture-attributes" numbered="true" toc="default">
          <name>Persist Collected Posture Attributes</name>
          <t>Following successful collection, Posture Collection Services (PCS) will supply the payload of collected posture attributes to the interface(s) supporting the persistent storage of those attributes to the Posture Attribute Repository.  Information in this payload should include identifying information of the computing resource(s) for which attributes were collected.</t>
        </section>
        <section anchor="initiate-ad-hoc-evaluation" numbered="true" toc="default">
          <name>Initiate Ad-Hoc Evaluation</name>
          <t>The Orchestrator supplies a payload of evaluation instructions to a Posture Evaluation Services (PES) either through direct or broadcast mechanisms.  The receiving PES components perform the required evaluation based on their capabilities.  The PES generates a payload of posture evaluation results and publishes that payload to the Evaluation Results Repository interface, for persistence.</t>
        </section>
        <section anchor="coordinate-periodic-evaluation" numbered="true" toc="default">
          <name>Coordinate Periodic Evaluation</name>
          <t>Similar to ad-hoc evaluation, the Orchestrator supplies a payload of evaluation instructions similar to those of ad-hoc evaluation.  Additional information elements containing evaluation identification and periodicity are included.</t>
          <section anchor="schedule-periodic-evaluation" numbered="true" toc="default">
            <name>Schedule Periodic Evaluation</name>
            <t>To enable operations on periodic evaluation, the scheduling payload MUST include both a unique identifier for the set of evaluation instructions, as well as a periodicity expression to enable the evaluation schedule.  An optional "immediate evaluation" flag will indicate to the Posture Evaluation Service (PES) that, upon receipt of the evaluation instructions, an evaluation will automatically be initiated prior to engagement of the scheduled evaluation.</t>
          </section>
          <section anchor="cancel-periodic-evaluation" numbered="true" toc="default">
            <name>Cancel Periodic Evaluation</name>
            <t>The Orchestrator disables the periodic evaluation of posture attributes by supplying Posture Evaluation Service(s) the unique identifier of previously scheduled evaluation instructions.  An optional "final evaluation" flag will indicate to the PES that, upon receipt of the cancellation instructions, a final ad-hoc evaluation is to take place.</t>
          </section>
        </section>
        <section anchor="coordinate-change-based-evaluation" numbered="true" toc="default">
          <name>Coordinate Change-based Evaluation</name>
          <t>A more fine-grained approach to periodic evaluation may be enabled through the triggering of Posture Evaluation based on changes to posture attribute values at the time of their collection and persistence to the Posture Attribute Repository.</t>
          <section anchor="identify-attributes" numbered="true" toc="default">
            <name>Identify Attributes</name>
            <t>The Orchestrator enables change-based evaluation through a payload published to Posture Attribute Repository component(s).  This payload includes appropriate information elements describing the posture attributes on which changes in value will trigger posture evaluation.</t>
          </section>
          <section anchor="cancel-change-based-evaluation" numbered="true" toc="default">
            <name>Cancel Change-based Evaluation</name>
            <t>An Orchestrator may disable change-based evaluation through a payload published to Posture Attribute Repository component(s), including those information elements necessary to identify those posture attributes for which change-based evaluation no longer applies.</t>
          </section>
        </section>
        <section anchor="queries" numbered="true" toc="default">
          <name>Queries</name>
          <t>Queries should allow for a "freshness" time period, allowing the requesting entity to determine if/when posture attributes must be re-collected prior to performing evaluation.  This freshness time period can be "zeroed out" for the purpose of automatically triggering re-collection regardless of the most recent collection.</t>
        </section>
      </section>
    </section>
    <section anchor="operations" numbered="true" toc="default">
      <name>Operations</name>
      <t>The following sections describe a number of operations required to enable a cooperative ecosystem of posture attribute collection and evaluation functions.</t>
      <section anchor="component-registration-1" numbered="true" toc="default">
        <name>Component Registration</name>
        <t>Component registration describes how an individual component becomes part of the SACM ecosystem; registering with the Manager, and establishing the administrative interface.</t>
        <ul spacing="normal">
          <li>Interaction Type: Directed (Request/Response)</li>
          <li>Source Component: Any component wishing to join the ecosystem, such as Posture Collection Services, Repository Interfaces, Posture Evaluation Services and more.</li>
          <li>Target Component(s): Manager</li>
        </ul>
        <section anchor="request-payload" numbered="true" toc="default">
          <name>Request Payload</name>
          <t>When a component onboards with the ecosystem, it must identify itself to the Manager, using either descriptive information or an already-existing component unique identifier.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
component-registration-request:
  {:component-identification:}

component-identification:
  component-unique-identifier (if re-establishing communication)
    #-OR-#
  component-type {:component-type:}
  component-name
  component-description (optional)

component-type:
  enumeration:
    - posture-collection-service
    - posture-evaluation-service
    - repository-interface
    - orchestrator
    - others?
]]></artwork>
          <t>When registering for the first time, the component will send identifying information including the component type and a name.  If the component is re-establishing communications, for example after a restart of the component or deployment of a new version, the component only needs to supply its previously generated (and persisted) [component-unique-identifier].</t>
        </section>
        <section anchor="request-processing" numbered="true" toc="default">
          <name>Request Processing</name>
          <t>When the Manager receives the component's request for onboarding, it will:</t>
          <ul spacing="normal">
            <li>Generate a unique identifier, <tt>[component-unique-identifier]</tt>, for the onboarding component,</li>
            <li>Persist identifying information, including the <tt>[component-unique-identifier]</tt> to its component inventory, enabling an up-to-date roster of components being managed,</li>
            <li>Establish the administrative interface to the onboarded component by enabling a service handler to listen for directed messages from the component.</li>
          </ul>
        </section>
        <section anchor="response-payload" numbered="true" toc="default">
          <name>Response Payload</name>
          <t>The Manager will respond to the component with a payload including the component's unique identifier.  At this point, the Manager is aware of the component's existence in the ecosystem, and the component can self-identify by virtue of receiving its unique identifier.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
component-registration-response:
  component-unique-identifier: [component-unique-identifier]
]]></artwork>
        </section>
        <section anchor="response-processing" numbered="true" toc="default">
          <name>Response Processing</name>
          <t>Successful receipt of the Manager's response, including the <tt>[component-unique-identifier]</tt>, indicates the component is onboarded to the ecosystem.  Using the response payload, the component can then establish it's end of the administrative interface with the Manager.  The component must then persist it's unique identifier for use when re-establishing communication with the Manager after failure recovery or restart.</t>
        </section>
      </section>
      <section anchor="administrative-interface-1" numbered="true" toc="default">
        <name>Administrative Interface</name>
        <t>A number of functions may take place which, instead of being published to multiple subscribers, may require direct interaction between the Manager and a registered component (and vice-versa).  During component onboarding, this direct channel, known as the Administrative Interface, is established first by the Manager and subsequently complemented by the component onboarding the SACM ecosystem.  Three operations are defined for the administrative interface, but any number of application or capability-specific operations MAY be enabled using the directed messaging provided by this interface.</t>
        <section anchor="capability-advertisement-handshake-1" numbered="true" toc="default">
          <name>Capability Advertisement Handshake</name>
          <t>Capability advertisement represents the ability of any registered component to inform the Manager of that component's capacity for performing certain operations. For example, a Posture Collection Service component may advertise its capability to perform collection using a particular collection system/serialization.  This capability advertisement is important for the Manager to persist in order for the Manager to correctly classify components registered within the SACM ecosystem, and therefore provide the ability to publish messages to components in accordance with their capabilities.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response)</li>
            <li>Source Component: Any registered component, such as Posture Collection Services, Repository Interfaces, Posture Evaluation Services and more.</li>
            <li>Target Component(s): Manager</li>
          </ul>
          <section anchor="request-payload-1" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>The component's capability advertisement request payload will include a list of "Capability URNs" (TBD IANA SECTION) that represent it's supported operational capabilities.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
capability-advertisement:
  capabilities:
    capability-urn: [urn]
    capability-urn: [urn]
    capability-urn: [urn]
    ...
]]></artwork>
          </section>
          <section anchor="request-processing-1" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>Upon receipt of the component's capability advertisement, the Manager SHOULD:</t>
            <ul spacing="normal">
              <li>Persist the component's capabilities to the Manager's inventory</li>
              <li>Coordinate, based on the supplied capabilities, the service handlers (for directed messages) and/or event listeners (for broadcast messages) to which the component should support.</li>
            </ul>
          </section>
          <section anchor="response-payload-1" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>The response payload delivered to the component should include the appropriate service handling/event listening information required for the component to handle further interactions based on each advertised capability.  If a capability was not registered successfully, appropriate error messages SHOULD be supplied to inform the component of the failure(s).</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
capability-advertisement-response:
  capabilities:
    capability:
      capability-urn: [urn]
      registration-status: (success | failure)
      service-handler-or-event-listener: [info]
      messages: [messages]
    capability:
      capability-urn: [urn]
      registration-status: (success | failure)
      service-handler-or-event-listener: [info]
      messages: [messages]
]]></artwork>
          </section>
          <section anchor="response-processing-1" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>Once the component has received the response to its capability advertisement, it should configure the capability-specific service handler(s) or event listener(s). Once these handlers/listeners have been configured, the component is considered fully onboarded to the SACM ecosystem.</t>
          </section>
        </section>
        <section anchor="health-check-1" numbered="true" toc="default">
          <name>Health Check</name>
          <t>As time passes, it is important that the Manager maintains knowledge of all registered component's current operational status.  The health check operation describes the efforts taken by the Manager to maintain the most up-to-date inventory of it's component roster, and to potentially trigger events to users or outside systems (e.g. a SIEM or SOAR) indicating unavailable components.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response)</li>
            <li>Source Component: Manager</li>
            <li>Target Component(s): Any registered component, such as Posture Collection Services, Repository Interfaces, Posture Evaluation Services and more.</li>
          </ul>
          <section anchor="request-payload-2" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>The request for the health check is a simple "ping".</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
health-check-request:
  action: ping
]]></artwork>
          </section>
          <section anchor="request-processing-2" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>When the target component receives the health check request, the target component need only respond that it is operational and connected to the integration service.  This is a simple "Hello component, are you listening?  Yes, I am" interaction.  The health check request from the Manager should be made with an appropriately small timeout indicator; only an operational component will be able to respond to the request, so if that component is offline and cannot respond, the Manager should not be kept waiting for an extended amount of time.</t>
          </section>
          <section anchor="response-payload-2" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>When responding to the health check request, the response payload will simply indicate success:
~~~~~~
health-check-response:
  response: success
~~~~~~</t>
          </section>
          <section anchor="response-processing-2" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>Upon receipt of the "health-check-response" payload, the Manager will update its inventory of currently operational components with the timestamp of the receipt.  Manager implementations may raise alerts, inform users, or take other actions when health checks are unsuccessful, at their discretion.</t>
          </section>
        </section>
        <section anchor="heartbeat-1" numbered="true" toc="default">
          <name>Heartbeat</name>
          <t>As time passes and SACM ecosystem components which have previously registered are brought offline (perhaps for maintenance or redeployment) and back online, it is important that registered components maintain administrative contact with the Manager. The heartbeat operation describes the efforts taken by a registered component to determine the status of contact with the Manager, and to take appropriate action if such contact cannot be made.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response)</li>
            <li>Source Component: Any registered component, such as Posture Collection Services, Repository Interfaces, Posture Evaluation Services and more.</li>
            <li>Target Component(s): Manager</li>
          </ul>
          <section anchor="request-payload-3" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>The request payload simply defines the hearbeat action:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
heartbeat-request:
  action: pulse
]]></artwork>
          </section>
          <section anchor="request-processing-3" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>When the Manager receives the heartbeat request, it need only respond that it is operational and connected to the integration service.  This is a simple "Hello Manager, are you listening?  Yes, I am" interaction.  The heartbeat request from the component should be made with an appropriately small timeout indicator; only an operational Manager will be able to respond to the request, so if it is offline and cannot respond, the component should not be kept waiting for an extended amount of time.</t>
          </section>
          <section anchor="response-payload-3" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>When responding to the heartbeat request, the response payload will simply indicate success:
~~~~~~
heartbeat-response:
  response: success
~~~~~~</t>
          </section>
          <section anchor="response-processing-3" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>Upon receipt of the "heartbeat-response" payload, the component may reset its heartbeat timer and continue normal operations, awaiting incoming message payloads.  Component implementations may raise alerts, inform users, or take other actions when heartbeat requests are unsuccessful (potentially indicating a downed Manager), at their discretion.</t>
          </section>
        </section>
      </section>
      <section anchor="status-notification" numbered="true" toc="default">
        <name>Status Notification</name>
        <t>From time to time during the performance of any given operation, a component may need to supply status information to the Manager (or any other concerned component), for use in display to users, or to trigger other events within the SACM ecosystem.  The status notification operation is designed to allow any component to broadcast status message payloads to any subscribers with the need to know. For example, a collection component could broadcast to the Manager that it has initiated collection, subsequent collection progress updates, and finally completion or error conditions.</t>
        <ul spacing="normal">
          <li>Interaction Type: Broadcast (Publish/Subscribe)</li>
          <li>Source Component: Any registered component, such as Posture Collection Services, Repository Interfaces, Posture Evaluation Services and more.</li>
          <li>Target Component(s): Typically the Manager, but any registered component may subscribe to status notifications.</li>
        </ul>
        <section anchor="request-payload-4" numbered="true" toc="default">
          <name>Request Payload</name>
          <t>At a minimum, the payload broadcast for a status notification MUST include the status message and the publishing component's <tt>component-unique-identifier</tt>. Further identifying information, such as status codes, operation indicators, etc., MAY be provided by implementing components.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
status-notification:
  publisher: [component-unique-identifier]
  message: [message]
  [additional information]
]]></artwork>
        </section>
        <section anchor="request-processing-4" numbered="true" toc="default">
          <name>Request Processing</name>
          <t>When subscribers are notified of the status message, respective components may act upon them in component/application-specific ways, including persisting those messages to repositories, forwarding to log aggregation tools, displaying on user interfaces, and so on. Potential for use of component status notifications is only limited by application implementations.</t>
        </section>
        <section anchor="response-payload-4" numbered="true" toc="default">
          <name>Response Payload</name>
          <t>N/A</t>
        </section>
        <section anchor="response-processing-4" numbered="true" toc="default">
          <name>Response Processing</name>
          <t>N/A</t>
        </section>
      </section>
      <section anchor="initiate-ad-hoc-collection-1" numbered="true" toc="default">
        <name>Initiate Ad-Hoc Collection</name>
        <t>The Ad-hoc collection workflow MAY be initiated by the Manager, via user interaction, or through a Posture Evaluation Service, and represents a single, point-in-time operation to collect posture attributes from applicable endpoints.  The SACM Producer initiates a message payload, either through directed channels (such as the administrative interface) or through broadcast notifications to multiple subscribers, to Orchestrator components.  Orchestrators MAY manipulate the Manager's collection instructions according to various collection capabilities, prior to providing those instructions to Posture Collection Service (PCS) components.  Once collection instructions are received by the PCS, it will collect the requested posture attributes from the designated endpoints, using its advertised collection capabilities.  The following diagram illustrates this workflow with the Manager as the initiating SACM Producer:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 +-----------+                      +------------------------------+
 |  Manager  |                      |  Posture Collection Service  |
 +-+-----^---+                      +---^----------+----------+----+
   |     |                              |          |          |
 1.|    (S)                           4.|         (S)       5.|
   |     |                              |          |          |
   |     |                              |          |          |
 +-v-----+-----------------------------------------v----------v----+
 |                       Integration Service                       |
 +-+-----^------^----------------------------------^----------+----+
   |     |      |                                  |          |
 2.|    (S)     |3.                               (S)         |6.
   |     |      |                                  |          |
   |     |      |                                  |          |
 +-v-----+------+-+               +----------------+----------v----+
 |  Orchestrator  |               |  Posture Attribute Repository  |
 +----------------+               +--------------------------------+
]]></artwork>
        <ol spacing="normal" type="1"><li>The Manager initiates a request to one or more Orchestrators to perform collection,</li>
          <li>The Orchestrator receives collection instructions and potentially manipulates them according to one or more collection capabilities,</li>
          <li>The Orchestrator publishes a notification to subscribed Posture Collection Service components, indicating the posture attributes to be collected,</li>
          <li>The Posture Collection Service receives the collection instructions and performs the actual collection of posture attributes from an endpoint or endpoints.</li>
          <li>The Posture Collection Service publishes a notification(s) containing the collected posture attributes to be persisted to the Posture Attribute Repository,</li>
          <li>The Posture Attribute Repository persists the collected posture attributes, potentially performing normalization of the data as part of its process.</li>
        </ol>
        <t>Interactions labeled (S) indicate the capability of each component to publish status notifications, subscribed to by the Manager.</t>
        <section anchor="sacm-producer-to-orchestrator" numbered="true" toc="default">
          <name>SACM Producer to Orchestrator</name>
          <t>The Ad-hoc collection workflow MAY be initiated by a number of SACM components, such as the Manager, a Posture Evaluation Service, or other events outside the scope of this document.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response) or Broadcast (Publish/Subscribe)</li>
            <li>Source Component: Various</li>
            <li>Target Component(s): Orchestrator</li>
          </ul>
          <section anchor="request-payload-5" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>A request to orchestrate posture attribute collection MUST include enough information to describe those attributes being collected, and MAY include endpoint targeting information.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
collection-instructions:
  TBD
]]></artwork>
          </section>
          <section anchor="request-processing-5" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>When the Orchestrator receives the collection instructions, it may be required to manipulate them according to the capabilities it's collector(s) support.  For example, generic collection instructions could be transformed to the appropriate OVAL serialization for collection via OVAL-compliant collectors.</t>
          </section>
          <section anchor="response-payload-5" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>Orchestrators have the option to provide broadcast status update messages to indicate success, failure, or other error messages when receiving posture collection orchestration payloads.</t>
          </section>
          <section anchor="response-processing-5" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>N/A</t>
          </section>
        </section>
        <section anchor="orchestrator-to-posture-collection-service" numbered="true" toc="default">
          <name>Orchestrator to Posture Collection Service</name>
          <t>Once the Orchestrator has received collection instructions from the initiating SACM component, and has performed any manipulation of the instructions to conform to it's capabilities, it will provide those instructions to relevant Posture Collection Services.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response) or Broadcast (Publish/Subscribe)</li>
            <li>Source Component: Orchestrator</li>
            <li>Target Component(s): Posture Collection Service</li>
          </ul>
          <section anchor="request-payload-6" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>The payload exchanged between the Orchestrator and it's associated Posture Collection Services will be collection instructions adhering to a data model supported by the PCS based on its advertised capabilities.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
collection-instructions:
  TBD
]]></artwork>
          </section>
          <section anchor="request-processing-6" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>Upon receipt of the payload containing collection instructions, the Posture Collection Service should parse and validate them, indicating any errors in the process.  If the payload does not conform to any serialization or data model to which the PCS' capabilities correspond, status messages indicating such nonconformance SHOULD be provided to both the Orchestrator and the initiating SACM producer.</t>
            <t>Once successfully parsed and validated, the PCS MUST perform collection of posture attributes according to the collection instructions, from any endpoint to which the PCS has access, or from the list of endpoints described in any targeting information included in the collection instructions.</t>
          </section>
          <section anchor="response-payload-6" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>Posture Collection Service components will respond using the generic status update mechanisms to indicate success, failure, or any errors that occur. Errors may occur parsing collection instructions, verifying them, targeting indicated endpoints, or from the act of collecting the indicated posture attributes.</t>
          </section>
          <section anchor="response-processing-6" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>Any messages received by components regarding the success, failure, or errors involved in the collection of posture attributes MAY be processed according to the receiving components' capabilities.</t>
          </section>
        </section>
        <section anchor="posture-collection-service-to-posture-attribute-repository" numbered="true" toc="default">
          <name>Posture Collection Service to Posture Attribute Repository</name>
          <t>Upon completion of posture attribute collection, the PCS constructs the payload of collected attributes based on its advertised capabilities, e.g. OVAL system characteristics.  This payload is provided to either a specific posture attribute repository via directed messages or to subscribed repository interfaces via broadcast messages.</t>
          <ul spacing="normal">
            <li>Interaction Type: Directed (Request/Response) or Broadcast (Publish/Subscribe)</li>
            <li>Source Component: Posture Collection Service</li>
            <li>Target Component(s): Posture Attribute Repository</li>
          </ul>
          <section anchor="request-payload-7" numbered="true" toc="default">
            <name>Request Payload</name>
            <t>The payload supplied by the Posture Collection Service SHOULD conform to information and data models supported by its advertised capabilities. These data models, at a minimum, SHOULD include name/value pairs for each collected attribute.</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
collection-results:
  [
    attribute-name,
    attribute-value
  ]
]]></artwork>
          </section>
          <section anchor="request-processing-7" numbered="true" toc="default">
            <name>Request Processing</name>
            <t>As the Posture Attribute Repository interface receives the payload of collected posture attributes, some data normalization MAY occur in order to persist the information most efficiently based on the persistence technology.  This normalization is dependent on the implementation of the repository interface as well as the persistence technology.  For example, OVAL system characteristics, an XML payload, could be normalized to a property graph representation when persisted to a Neo4j database.</t>
          </section>
          <section anchor="response-payload-7" numbered="true" toc="default">
            <name>Response Payload</name>
            <t>Once the Posture Attribute Repository has received, it MAY respond to the Posture Collection Service that it has successfully received the collected posture attributes. This response would only be applicable when receiving payloads via directed requests. If payloads are received via broadcast interactions, there may not be a PCS to which a response can be sent.  The Posture Attribute Repository MAY utilize the generic status update interactions to provide response messages to appropriate subscribers.</t>
          </section>
          <section anchor="response-processing-7" numbered="true" toc="default">
            <name>Response Processing</name>
            <t>Any messages received by components regarding the success, failure, or errors involved in the persistence of collected posture attributes MAY be processed according to the receiving components' capabilities.  For example, a generic status update message could be processed by a Manager component, correlated with the initial posture collection instructions in order to "close the loop" on the posture attribute collection workflow.</t>
          </section>
        </section>
      </section>
      <section anchor="initiate-ad-hoc-evaluation-1" numbered="true" toc="default">
        <name>Initiate Ad-Hoc Evaluation</name>
        <t>### Manager to Orchestrator
### Orchestrator to Evaluator
### Evaluator to Posture Evaluation Repository</t>
      </section>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>[TBD]</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>[TBD]</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>[TBD] Some boilerplate code...</t>
      <section anchor="component-types" numbered="true" toc="default">
        <name>Component Types</name>
        <t>URI: <tt>urn:ietf:sacm:component-type</tt>
Description: The allowed enumeration of the various component types permitted to utilize the SACM ecosystem.</t>
        <ul spacing="normal">
          <li>Manager</li>
          <li>Orchestrator</li>
          <li>Collector</li>
          <li>Evaluator</li>
          <li>Repository Interface</li>
          <li>[MORE]</li>
        </ul>
      </section>
      <section anchor="component-capabilities" numbered="true" toc="default">
        <name>Component Capabilities</name>
        <t>### Health Check
A URN representing a component's capability to initiate Health Check operations and to process any provided response payloads.</t>
        <t>URN: <tt>urn:ietf:sacm:capability:action:health-check</tt></t>
        <section anchor="heartbeat-2" numbered="true" toc="default">
          <name>Heartbeat</name>
          <t>A URN representing a component's capability to initiate Heartbeat operations and to process any provided response payloads.</t>
          <t>URN: <tt>urn:ietf:sacm:capability:action:heartbeat</tt></t>
        </section>
        <section anchor="status-notification-publish" numbered="true" toc="default">
          <name>Status Notification (Publish)</name>
          <t>A URN representing a component's capability to publish status notifications.</t>
          <t>URN: <tt>urn:ietf:sacm:capability:publish:status-notification</tt></t>
        </section>
        <section anchor="status-notification-subscribe" numbered="true" toc="default">
          <name>Status Notification (Subscribe)</name>
          <t>A URN representing a component's capability to subscribe to status notification events.</t>
          <t>URN: <tt>urn:ietf:sacm:capability:subscribe:status-notification</tt></t>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8412" target="https://www.rfc-editor.org/info/rfc8412">
          <front>
            <title>Software Inventory Message and Attributes (SWIMA) for PA-TNC</title>
            <author fullname="C. Schmidt" initials="C." surname="Schmidt">
              <organization/>
            </author>
            <author fullname="D. Haynes" initials="D." surname="Haynes">
              <organization/>
            </author>
            <author fullname="C. Coffin" initials="C." surname="Coffin">
              <organization/>
            </author>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <author fullname="J. Fitzgerald-McKay" initials="J." surname="Fitzgerald-McKay">
              <organization/>
            </author>
            <date month="July" year="2018"/>
            <abstract>
              <t>This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8412"/>
          <seriesInfo name="DOI" value="10.17487/RFC8412"/>
        </reference>
        <reference anchor="I-D.ietf-sacm-ecp" target="https://www.ietf.org/archive/id/draft-ietf-sacm-ecp-05.txt">
          <front>
            <title>Endpoint Posture Collection Profile</title>
            <author fullname="Danny Haynes">
              <organization>The MITRE Corporation</organization>
            </author>
            <author fullname="Jessica Fitzgerald-McKay">
              <organization>Department of Defense</organization>
            </author>
            <author fullname="Lisa Lorenzin">
              <organization>Pulse Secure</organization>
            </author>
            <date day="21" month="June" year="2019"/>
            <abstract>
              <t>   This document specifies the Endpoint Posture Collection Profile,
   which describes the best practices for the application of IETF, TNC,
   and ISO/IEC data models, protocols, and interfaces to support the on-
   going collection and communication of endpoint posture to a
   centralized server where it can be stored and made available to other
   tools.  This document is an extension of the Trusted Computing
   Group's Endpoint Compliance Profile Version 1.0 specification [ECP].

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-ecp-05"/>
        </reference>
        <reference anchor="RFC8600" target="https://www.rfc-editor.org/info/rfc8600">
          <front>
            <title>Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange</title>
            <author fullname="N. Cam-Winget" initials="N." role="editor" surname="Cam-Winget">
              <organization/>
            </author>
            <author fullname="S. Appala" initials="S." surname="Appala">
              <organization/>
            </author>
            <author fullname="S. Pope" initials="S." surname="Pope">
              <organization/>
            </author>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8600"/>
          <seriesInfo name="DOI" value="10.17487/RFC8600"/>
        </reference>
        <reference anchor="RFC6120" target="https://www.rfc-editor.org/info/rfc6120">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
              <organization/>
            </author>
            <date month="March" year="2011"/>
            <abstract>
              <t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6120"/>
          <seriesInfo name="DOI" value="10.17487/RFC6120"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-sacm-terminology" target="https://www.ietf.org/archive/id/draft-ietf-sacm-terminology-16.txt">
          <front>
            <title>Security Automation and Continuous Monitoring (SACM) Terminology</title>
            <author fullname="Henk Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Jarrett Lu">
              <organization>Oracle Corporation</organization>
            </author>
            <author fullname="John Strassner">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Nancy Cam-Winget">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Adam Montville">
              <organization>Center for Internet Security</organization>
            </author>
            <date day="14" month="December" year="2018"/>
            <abstract>
              <t>   This memo documents terminology used in the documents produced by
   SACM (Security Automation and Continuous Monitoring).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-terminology-16"/>
        </reference>
        <reference anchor="RFC8322" target="https://www.rfc-editor.org/info/rfc8322">
          <front>
            <title>Resource-Oriented Lightweight Information Exchange (ROLIE)</title>
            <author fullname="J. Field" initials="J." surname="Field">
              <organization/>
            </author>
            <author fullname="S. Banghart" initials="S." surname="Banghart">
              <organization/>
            </author>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <date month="February" year="2018"/>
            <abstract>
              <t>This document defines a resource-oriented approach for security automation information publication, discovery, and sharing.  Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories.  This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8322"/>
          <seriesInfo name="DOI" value="10.17487/RFC8322"/>
        </reference>
        <reference anchor="draft-birkholz-sacm-yang-content" target="https://tools.ietf.org/html/draft-birkholz-sacm-yang-content-01">
          <front>
            <title>YANG subscribed notifications via SACM Statements</title>
            <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
              <organization/>
            </author>
            <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC7632" target="https://www.rfc-editor.org/info/rfc7632">
          <front>
            <title>Endpoint Security Posture Assessment: Enterprise Use Cases</title>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire">
              <organization/>
            </author>
            <author fullname="D. Harrington" initials="D." surname="Harrington">
              <organization/>
            </author>
            <date month="September" year="2015"/>
            <abstract>
              <t>This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture.  From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7632"/>
          <seriesInfo name="DOI" value="10.17487/RFC7632"/>
        </reference>
        <reference anchor="RFC8248" target="https://www.rfc-editor.org/info/rfc8248">
          <front>
            <title>Security Automation and Continuous Monitoring (SACM) Requirements</title>
            <author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget">
              <organization/>
            </author>
            <author fullname="L. Lorenzin" initials="L." surname="Lorenzin">
              <organization/>
            </author>
            <date month="September" year="2017"/>
            <abstract>
              <t>This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols.  The requirements and scope are based on the agreed-upon use cases described in RFC 7632.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8248"/>
          <seriesInfo name="DOI" value="10.17487/RFC8248"/>
        </reference>
        <reference anchor="RFC5023" target="https://www.rfc-editor.org/info/rfc5023">
          <front>
            <title>The Atom Publishing Protocol</title>
            <author fullname="J. Gregorio" initials="J." role="editor" surname="Gregorio">
              <organization/>
            </author>
            <author fullname="B. de hOra" initials="B." role="editor" surname="de hOra">
              <organization/>
            </author>
            <date month="October" year="2007"/>
            <abstract>
              <t>The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources.  The protocol is based on HTTP transfer of Atom-formatted representations.  The Atom format is documented in the Atom Syndication Format.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5023"/>
          <seriesInfo name="DOI" value="10.17487/RFC5023"/>
        </reference>
        <reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3444">
          <front>
            <title>On the Difference between Information Models and Data Models</title>
            <author fullname="A. Pras" initials="A." surname="Pras">
              <organization/>
            </author>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
              <organization/>
            </author>
            <date month="January" year="2003"/>
            <abstract>
              <t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3444"/>
          <seriesInfo name="DOI" value="10.17487/RFC3444"/>
        </reference>
        <reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4949">
          <front>
            <title>Internet Security Glossary, Version 2</title>
            <author fullname="R. Shirey" initials="R." surname="Shirey">
              <organization/>
            </author>
            <date month="August" year="2007"/>
            <abstract>
              <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="FYI" value="36"/>
          <seriesInfo name="RFC" value="4949"/>
          <seriesInfo name="DOI" value="10.17487/RFC4949"/>
        </reference>
        <reference anchor="RFC5209" target="https://www.rfc-editor.org/info/rfc5209">
          <front>
            <title>Network Endpoint Assessment (NEA): Overview and Requirements</title>
            <author fullname="P. Sangster" initials="P." surname="Sangster">
              <organization/>
            </author>
            <author fullname="H. Khosravi" initials="H." surname="Khosravi">
              <organization/>
            </author>
            <author fullname="M. Mani" initials="M." surname="Mani">
              <organization/>
            </author>
            <author fullname="K. Narayan" initials="K." surname="Narayan">
              <organization/>
            </author>
            <author fullname="J. Tardo" initials="J." surname="Tardo">
              <organization/>
            </author>
            <date month="June" year="2008"/>
            <abstract>
              <t>This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model.  NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system.  This may take place during the request for network access and/or subsequently at any time while connected to the network.  The learned posture information can then be applied to a variety of compliance-oriented decisions.  The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software.  In order to provide context for the requirements, a reference model and terminology are introduced.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5209"/>
          <seriesInfo name="DOI" value="10.17487/RFC5209"/>
        </reference>
        <reference anchor="RFC6192" target="https://www.rfc-editor.org/info/rfc6192">
          <front>
            <title>Protecting the Router Control Plane</title>
            <author fullname="D. Dugal" initials="D." surname="Dugal">
              <organization/>
            </author>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro">
              <organization/>
            </author>
            <author fullname="R. Dunn" initials="R." surname="Dunn">
              <organization/>
            </author>
            <date month="March" year="2011"/>
            <abstract>
              <t>This memo provides a method for protecting a router's control plane from undesired or malicious traffic.  In this approach, all legitimate router control plane traffic is identified.  Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane.  That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.</t>
              <t>Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6192"/>
          <seriesInfo name="DOI" value="10.17487/RFC6192"/>
        </reference>
        <reference anchor="I-D.ietf-i2nsf-terminology" target="https://www.ietf.org/archive/id/draft-ietf-i2nsf-terminology-08.txt">
          <front>
            <title>Interface to Network Security Functions (I2NSF) Terminology</title>
            <author fullname="Susan Hares">
              <organization>Huawei</organization>
            </author>
            <author fullname="John Strassner">
              <organization>Huawei</organization>
            </author>
            <author fullname="Diego R. Lopez">
	 </author>
            <author fullname="Liang Xia">
              <organization>Huawei</organization>
            </author>
            <author fullname="Henk Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <date day="5" month="July" year="2019"/>
            <abstract>
              <t>   This document defines a set of terms that are used for the Interface
   to Network Security Functions (I2NSF) effort.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-i2nsf-terminology-08"/>
        </reference>
        <reference anchor="CISCONTROLS" target="https://www.cisecurity.org/controls">
          <front>
            <title>CIS Controls v7.1</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="MQTT" target="https://mqtt.org/mqtt-specification/">
          <front>
            <title>MQTT</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="NIST800126" target="https://csrc.nist.gov/publications/detail/sp/800-126/rev-3/final">
          <front>
            <title>SP 800-126 Rev. 3 - The Technical Specification for the Security Content Automation Protocol (SCAP) - SCAP Version 1.3</title>
            <author initials="D." surname="Waltermire" fullname="David Waltermire">
              <organization/>
            </author>
            <author initials="S." surname="Quinn" fullname="Stephen Quinn">
              <organization/>
            </author>
            <author initials="H." surname="Booth" fullname="Harold Booth">
              <organization/>
            </author>
            <author initials="K." surname="Scarfone" fullname="Karen Scarfone">
              <organization/>
            </author>
            <author initials="D." surname="Prisaca" fullname="Dragos Prisaca">
              <organization/>
            </author>
            <date year="2018" month="February"/>
          </front>
        </reference>
        <reference anchor="NISTIR7694" target="https://csrc.nist.gov/publications/detail/nistir/7694/final">
          <front>
            <title>NISTIR 7694 Specification for Asset Reporting Format 1.1</title>
            <author initials="A." surname="Halbardier" fullname="Adam Halbardier">
              <organization/>
            </author>
            <author initials="D." surname="Waltermire" fullname="David Waltermire">
              <organization/>
            </author>
            <author initials="M." surname="Johnson" fullname="Mark Johnson">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="NISTSIEM" target="https://csrc.nist.gov/glossary/term/security_information_and_event_management_SIEM_tool">
          <front>
            <title>security information and event management (SIEM) tool</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="XMPPEXT" target="https://xmpp.org/extensions/">
          <front>
            <title>XMPP Extensions</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK99" target="https://www.github.com/sacmwg/vulnerability-scenario/ietf-hackathon">
          <front>
            <title>IETF 99 Hackathon - Vulnerability Scenario EPCP</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK100" target="https://www.github.com/sacmwg/vulnerability-scenario/ietf-hackathon">
          <front>
            <title>IETF 100 Hackathon - Vulnerability Scenario EPCP+XMPP</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK101" target="https://www.github.com/CISecurity/Integration">
          <front>
            <title>IETF 101 Hackathon - Configuration Assessment XMPP</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK102" target="https://www.github.com/CISecurity/YANG">
          <front>
            <title>IETF 102 Hackathon - YANG Collection on Traditional Endpoints</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK103" target="https://www.ietf.org/how/meetings/103/">
          <front>
            <title>IETF 103 Hackathon - N/A</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK104" target="https://github.com/CISecurity/SACM-Architecture">
          <front>
            <title>IETF 104 Hackathon - A simple XMPP client</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="HACK105" target="https://github.com/CISecurity/SACM-Architecture">
          <front>
            <title>IETF 105 Hackathon - A more robust XMPP client including collection extensions</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="security-domain-workflows" numbered="true" toc="default">
      <name>Security Domain Workflows</name>
      <t>This section describes three primary information security domains from which workflows may be derived: IT Asset Management, Vulnerability Management, and Configuration Management.</t>
      <section anchor="it-asset-management" numbered="true" toc="default">
        <name>IT Asset Management</name>
        <t>Information Technology asset management is easier said than done. The <xref target="CISCONTROLS" format="default"/> have two controls dealing with IT asset management. Control 1, Inventory and Control of Hardware Assets, states, "Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access." Control 2, Inventory and Control of Software Assets, states, "Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and that unauthorized and unmanaged software is found and prevented from installation or execution."</t>
        <t>In spirit, this covers all of the processing entities on your network (as opposed to things like network cables, dongles, adapters, etc.), whether physical or virtual, on-premises or in the cloud.</t>
        <section anchor="components-capabilities-and-workflows" numbered="true" toc="default">
          <name>Components, Capabilities and Workflow(s)</name>
          <t>TBD</t>
          <section anchor="components" numbered="true" toc="default">
            <name>Components</name>
            <t>TBD</t>
          </section>
          <section anchor="capabilities-1" numbered="true" toc="default">
            <name>Capabilities</name>
            <t>An IT asset management capability needs to be able to:</t>
            <ul spacing="normal">
              <li>Identify and catalog new assets by executing Target Endpoint Discovery Tasks</li>
              <li>Provide information about its managed assets, including uniquely identifying information (for that enterprise)</li>
              <li>Handle software and/or hardware (including virtual assets)</li>
              <li>Represent cloud hybrid environments</li>
            </ul>
          </section>
          <section anchor="workflows" numbered="true" toc="default">
            <name>Workflow(s)</name>
            <t>TBD</t>
          </section>
        </section>
      </section>
      <section anchor="vulnerability-management" numbered="true" toc="default">
        <name>Vulnerability Management</name>
        <t>Vulnerability management is a relatively established process. To paraphrase the <xref target="CISCONTROLS" format="default"/>, continuous vulnerability management is the act of continuously acquiring, assessing, and taking subsequent action on new information in order to identify and remediate vulnerabilities, therefore minimizing the window of opportunity for attackers.</t>
        <t>A vulnerability assessment (i.e. vulnerability detection) is performed in two steps:</t>
        <ul spacing="normal">
          <li>Endpoint information collected by the endpoint management capabilities is examined by the vulnerability management capabilities through Evaluation Tasks.</li>
          <li>If the data possessed by the endpoint management capabilities is insufficient, a Collection Task is triggered and the necessary data is collected from the target endpoint.</li>
        </ul>
        <t>Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific vulnerability. Common endpoint information used to detect a vulnerability includes:</t>
        <ul spacing="normal">
          <li>A specific software version is installed on the endpoint</li>
          <li>File system attributes</li>
          <li>Specific state attributes</li>
        </ul>
        <t>In some cases, the endpoint information needed to determine an endpoint's vulnerability status will have been previously collected by the endpoint management capabilities and available in a Repository. However, in other cases, the necessary endpoint information will not be readily available in a Repository and a Collection Task will be triggered to perform collection from the target endpoint. Of course, some implementations of endpoint management capabilities may prefer to enable operators to perform this collection even when sufficient information can be provided by the endpoint management capabilities (e.g. there may be freshness requirements for information).</t>
        <section anchor="components-capabilities-and-workflows-1" numbered="true" toc="default">
          <name>Components, Capabilities and Workflow(s)</name>
          <t>TBD</t>
          <section anchor="components-1" numbered="true" toc="default">
            <name>Components</name>
            <t>TBD</t>
          </section>
          <section anchor="capabilities-2" numbered="true" toc="default">
            <name>Capabilities</name>
            <t>TBD</t>
          </section>
          <section anchor="workflows-1" numbered="true" toc="default">
            <name>Workflow(s)</name>
            <t>TBD</t>
          </section>
        </section>
      </section>
      <section anchor="configuration-management" numbered="true" toc="default">
        <name>Configuration Management</name>
        <t>Configuration management involves configuration assessment, which requires state assessment. The <xref target="CISCONTROLS" format="default"/> specify two high-level controls concerning configuration management (Control 5 for non-network devices and Control 11 for network devices). As an aside, these controls are listed separately because many enterprises have different organizations for managing network infrastructure and workload endpoints. Merging the two controls results in the following paraphrasing: Establish, implement, and actively manage (track, report on, correct) the security configuration of systems using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.</t>
        <t>Typically, an enterprise will use configuration guidance from a reputable source, and from time to time they may tailor the guidance from that source prior to adopting it as part of their enterprise standard. The enterprise standard is then provided to the appropriate configuration assessment tools and they assess endpoints and/or appropriate endpoint information.</t>
        <t>A preferred flow follows:</t>
        <ul spacing="normal">
          <li>Reputable source publishes new or updated configuration guidance</li>
          <li>Enterprise configuration assessment capability retrieves configuration guidance from reputable source</li>
          <li>Optional: Configuration guidance is tailored for enterprise-specific needs</li>
          <li>Configuration assessment tool queries asset inventory repository to retrieve a list of affected endpoints</li>
          <li>Configuration assessment tool queries configuration state repository to evaluate compliance</li>
          <li>If information is stale or unavailable, configuration assessment tool triggers an ad hoc assessment</li>
        </ul>
        <t>The SACM architecture needs to support varying deployment models to accommodate the current state of the industry, but should strongly encourage event-driven approaches to monitoring configuration.</t>
        <section anchor="components-capabilities-and-workflows-2" numbered="true" toc="default">
          <name>Components, Capabilities and Workflow(s)</name>
          <t>This section provides more detail about the components and capabilities required when considering the aforementioned configuration management workflow.</t>
          <section anchor="components-2" numbered="true" toc="default">
            <name>Components</name>
            <t>The following is a minimal list of SACM Components required to implement the aforementioned configuration assessment workflow.</t>
            <ul spacing="normal">
              <li>Configuration Policy Feed: An external source of authoritative configuration recommendations.</li>
              <li>Configuration Policy Repository: An internal repository of enterprise standard configurations.</li>
              <li>Configuration Assessment Orchestrator: A component responsible for orchestrating assessments.</li>
              <li>Posture Attribute Collection Subsystem: A component responsible for collection of posture attributes from systems.</li>
              <li>Posture Attribute Repository: A component used for storing system posture attribute values.</li>
              <li>Configuration Assessment Evaluator: A component responsible for evaluating system posture attribute values against expected posture attribute values.</li>
              <li>Configuration Assessment Results Repository: A component used for storing evaluation results.</li>
            </ul>
          </section>
          <section anchor="capabilities-3" numbered="true" toc="default">
            <name>Capabilities</name>
            <t>Per <xref target="RFC8248" format="default"/>, solutions MUST support capability negotiation. Components implementing specific interfaces and operations (i.e. interactions) will need a method of describing their capabilities to other components participating in the ecosystem; for example, "As a component in the ecosystem, I can assess the configuration of Windows, MacOS, and AWS using OVAL".</t>
          </section>
          <section anchor="configuration-assessment-workflow" numbered="true" toc="default">
            <name>Configuration Assessment Workflow</name>
            <t>This section describes the components and interactions in a basic configuration assessment workflow. For simplicity, error conditions are recognized as being necessary and are not depicted. When one component messages another component, the message is expected to be handled appropriately unless there is an error condition, or other notification, messaged in return.</t>
            <figure anchor="fig-configassess">
              <name>Configuration Assessment Component Interactions</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+  +----------------+  +------------------+  +------------+
| Policy Feed |  |  Orchestrator  |  |    Evaluation    |  | Evaluation |
+------+------+  +-------+--------+  | Sub-Architecture |  |   Results  |
       |                 |           +---^----------+---+  | Repository |
       |                 |               |          |      +------^-----+
       |                 |               |          |             |
     1.|               3.|             8.|        9.|          10.|
       |                 |               |          |             |
       |                 |               |          |             |
+------v-----------------v---------------+----------v-------------+-----+
|                           Integration Service                         |
+-----+----------------------------------+----------^---------+------^--+
      |                                  |          |         |      |
      |                                  |          |         |      |
    2.|                                4.|        5.|       6.|    7.|
      |                                  |          |         |      |
      |                                  |          |         |      |
+-----v------+                       +---v----------+---+  +--v------+--+
|   Policy   |                       |    Collection    |  |  Posture   |
| Repository |                       | Sub-Architecture |  | Attribute  |
+------------+                       +------------------+  | Repository |
                                                           +------------+
]]></artwork>
            </figure>
            <t><xref target="fig-configassess" format="default"/> depicts configuration assessment components and their interactions, which are further described below.</t>
            <ol spacing="normal" type="1"><li>A policy feed provides a configuration assessment policy payload to the Integration Service.</li>
              <li>The Policy Repository, a consumer of Policy Feed information, receives and persists the Policy Feed's payload.</li>
              <li>Orchestration component(s), either manually invoked, scheduled, or event-based, publish a payload to begin the configuration assessment process.</li>
              <li>If necessary, Collection Sub-Architecture components may be invoked to collect neeeded posture attribute information.</li>
              <li>If necessary, the Collection Sub-Architecture will provide collected posture attributes to the Integration Service for persistence to the Posture Attribute Repository.</li>
              <li>The Posture Attribute Repository will consume a payload querying for relevant posture attribute information.</li>
              <li>The Posture Attribute Repository will provide the requested information to the Integration Service, allowing further orchestration payloads requesting the Evaluation Sub-Architecture perform evaluation tasks.</li>
              <li>The Evaluation Sub-Architecture consumes the evaluation payload and performs component-specific state comparison operations to produce evaluation results.</li>
              <li>A payload containing evaluation results are provided by the Evaluation Sub-Architecture to the Integration Service</li>
              <li>Evaluation results are consumed by/persisted to the Evaluation Results Repository</li>
            </ol>
            <t>In the above flow, the payload information is expected to convey the context required by the receiving component for the action being taken under different circumstances. For example, a directed message sent from an Orchestrator to a Collection sub-architecture might be telling that Collector to watch a specific posture attribute and report only specific detected changes to the Posture Attribute Repository, or it might be telling the Collector to gather that posture attribute immediately. Such details are expected to be handled as part of that payload, not as part of the architecture described herein.</t>
          </section>
        </section>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJ+5g2EAA+V923LkxpXge30FgnoQuV1VVLcutuiZ2aXYLYk76ss0W5Id
DssCq8AiplFAGUCRXVZrw7+xETs/5y/Zc808mUgU2XLbMxvLUKjJKiAvJ0+e
+2U2m036sq+Kk+yiWGzbst9lp9u+Wed92dRZXi+zs6buy3rbbLvsaVOXfdOW
9So7vDg9e3qUnbaL67IvFv22LSb55WVb3MBI8FX4zbJZ1PkaJlm2+VU/K4v+
atbli/Ush6dmDz+ZdD1M9ce8amp4qG+3xaTctPRb1z/66KPPP3o0ydsi96uc
3K5kou+b9jWu6Ku22W4mr29PsvO6L9q66GePcbbJIu9Psq5fThbNEh48ybbd
LO8WZTnZlCeTLOubxUm2Kzr4tWvavi2uOvf3bu3/nOTb/rppTyazrKzhs9M5
AqS/KauqgGd5g6fLfJ19H37TtDDpWYGryq6a1q3PbybLFHZn5xfwV7HOy+ok
y2Gw+VpHmnfL5n+s8Jv5olnj6mCtBezt44fZq2JxnX2Xw1O77HFb3uC0sF1Y
0IcPH3302cMP8W+Y6SR7knc9wKoo6sttdw0ft8UKjvoke/Y7emdb9y089u3F
qe7zC9jNtt7ltdvkF7Ac/9kv3t4lDDNf0zBzRIl/6OYmddMilt8UiAMvvzx7
9PDh5/Lrrz95+Ah/XQNSVoyofdNUs0W+yWHRMNWsyuvVNl8V+tha8Lnriq5b
AzBma1hhFX29aGATC7xaya+Lm7za5uNf18tNU8LQed+35eW2L2bLvM/52Rlu
tcPtwUvns8dzf8mKxeYkg//J5j776KOT7M16s1m15ZI/+wzgeJL99umLF5NJ
WV9ZyIRDwcmuy7qpmhWAET/pZdCPHz06ydqmKvFw+JZflu3r66b6M78Jh7yC
/QNu1D2OC/cub1d4wtd9v+lOjo8RxB3NNQeUOr7u19XxXSPNPnrIYzEN+93p
s6+ybnvZLQA+xTKrm768KhcE0i67KXMmGRd93hd4SB29rPcafxec/3oOSM6T
0seK+V8X9evwG3nh2Tw7y9ez74HAFH3wyrO8XuzCLwFgv/rs40eKbY8++bX8
+ulHjz6WXz/+5JNP5NdPPv9EMfPTRx/pr589/PxRcEDlo7q7Ck+IPsIZ4d6d
PX/26uXzby7SwL+9vZ0vyk5uLB0AghhOtLMAhnGIIeDn2c2v5gj9p//26lV6
0PWf+p6Gwl9m3aZYuNM4tqPiCPD3s/OLV7/+6KOHjz5LD7fo2sW8BiSfr5qb
4832stKjPV4WPZCO425zDAPMYIRjIDezj4+vyjqv7FQXLzJ5IntZ3Myzj+EA
X10XRGNqGK7KLuwyiaD18L3jjmeMeJZLvmgb4CFNBUzx7PTFEYyI/2bfFW2H
Xz+cfzyGZo/n2fd5RUfWFgHWPM5vymX8pbx1Mc/+bVvWdfDCRV9srovafGNQ
uWn66xCPczjBpflCHv7XeXaxyNsr4MPB8/8K3LcOv/JbeNGWcDHzcP1tvmq6
4CugVfDFl8Vlu83bXfboo4e/lkM/f/mrzz7/5JceOn5Ztsc4xPC8efgMv0yc
7CmQ6x4QYQN8H2WIL4nywYk9HDsxYPpf59Vl3i7Log12TJw/+u5vOuan8+x/
Ntd114QH/TRvX5svcIMX50+e3gd6q6rpOoD9Mc52rJf9j47iN/UfUQwrbgDB
/wiMB/gbUsk/4vh/RPJsIauvZ+Z1Ehjp9cy/DtcC3j/KZADkMk9+O0IxkC0R
xSjewC3r6JjtpPhy9sR9B199fXr2r59/Pk7UVmV/vb1EoeIYucft6vhmW9VF
q4y8WxR13pbNMdHQ63zxOodDr+2k509efZl9/jkcrnwJJ/SdHQQuBg+SPXlx
9kIW9RDY7N99VTDJfZf1gNi7ru3hvdYG5F5O+RilulVLp5xYxcNgFUAjr8rV
lp+mS8YyURYs4dG7LgG5e2LuR8HcJAKcOTkrg/9etfmyxD+Auj8RGapzy/h4
fBleFmluj9cgjgKN6I7hlePEMj4OlvHs+NTNMELZ0ptEAWUWKE/DqT4JpjrN
unK9qQq+HAsQwerezf3p+57702juddMWIPiBvN3bBQBVWFRb1LcyL/Rm/lZP
JrPZDNQCkFjzRT+ZvLouuwzUxC3hybIAQl50QE6y3CwnA3QG+g9j5jBqsyla
ElN/mepaLJpu14EcOM8ymv0WFMkM/t20xRKZBMiP2w2MZOnbqiryGr64aps1
y5LfdgUIdx0tdgms5E9bIOMkW2aHP/0kkt7PP9O39DeKe/B3W6A8hMuvdkdT
+tqIblneAYPawodlDa+R4Nv//PN8Mvn++ct/PQcU/+rl829fnJDs0jXbdlGI
qIJgRKEZdwLqVA0sEhcMw3xV9l/DmWfZxXa1Kjrc3+IaZGlYenfdbEEcuCxQ
eF6XPX4HK9hsQc9rYUvwNOyvT6GPkC+iU1YRgmM7hrnOazjh7YIFcBAi8D72
1zDUBrgDznFbgBLI2LAul0tQmCcfoArZNkt+DXGjgKW0mwZA3VxFe+wbwZYI
WeCu55tN2+SgOyJkRPR/3CBQptklHNmSFwOb3pSAPjj2FqZY0Gka6IeH2Noj
Dp/io50zOrnZVzBhR/OsG7gk+fImh1OB3V/uANwblT3y7AZodQFYDOswd4aR
tGMUKVH4XNKu6S4U0U1wSE2AQoWKUXVZdpscnlFkAbjDEQLE63INkOIBAEoL
S7nhWD74IERpUKiYBeCZvAZ9HC4NLOfg6bcXrw6m/G/27Dn9/vLJv317/vLJ
Y/z94uvTb75xv/ATE/jj+bffyPf4m3/z7PnTp0+ePeaX4dMs+ujp6e8OCCKT
g+cvXp0/f3b6zQEeQx+QEcQ3gBSgNcKthYstiL0sVEOEd+DgJqj8T7Mvzl5k
Dz/hs8RP6MJ9ALpBu+br/RgxjVgJEDDP104mJ/xV4XEBNTXEGAAOHj3gAkC9
s2cLZw4oTXSNERRlUfxerQwlHJNgqKr+2WExX82n2TW8OGMcvoLDuc2r6giQ
CbCNLhe+Qvi3aUs89Ju8Kpd4wEgTdpnYGQp6TteQE572sDxgJiUorfgVCNu7
+cGEN0v7PO9wpYxjQMMIm6YM0xAAqLX+/POUF4SzwjHg2A1dvKsMNI8Cdo3j
dgDmExDrcmRjBCOarhMmAszHse1pdtFc9bdwstPsqy1sqsbpAXy/nX/60ecZ
6weEmYuiFeW/6ObZac1TIckAJM7qAo8DLlwF9+0W1w23ESgIcPu8Lv+s+M8K
wlMnyyIEEPXPX7kThfdur0uAPG+FkA6+uymRzxXLKTAR1HzgF0OOEZmWBSAk
8RmcSE06DsZo2smKiqZNApgxTACMBAd4X7kgUJ4z1pCR5A0hFRI/GEVn4WUe
8CsHAYuTKRnhASJ4/QFf8D7BXfKmJ8ShYrbJyxbAm536kRfwkp51TSPh/NvL
fwekx5M+c1a0E1zrqeL9VZEjIna8IVxffgP6HVE5ImJCws90YNrqRQHPVV2T
HXjr3IFwTTZ/0C0WiRC1OZpzUwIC4KydoJPMuiBi14VKzWWzhRUCiwE8I3mH
xSl3KwkJANjEsUKJp8+714zep/oxklkG0RINdgQ1gPSiBeUsW2+rvkRhrvAY
j1dev8/jufmYGDIO5CTSAK0vhOjDP3wMjBV2GfDOelvTNWGeALcb9WSgGH+G
ZW3EtjFl6gJo+OJ09urZWfZ7xMBfff7oD3T4GchFHcMI58Kp8mB7ftLrnNhX
n78ulLq1TVXwK3RxlkAX4C97BABf/grBS3slin6VIyuD0ZDUAQHri5B6klTV
6KgKJDbglDw3zhFxXDh/OAVCVcsOBXPqpp7dNBV8VJG4JNgbUGlzz2hb7gu9
q8zHi6Wwp22dX13B7EKGMrJNo+h12TT9bLFbVAXhUKhYlYQOuw3BDlQAFQJW
QhfdbB3AnQnHVYkE9pD/WTo5F1aBYAHaFEoACMBjxHp+wV1Md2n8JQcZdgk3
Z9EjQYUDq5rFa5jhpoQTIgKNoowYYAAH2mX0Pg8uFyNfIGmFhaHJdtG0KCzD
9cLDT0wNGPi0WXrLDp2m3YWjSHRDYVgQVLfAMne4rlx0hgV9gBNa08WmAnn/
KMA2XKfIbfZRvSmdvyoXz56+wCm+f3o+x/tP0nZ6ec0CVJhsuSUN5RJ4Y9Zu
61lfrgvmFcCjZhn9iQhVO4xCEZvOGO8xjLVBdapckNzTLa6L5bZC4jI6t8wI
i3SnB4J10QqlQIasMM0zj433O5gMkIDwS+55TLrKviuqK75nHYhsSpzpnr5E
okDAFom7GzAA3KSICPzNl9taVA2nKZb0FGytwKthaQrxFJZCwmHx5qvAQSva
I9vl9Y42vCXCz/geoDKAu+abjdwT5I4e9UyUqdBk6OwS52ZhbJG2My2d3En3
FHRavFQHF4hncseEZuD5IefsumZREuyFqCNZLhfbKm8zgMvrrMp3KH4tly0J
McUV8rV/hy3jPvCwZKWEfpsGSWbJw9fZ+Qv3YoN0Ro5X9yb6tJxMdwJzbfpm
AyuGv17zb13R3hQt/LIA/S/bXAPgmUwgQC0YUXK8zm+KcF6G36smu9q2dIIL
2Fh5taN1pCE3tdeGaCfMtLnedWT1h5lvyrYHqjAyu4eHrCDLnjU9PzZ1XwJ+
tTlrvChT69mQ1J51cBRwJWGfLQgUtHsV3pF8shR5VbL4Hiy8FRkHDr9D9ugY
h5dA8JhjBYh4xgvdon+Wx7vNd51I5GVvqbuV0lOUGjEiSYa/EwiGM7nhEIXa
otoFYlc0Ln9fJ79nu4Hw8it/1QMBNbFgAgNeKbrmgUEJuMYVgBNxm0BwC3o1
MB7C9Qxp16ppS+biblNGG4EzQ6OEM4WrLjXk8OwYhj8PY9nxiI3mbkjPZNVd
gbeueEOXSSxPDo2d8uZtrIfuUT8FQeALa/IwFIUZCmkvwzvi5Av6HsZxlDEz
KovTWUrQqwtL4oHvIEcqWnTSLJxEwiQTSDQc9iXSApTyWQscDN/hGgQMeAH6
sodPg+8Nvb3c1suKaDUAXrQOuX9DmT73Iom/wcLpdcAW1TRECRFHnJ7uRPXT
714cGZaRnQV77k4U/Tp0O0+HEpa7hHIaZJIauR+HQqWO0jdzyGI7e52nxizr
4Q67BBpXNq2oGqDdzxDcQJ+qZjUj2Y9o84vH32bFuuw6Max7diZKJ10w/GB2
VTW38NLhK1rPUTYGHML0GMSWGT4RdRRR7wVj+108eSjCwtoR+NsuIGn4qYKZ
HjQCfIeCA0jUPRvvmtg28GFnb72aSU6Y86EhFyG/7YT/iq7RLRq+TAQnEktk
46quR4hBGBPgrb9ApK4oQUgcfKjepFQT4UoCgmMHl7JGD17T7mJcBcQnFwgw
8l2dr+VOAmUoV2TUYM5YAL1xIoBfObJSc32tOu2omFubOW1z0e8UxvzexMKn
wky4D48OhzL1EQu4YoKI9TlUcbPBcvzpkUkMpqrI8oNYsxOqypeskJOEcb6E
uQs2dAGxTQy6LlfXvTNQ0jJuJJBAViXWXhS52QyHZjuMjvL2bPZrEEJ+n5AL
+C/C0nAPSgyR2LeGTnpynoJjIZiURJapWV7nTHeKa0eDu59AVLFmbK5BtCqy
A2cnik7pILsG2FUIP0TGy+YGjwjYe8d6QryK4P4H0sLkhZgh1FikVonS6SBk
snCYT6J9aIIJpJWOnncRMEZ4MdaJ4Jo3VjMJF4fhCh06s9R+1roPeIESuFOR
Fpf3qtp34bQL1rmmbB1gMT+xEjbLeOXhdVkv2fCGyod9srSMmqyXfZvXHerJ
Ru7Az0mpngKr7kPNAkVcegAXsy76nP4gAqfmTNgXf2sUbxyNrqjcQQMPJDq6
KyKHDgLIwBs2+9VEjNzhmNdJ+Dks50WM3Gh6r9Dp5B+eWiFMTEjB10W/mB/B
+SW8lU5EMG4CVgcckwEBF214aiDhVxH1rkGZWF3T7rbsIHNCbSA8N7Bf8oGi
kJdXuz/zmfOircgOH6owBAd4RfgqUVDihaP1LYtevBggEQTQAf4AH6lQ0WX0
cgu3thOL7dBbGwnMcFyAFKjOxYZWFfXQho/kEQOEUaruCqAM8tdB5IMQh9yq
AZkeLwjI/8UNm9oWuCzyvjH6I/DxzwIxBlXbQ3OonQsbPBIpPSVu4cpytzAh
0XY1gAEUrzPh6CTn7MZPkY3BCR/km43GOUWEhFw7Et8BkFrlRCYcmvgbY6+m
rCKSJb3sARPwvUPosEXiMiQDIvnyBXMy8gFsTAOQeGfPT1+esKUSzVFwqV/X
zW1NxjBd4vMWleCecWVqsGAqLnQ0KXVw5XAwVtSzaxCxSIEo2JFXdsbSu+Md
FG/KjlSyohZ8M1Ri6ux8TNMcwISbEtayh3VB2Je1sg6SUNFLPVs0TQuic27M
9UC3jBzYNqs2D8BcopAMq6jhjMjZWv7Z21dQeEOD+BYeYJii3MWOJwpRFfru
rc2seIyamUW3PBram0Pz8sCu/E2DBgKRNju+FfwwrpSWli+8bdVtj2xLzKjM
p4grll4LucePzRXznADYy65q8uWUrTB5QKlhXSJTiR5e0VqdsDpqjHjMImpE
uFlSsRYs66WwYi1hfD18TGVzw4FQxmM7t1p+H3999uKI5XRnsWHw6omQ34O4
hMoxFsxstKsj0MrqhRbIYeJUYk4LHDhX8d5RR52wPpYF5s3zLtB9dIWgSIuD
Vugf2r2bNYrrrGDQeXGEPemWaJ5mHR7WshsOiJQxMGoAPQP5KRenPK4hNl2I
DSKkssTrRyiv9z6R5LSkcA/YSoVnWBpZaCCvMWxHxDh0K3fXhdO7jJsIn0V8
Zj1MLjKirXN5HYn/L7HkDigCSlUkQFrDI+1bDgu288RlBoBK/fzJUeQPZmqb
nQEZAsU6F8bO0i+yMUKVkAdNwlBBE8yQZbTc2h59cGwYdduIDRKlAIxaQggA
5WWffkyoOtyOBjhW5N4hSroiR+B1yGnkhHhjpP4EC2XNaMNSg38Nd4SZQGh3
ELJ5K38yLNfNkuTX2NaC/llvQFIvWNWQlRo9RmKhR6FGDT5wk1uJ33Ai09Bx
68yOFPYDlxbAhLD06xKDiVADA259hAKj/gVjUE6DyKbnN0hxilsKw1kVAB5U
2jTgCOklGXzgMIoSEXXRrOryzyI9EONBBeOStjpwiRAfVZnoakv6KdOusaik
df4axi7o1gNPKtYbcbpQiNsggiqIlTrtxU4B5MZrHPUutNPmFPzXk1eXyI6n
9BIAobsy/myU+4pd4OHGkCtgHeQY8vtG23uBaimx61UJbDhD8E8DK4WVnuhP
9ll1sa8at7jnPVUm4/eAqj12gjuqi86mPxbihcoN8Au86eQxfEExcziyBD/6
9VFkZ1tUBcaeRffmf7kfiTPPHsyinwf6zdvYA/fWf5Nlh7qCI/wgHu3BYDT9
eTv8IFrCzXBFb/lRE5cMIibx4ZExxne1Zx3RHm4G794BET2FJETMSswh/HSS
fQBcG8O70GKO0bf/fPAF/RFSgQv1Mx38PKFQPQX/5NT96kJNXMQbc1qNvHUK
hreUkCzQI60lCZtDM0BRcLEXSUQiiiJYj9fXoR8FgTKRyqtp8Mphnh2I7Hdw
xKG3tGoxqBirQ99sysXUpnahW2UX3DM7o78KRBdEW1ygt7Kt2TqE5n9Yp3I2
Z06SBaGwwCuSqBNaEtMGWg0bBRXMcBenJM07457IDM64aYhnaYNiiWZpcAyN
3HHgpe4HTlN/fV+nye7w/efJ7nFzog6mtHO3JJi2o2X402kHwMoO0dgmkTK0
x6PpmI+e80fC1D1S6nIPbqcO5+68SJTA2Eeaz8MyM5RQp5B3JMYNSCgFesPp
rweySdkGIUXh3oen7mAgKDw8fF6f2a9dw3QMTRglEsSORIAUEdRzQZy+bJvX
sNzLor8tinqMUfyGlH9k/J34CFEO8NlS/jW0Wip6CyinKnT2YUS6B76CxsEW
Xaf6Oqq8YRBGxq4IYxQS/chqnXHgBnL8LlClnMkM5tuiaR01FQ2RDcgp3IGi
muoWgGtf6uaJUbsAIJqeMUPCgNC86cwIgCFPcjKNWnWuQn2gvilQY1tUaDi+
KjG8TpA3FgXIYKXP+bAmR5usuFGhq83AGSN/LBaSGYa2FIxHD7KRsUcxiWQa
TyKuMfcZjkqN74mZJWtAZWaYlNUtb+dexM4+9sUNEfsFD3/8FINyV4zUOuUh
Kp2oW4pCI5oHkZyDNb9wgBde/8gCnkKG0ZrD+8nmUNY3TXXD+gXSNSZT9rj0
nmA4QGyAD8Hx9PR3FL/XuSA6PGK6AgUQTbRYrYuctKPQe8MME16FPxGixZK5
FoeQOTsCicqYnY2iM9stO/be6LBq//3t028oQbDboO9aDKiKOk6Q/PGfBEbH
//IjguzHfyr/hL9i/YU/57g5pE6zBbyNKsUmsSBM1oXVmK2aHTrC6szSRO3Q
qoJrpSRbTCeBmb5AkRUO9rpZdhriZaKlQtM1qBZoDo4OuEtRa59YExJu0A/x
4qpSIppngnJOQzGg4/SqHeeXtDm59i53PZl7Gu/U8HqrQLt0RgnZnUURY6Th
C0VsVs90dG0usLelAF1HGOyKmXJp5FfwjQS0yHuOieq8xlXtQ2Xf9MEVzc6C
QSbfR+849WQaT2fRgwJz6bicjyjw02jkuqIR0ylMkMFkrjDGF9VDMekjeODO
otums/QyWkksRdEGPwhxfxLdhPRIQnw5fwO4LDxB6NVu18F+0dXgaKGYgC37
C9w4KW6uIue5uHLDdTDKuruGER2ABSQeVfllUaFWnmM0qKKWEZocC0jOC5iJ
1nqXHcLmfOEvG2V4r9zsOnFA6sgYxgfqPEm8gAHF2QNfDNfzy8ZcNc1JqHeq
IKBL0YWLkjioiCzMEXSKrrAr6KwVq3A2LJgQby5xRgoAJKw0HoeGZDaSGiM5
5vtry07gqLcd53f198CoaUgxiVrUzK4lR0qvCdmmYato1sjXWNokNkQwlJyF
jvwnbbHKhWDGWXWB2DQMVfDYtcx+PLbi+bGXWY+bm7z6MbslwaCsOb6cD+Iw
PzJYSjY5ujCLvOuD4bJDkS2PnRhzpOd7eHlk1AxOJKBYBhqUzCvMTxniB35l
B+LZYjn1cHEUIoFaeN0N8SPaCAU+Svz++Xen30R0mCEvxETIpSMn0d8xohc1
IFcHum4vl6fkLAUOI4ldA0JwI3Yo8dRTRbja+VGZqbwuEL3yFRnQhrJC0WrY
DnNle/lwtqpcl70j5To30dqpEvSW44jLGl1InWxFsn7l5ph3zaW5AzxmKWLI
dd/UyyyoLEKGZ5dnzCvD9zbVdgWyKSfNafx+nG7H3/JdtwuYc90C8UbKraCE
0b6shgxuZBtT3gfJSiyUtwVnAQHA+uyApbDuIDu0ctoUpDTGwAX/iTsSwe1I
D9shsnoFxHenLNNBxMh0Jh9NnqY9Ui2uHNM6vVFWLBIGVJNIMI7UswJVINbR
bKqtaNMLIaFyWU3g0UJZyjmStxt0+3VsIgjZ/nToqVFy0/HD8DlQvppTIciX
RRsbIN/UrSLgMCiWVC7MiYPr/TGGZgP0NPOoA7JZh+5us1xR/8k3oXcJldyS
YpGHMXHGMiAc149MJho6wtottRDOFBubArvawKJPcY2GqMlUbtBlOB4nzsGs
A/qZFKyJzO+UhNoMVUPUbYqgCnje4MXo/m1d0pG9lAzU7BmSs+zw25fPfCg9
ad2XRZx3WdTXOfnEKNT09Bk65i4pLYr+OBOPLSvJR/PsW6b5+8SUBE2bWmkB
l6X8+3KYnTEq8BkdXQHcdlMLLMZFcUCz0k6f0t71SqqUlZIq1JUhTmqqJIE+
KEkPohI7YidrC5KJzNNXHAFI5MIjzFekUOd3EMN3BRrp2GKcuR9fw5u7ZGMk
09jVFi1WjtgY9iO2NeWxquMAmUN9IkwECIxLfn3eFiTENHGqJ17k4bQuyrki
veUL90UwPifz7OoF6Ac1EvJLdIFe5duqnwZDhK9JvjWaOl6jO73kKCE/juS+
BZ+I5OJWMjk1yzXDTyXZDMaIDDIDwW0aaki3FEUZhFKQrz7CAwDH99cWhcgS
fy8KQwE5sYBI5SZ4IE59Keic2HW5U+0gJVKpRCQYsIvOnzRJClscGOWzA/I5
dv1BKL3hvgh0LprKmM05hAltzIGQkafPARYuVTuMPfabst6+Yem04ZTr/ZZo
qgfiDbOLga2cXMZGPJ/6WDm1aNCIY0HCOnFYcWOLAW7FgBsLCj4WpCY7oJGE
k9guVUCkHgZXSOybma5Fnb90L9Syl6urqZUEDN71NNDDlbJZ46+Nvdlvo3FB
wykJhWm6ThuHP1rQu9gokbCTzILyybpAs3fpnHoDdDKxkYCwuQOmd8ABowmo
Ei5OJZjUiayybRccZ4NzdXg6ww+yC09bJub3qVaUOXaD0FKCyUMdnmeklxhH
FaCcZYyQuc1Lb1zw7i0Tx9PIojnMDKFC2bTbXiMGcxPzh8HyBaZIookeibU6
s0qiE/DcdVMtOejYEOcQfnx/hRTD6tsda6VnTx9/wSrJQMYL4qkN//IiauaL
hM4F0KdmCROK2xlZkli+Q0RxF4GxQIUzI5Pm5n6ggYW8qQh5yRxG2FMEFFlp
QIRYF0sS6loXyslUlM85IqHCIHq+MrwUyUfHPNfMRsPjKzcsFaLghIdnI1oc
EujEXThz2RnZF5AZRIqrbaXnH2Kgd3ggCyVHowlVr5p6NWu3NZtr8+61D/0T
Y7BS2SnFgIOqyR5w/ojOHpOG7Gky2UjhLqIQjILz5pibTcnXsI7LfPGawqs1
C9bKAHxW3giNxZlQUyA271OsRSEOqn4Zm25QZiuy7+ZZvV1fcrEGDlhBnYhq
CEigrFih1GTl/My8+eOVK+Ci+D0AHiYnABpODaBE5BUNHjPjsVZwvuawdvUz
CdjRgxWGuAyCL/b8PJhkb7P4h6vBtIPPKcAjNfoP46OnfpKjPMCFJJdOa7Sq
4GF3BJ+8pQAUnytyOINbcxSN/sPI6D/Y0c3KEr8N/0oFuPzyoeCDx/6Iv0Wb
UhSo8w5DDQNvQnjcJH4L/3qgQ+Hopw7h+KMYW0Zjk+jnn3jEf7lzVeMYpF89
2L/BvVBJf8Ub9JVRdYO/aKi7NziI77Kb8j/jF8CWfAR5Nqhi6MYYuZ+pSdNX
M7GEeOUjl5o3YsJ4E4u895xDCCTCx1BmJ9eLRJA9079HqD4GkZ1SKcDbmhNo
7ChcaKrwyW8yQhClSZaBjisNUaQ4h7DFgR1GJvfeETZyr1zyoIjSqgBEXyBT
K95sXGGNdf6mlOoXVbmqveszqNYXlH0zUahqMEI/qBE5U/OSXUV5D4fVYPoR
pYiFqseR6klvUM/hal5vuAwLGxzCYD48le7YQymqiNlxzcYuLBO4oSoekmaS
DBL9jUnAiWNl4nMZLdIWPcgMmCy8UewjrgdrgnBJNozKm3Lw4A0G/4mQ4KQA
0eNNIU4Cgo1rHQuWnY6G39LMFA7rFDCr4YGUFSM2FmIrKVjKyDOxdVtKvLVR
0BAgHKYwkHIstbi8F+QWwwWwmmnZLbacNE9LoVIlopLOOViI0kl5HYqd0SJN
oq4TValMgUDRrRXZP0i1V4CoLMvnHE48HdS9s+GPkeEvtmPjDAdemDjISMEv
9q5qg2nLXc+ZcyLFUXJh04up3Zmhh4/CXcS7UnZrMQmI1EUWAZXAbIhbkGzk
y7YHIutv0Ogibh/MFeaQLyNom/gnL8OqtVrF6iAycepLXnvrwiBcaC0L1pL6
POCSvbJyZRMRZj7gIailF1yaaRS0R8ZWTJri1Bs1H6NdbJCoRcSM+0bINVGX
S5EOfTy3qUuoYRmnXm/2KfobJev6Cf/6l//dSWmvwd331RGZFUgFgijfLA5j
sFCol4H/xIJP0ym6IPaLscZJDRKb5vUMIrCpygT2RCUGzi2eoUDwTJXztJVK
vMHYuHTDqsSFpB+GuOC1o1gpcvdoERXCI4xSo1NA8PX4I0yVwDZ3zJUUKaWM
d+cPYbsu+/quwhAJt1sqZaNbnXJaEk8ZKLkcH4pGnhqtVjaCURI+aqE5sbMD
1zAVZ5eLn7Z7Mfyk5yzpdkg/DSr5mG96dJl315cNOkSnDjHJA2kVdJ9niqXu
osAXuvLmkC/Jr8rYHV4kIXaROjcZ8SF2QcyUbvdWwtyk0C+e0BJY7opJGdew
4uzVIYUELLBza3mWEAm8iUKMRJ03A8oipJLMPidm4Ehk9EUzpo+NcoPLCVl3
4V//8n+EHv/1L/+RcLo2sWtURbYojAexVj29ph7vWKy+Cf/YAJ0PU+hwB6bW
/TfSISg7RGO8kwY1myDpmyWzvcsGEEfAO+xFqB9vZWhf+h5FE3pNOShnqPLF
EifO69BDLFSMja90Urx094H4ZwnBeIwAg1C2bryf2HBYmMpDwg/HMHZyybLM
Kykc+wFVoxYZBH1zAyGJTNRad857WFweJK7uILaJHIilzBdPDE1brooqyfCt
WQAXU2Y7uS+sNER6+85UTyb8kLOa41RHV6NrMPXU1AfaV3eC+DYSQ4AjJqev
ORvGed5MsYuR6M+gRExtCGdZq2vaRXX69DbQiQKHT1jU+iow9x5NTXxByMiW
TMq7vcB3J8ROzb5ZFWINtSggmzDcsuccB9QXeUVdMZyB3PU+Rod5SNl6f43E
0HkDsPAYJu6V8gFcP0IkyBvnJMrs8OXjL55eHE25zCp9qHFKKjjDvuD4NtfH
63wTyeo+4yD03fssaHPIIq9cgV7piovrKrvrcuOFWFt/mi2qbnyPI3HeI71E
/cgOqercByNJK+dXRn+0MTG2GtFQfpoyERl1g4XayMFVftlieWtXojvW6qi0
Q8NZSow0IgbtS6jx7mrW/6cScc3OHV01Z2TrkyaCgItMBGUike6iF2SwvjCf
1QWSYgorIkfRh6kp44v/sJPFksxl76K4TTlOz1eJVWnTHrCP0mgCecTK6NFx
6f6Fs0+1xmNJkwKalJQ0fCi0B4MGGyyAKgELJMoY5ZCHY8lD1EPyf8ABcyCe
BNqW64Ly+6iSbe4d0uQgBiA0ZNzAx472HLgU7Cg0G2qDF75elCrvUNUgTsWl
KGTWr6wHuWqQty2a7aaSBAlT2MUHfbttoTM+NjygjnbAis/BntAHBZmOWbNW
qbKCKsTWphXSi6nU6YmrCR3ky3yD1UoPlNxrALIzbvHqpOLoGDSF8ujb5gCv
1GJj/ZacTWY+iL3GM/bpOdhJVN4wBsVPRQqiI2LkS4VfEpbMe6i66ZgtbzYo
TJEQjiaQDFq+ASpB+yCoPbdXYcdEIqQPzs8vqTMqZyJnFb2Jglt0FlWm6Fmq
dq2OXpGDUeoXTRGDW5jn8VnvpvyUBliH4r/R9DWnRXKCHcz5enJlDscp9uAM
tRNx3kPRDgLyRW50l2UhrGsT5Dc6S+EeAKO66yvLSknhWIEW4chFWCj12pQb
KgaGfNj0sGCBIhhFRFMWODWejuKqSXKeMi1X97kvljMNT8kYO6lCGcXzUY3A
qbb60AvNNMlUTbIEYIPFGlrNwYvcbOgMcBZJKh8S+wOskGzcsFv00bFglnAi
W1WTpBbnpxiXBZz0BXd6Zu9pZyM9HfuK61aN2PI7jZ0OIucCH4FvNWTUD3KI
Ecp691hy2aHMu+0xalLJx7AUMRcHXRZ5palY9CDFjQjRAH0C9TnTrgDlz31B
JNZEpMoBV6LD7SmTx+5AFci6/Jqx20iABMWA3NIdVPmgw/4NGAPDAbsUhqLe
UIKN943+/WCDhvUGr6BcHGzwY+T7IPZLy4pIrhtuS9HfZIb6iBsGYlZQ4SxE
3CUopGTDX+evo2S5qGkMxj5F3r2EroqONq44bQi6gxDpwCG2OwdKkMA6Uhsk
4cKIivgF5k1T/ecsMIkal6Uc8x5HKx28+T6+rsBRpcaKVTCnEm+kTNpJ60Pj
q0Qrh6VvWaK6tKV3Qh2S8deWYlRVzYiGPR+t082cvnaI4VpHXEbAehhcJUk1
ObuYwKfOEEdZ304g4FAl9r/sIhna1rNBgwm/e920RUN6n4+ujEJkiML5UlA2
/sdbq5LqzFCTifu1mcCz0enJ+qPxgwRorWlrEUXmNNYfk6dlR/MBXkagh2vr
Oc1In41p9uzJq7Pnz748fvnkgn6ZUhte+P/F19Ps+7J++XQKV37xuiAlBZdI
HNK30kq2q3OnZBNqrSlyfLvOlmUTKjpj9x/UwXKmvw9DChlX6XmXGKZEfMJY
4MZ4ZJMPYohmf8eVxNERNubBmw0L86kHa+LV8RCSB3fByMAhDp7KOPxlWJvZ
Ww7vgMNg9jiAZwCHfTCPQkNeyJW83+MGLQc/Z46SPoZb/W5L+uHdd3BXwM8o
OPdg7f4Qq8HsCaTYE1ulXz+wJZ3ioffDwB3FzfC7B+b3xNf86vC0/ant/3qS
jZw+Hnbw7PDrPRv+wS4x8fXfBqsH+5Djnpd6DwPisDaZ3PUkMOvRNYxixQOO
Z0ss8YF8PRndoJskezu+xrf3G2EPJHQNTzgqwf78G2gTJYVQ3gOSdJzja8Cf
wxdnF6hXUBkJ2IOC9GjfFgTEqRXc+FN0P8ExBSPsWT0tbNkUWoCD9Qu7wFTM
nE2O4ai5x4ULh9oj+GLsHIXijx8rycZ7MBMXfGQKzFutKXS/RnELySgFV43U
yW2+/pYvUGlqpiO4Rnz+RihOzWXXQrNSsTA7Ce0cxg9yEr0wNWJJ0ySYvR5j
E1y+RyMWM5EJjjDF6jBSaw+r58CXs/Qi1EPk0plIuTEBekibO+sctJUzJDFr
YK90FcL2l+a4zm1SXAgbKaR8l800OxxmBsZ5gejG+bLZtoPyUQYZ/Bl1ikVO
ypUslQ+y0+Xs62Yx4X+CY/VZ67nx2tIT4yg+NSdOtdhtuUCsRDzIolvOrgcT
k2XWzOfuVG4bAmC8Cgh9r4ud243vLX58oX32JqkPx3dKpoN61ZCBj90S5eLO
qz3YVzcy05BOjOwpo1auUr91icEyYcKT2/NzbhnEJozJSI2yaBFtuVpRjKwo
x40fY0pVCahWshYqZKIxHZRU5X4kSec6LV6tG3lYJTqAU2NXHy0THzPV3uqi
pwq9XE2fTMw+VjFQIV1NMx9IadbtbEQNW4LpDQfOJ977MDG/26UJffFQlPuq
RabZ461g1Gy/oHPNudajLtJTBIckdRaHUFY/Y9FxberlEl31bbFuboqlRPsu
uaZdE7RScjVFbIdOnwjpOlOqqXjbtoX2Wog7vEzDdiFsmpPiEPny2sd4UPC5
3jRpzzRsEmqHBoWb3H3bNSb8ddjWPKuKegU8alDzA90invvx8jW2Dt00Ak5b
sGEyefJm/zEkK3t6gwB8Z9iHFEClZcmwUgchDob2niaJUZVILeqXEL1KJ69k
iL1EQs0okH9IecYxKmZzvzt99lX2Yttdh9GzmsGoUtnki21ZceQdVtb46adZ
ly/WfZB8sC/RI9+u1s79P2hx5wRJAa0KWFodb9Dhy5oDuZA8QU8iavdJc2L6
48Rok/aWiCYN5MaUrSGQHJPGiPtKjYkw67T06DkrShGBf8TVRtwvzpLp2FRC
H5OOtWa76/a1j/iJm9HbAq3VFF1qri7BJbC3WokltZUyqCoDck5zLCQ7nzy1
CA6ttFN2U8PZbtUk6EL1/bqxVCM2n8JYSuqOGhh6r3OTRM5OjFY8DMbcaoN8
E0GJ6sEKShe4gagAciKSsXP1IBghkCl5kzk6Ujo8WZPiLQvbs4K5tUewE6Xj
IB2/yT3lGqRhRQAD7kfFXRDCdGgkvMby6i364prYk15Fl2jP99MsEfo2VTEq
6ZxAroIizKblzp5xxz1NT5K2j9KJkSJ3aNt7FRaAw64s0OdfD114U5etju1D
mDPIkrfSWINjVXoN8ZKYQ35UxiPR3CjBCY1aq6wHhmFfWP2BfdIq59aWq58n
h2czhdueNTCEtqm3I0MkjRbDTFA47gcBpxAzkJn7pYROhkbeB8YuIZOYdfxg
P02tLzQjjaTqJi0r6R+/Igt7+urwhZeNjvaOsGeyMdvyBd3JIbQme97aZ3mO
ljNEAf/AnpfvsaF7jjA8Zvtzh7F6YP1PZY3bn/sZrRPrG7VLjpkrk59b58M7
wuzt3+fVlxza4CUK8yPINQkfI3Lmf0wz4ODHI9Z/3p4D3DI2/wcWtx4EH47g
HB0czuX2byZ+mxnovXUf6meW96kxnIezBM8O50VN9/kdRtf4iQd2uMh5NvoT
jpA00xqGODTT7mHyAzPtECiBsJ2A2eGLJxdHcaDxHaL3IJVQuLG0cFdu7GLS
9woGYfZs3jtBBORK7FJn6teDrFFiOC2osdyqMl5WK6GDtokTvleVWJXDW2hD
UcZL87SLgaISfRoGde/L9PR6ioWP65yuJYjvkpt8Md/yKpDu10XhVMOO6nFH
Gwvj90abUuWJTd5qKa4wJ+ix10HJ62YS2VSgQ52lkDKbFF/uW5idnV9kXxT1
4nqdt6/x3cfnF6fZxavzr5zivE9+iWXehIQjx6HZu37DQSCSqAP0chP1gx2G
EE3VvGPKXO9TMUmrc3VKnT7CYraocHh0CIBlw7Vs8M8hZsbFTx3qOBNQUNxR
w2qpROTSOlc48YVwYFmCFoOaoAAgTjbDpSiMotVwzbuoq7eJ0jM2ML6K0bMD
6xd1qco7NyfZfxJTmlZrrjWiNpE20+IfyZljfd3g0EBfN7S47MJwmbtrmo8G
04xRXvUmPWFv0kgEZ4gEPj6sz980dbMGYslRlaTNW0NG0rqiZHl46X0TNUeV
BQ/VbuypMFpir3z4Fxu0cB9i5bA9AlhNd4HIQ/VbTQs55W9H1iV7jdHacMkp
6XLdplISyumiWDovRCKXuGVAZ26Q4ytKEnwR2CDiLqG42obIBB/dYhg+zJH8
GECKVkfsbZU9cZGNpk5nN/EfJ4N4g8RpH7GnNqwoQtL66TSZ1tYPmYrHhpKB
JXjfvm1yMV0evfSeDVP9XYSe5vDB6rabZU5erXzd4NAIFknde+qqB6iEYQsf
RGMfVEW+PBgpgCDt+rZd7zPWkQNhsWdKV+PE7KD9xlSTGKLyyzgQKIUc75qo
zjAVa4M4naR6MBW6EEtJHthfOBGpi2FMgbwesKEz2h5vLIRhqKyQCwUgbdxm
z6ZS9LGYHGMwx9UWqTRpaSZC8eGwGziB5TSI/aSprsoWawdu8XL0Ugp/X2sP
vtP+cb3B3XaxoFWFc1B2BFDbnCt/5nFm/Ei45UBaXZVqnTy2gPehmIe+wstL
8zQmQWtr2RDQtDKqixosL/Z91x6iMwovl7sQdANw4uE0CwK0XS8v5wIPb5Lk
aPWugI2pysEZJ1eNVmMPqgRx6oJeoKe+pIXfy6AEgSCVCgJp6Dr+cw+Ankwm
syFITbJe2ItCgWHOT3z/3TQ10EhLC6lRWOidD5JxsYsSDGn6BUhZX1NEJKQc
qZmDShnpzNOwvUvtu2SFBaQBL13KretNQeELcYVnu+Sjd4GHr0NikrnQ23jQ
Nrjdg+yQ0vwQOmP0850mNFPwDB92npcsIxLsuVVsyzexI02cg4RMfTeHNVGF
fW5vS2Z3j8Jp9A2JT9mlAoVcepwtgeEZr3yZR4Z33YYpX2ADF9qgzsmfJISN
K1E4aQJFLklhZMF/fVntYjWOamEEosY8dTjKIiTTw4W365XiG5c4a3KihBSA
DjBd6Af9qSNfGZiF5e9ZqMW+SU6WvSyoU/CefdgCLWH1ap+VbDOf2H0lTShT
hGpyliZwOkSXXTe3rGA4/clU7ZUeQaroDvnrbwIuuLcj1jQoJ0PFmJRM+9CA
ESCjgSPAamEMfqmGnpq2zVJF1/SDLjado9gmC3LA/7t9AsDgfc0s6UIoO7uM
k7Q2MdaFL/iec/fg5INVMJMLcmFN3WfDH32JnqEo4hqfhMs0rMvdMpdV6i7T
/hOMDpAizYLHz/VxOtzRsQI7Fa8mSiFDQaQuqsAH7mqRkcqys3TBwVpjYPxc
puixASD20U5TmzzAimFd6EEDFcnV8szl1Gok2dew3O4appuMPjLu+gyavpQS
jWOaPcWFwxTn9YwYGNe6BNVGqyLssHT/Q6dsbdt5TL740PAox2JVmnG7ODYs
OBBIBiGmEe5GJjOf2hU1d5U83mH3QndqAiCfGRQl/+BZfl3kFez77LpYvE4h
8sE1P7DABw6k6f3w8CzKWVaKnx9gQnMNq6Sq8F4IiRVdBUvTIfPfcUMFKpbV
+ZxjLW5CIWVRzY26oQra1MiXrlysP5z+TmVdE5JkSpITRwvISGD1lYL37sZg
AXCMyKnI9GwYyhilYMXbgjxgnLg+yeXOXJQtgfHA3KeXxRUWij+YMkIEpenu
vplzQzN8o4OuXJfcEJtPDJbY9pdFHraZkIpG47mJHqf47RRC/fUv/+dav//r
X/5jFKNyIyR462J45zNXVNVKDqgLdFqMIFHVz50CL0J6EZhqY6MHVNapGT0/
jSQhrQeUY3H7PUyudJ1KlwMK67vevhTCPTkNEhcXiUcdjZfwP0b60HQ6Sgc5
TZtqQkSMRLiXmsOiTrN4dCYUeGHY1Lcu6dJBiMXRuMBDeLxTtYTo87Id7Yvr
mEMeyBVE99HeCKfX1FhCQXszmCaHrM4v91jXbFAo2xlZmXCWgL4JbA+sI0Yq
vORtswnhmQ1SnJyyXgygStgnOnMlfDOgsKga3xNtgGiQyYdzSlvCyyOu1Mli
Z6hbIEzF2IF1YpJLYVsygT1KRsYmaASOqP5hN7XwDiwvIprDptsea1PBHq+n
bIzquO1AXlYo7mG0k888d52wp5xKoJGniDISGetLPRozU6xwBIZee4lThl7V
l3JCkGEhVuHsTPnHSmg63mV0RGHezpbojUaL9JI49DCWUUzpv9wXboo6s9Vh
SzefshPWZKR7TwYEI2y6CUNNKvTFhc6W0JqgtpQxzTtqFBSHMSFL1BIybD8q
N1v+/aqseqQREp3r4XxLhWa1okkkuQXQAQhzSVlyHDsxyZJJu6Bh+jQXIhMG
LCkoJrX4VTSAZvR0pgdVlNswaKu3Jxo2qs0k5Bmjul1fJ18PadAIBHOnbM1P
kflZHxOvkVlZot+iKeFLNVdwRPLYUH5Sco9p9/qhN9Y4t7ptxmbkYVvxUmvB
mv69d7rdHIWaxtlbrhCFq6zwQkVEc6QXXlIaZP5MBxjzjgceiGFSTGMwC9l3
2MCWV4Gq4MrqSVxBZPGKureLDZZ2SOyPO6yi9KnZVZmmGyVB8cp1x/LEGREk
kXPEkJGUItNYlA1KKvOS4zQfGoSdJuGq4I3l7vlglTzYm4TTik3S2rtN7LHs
VcqjbgTAB77xkG37e1XlK009XAZOGJt9YbS6HCgUpR/QDdw4E9X4ZuxXNFO+
7Rs86gXJJNSIT+VwoL0s4hT1KvJkpRK59HzPMCKnSp9ujMrLsvOutHvnlaHA
QJdgZ7CRaTuOMzxrqsVR3JTcTTCdhWbgFJ8WyBNBGtb7PCkCVpUnz4rnTScD
wmxokNhUeYrKBOlvxzZjy5wGNWjHwl/dArAXYC9u4325Esabe8BZakV7oKlb
Klc4Bq9PSLYRy/E7KXtoyhuafDcmIUZMDgPrfec5ZtU6xViEVV5KRASwkbIO
wseYGtrHtZaUCSbgyIigzFCUnHsXd9Br4Vj6vc7mnlx+yNrZv+Tlsbg5674a
MId6XnCRuBa6yvxqFnTuLemazjTWJBSa5QRFdXXkSNwJzSHeGZY8SxlDCmbR
8iOa818XtAlw7pGbmCqwYqtUbBlmhR6PZLQVb4oFFx9sNJszHFybvott0afE
DJC4m3zpNAhRpbAWmeXAe7GJygS4LjQVK3n3Fd/kZjnRCol75LpO54gNr/U9
7igSsCB/p7fYLsF3iu4jUqRnvusNn4BWtqc+J9h9kI1Qfmm3hS0SNiL7m8Dw
e6KuDXQblf2HcWudhAz/jSrAk7tVALPA/SoADo0Dqrc/2uhmGNnnIr2QUku8
RVqk3x9u+otkenNUQ5nequ/3lOnHDnKPTB9owe8g09up3odMb7H2Lpk+hsz7
kulHwPdLZHoz1N0yvX94n6R4Z+j+uNQ4vrEgkvG9CPjDJq6xgL+PQKUF/Ls6
14QC/jig3l3iH4FcWuK/5zk+uXgvAn4YnnyHgH9GufzC/s0BnHKVGAwrnq1a
zgMgQxraUtilODgCMcWmDPo2//gqdRCOfHNxgU6cbenCF+Ll4G7GV0rx3490
LTzZSi8DZNS4zYUFns3QkZ17Ghx0ct9rA7JNzWJp2bf5MCbNJEEWI7HPvhnc
jEZbWSjAqTguFkUh5FSz9ZAzRrd3FIEiyy4ih1zivzvchnFiSSAF3msVxrLR
9A0veY2t3/t4c+bCct+kBNlES5EFtc05f+GA/KbsiDZK7TSMIjEdwXG17N23
buBjcj0nFk/BuRRzPzPistJtEyobdWcu0fUoKwu0bXF3Hfy5aBu8udveR2Cb
crsh1zBkwC+Epa1V3mLIjQuYW8MeiAbWfWgbmnzgQ3e6KKi104pMzkliSycY
qcGmHjiv+2hZ4b0FwLgZnsMBF8X2nxtMZiPEhsFTg5ixfU7X+YQiJ72n+dVu
U5xkjzVo51Ccv8cvxYl8BM9fcIEVt8+TDD3DtgCJTNxk/97EjeC8Z2aPXji1
t//c+Pb2KSY+hH+WvcrbVdH7JQLhOHFR/VL6nKMcXjA1mnzPpYIGsXLGUmX2
UPZ86xxlKfuuqK4GfmQO/xFliTFgIydgdELqM59XbZEvdzOK1w4dcgPRxVU6
mLiHZhbZZkJMTiZZ9tOJfyaU2k9+nkxGv4M3/Xe8gJmRnQ5LjA+eBYgWRJdx
ycQPZs9fzj4IxqIS/3ZR+AEsxT6Doc/BBw50GPSnItiRXT6NAu8UNTZHcHvI
splecUOTZuIujx7wVz16wAfmztzVka9sOzP9CE+7++96RIxa9tIqLeWASqS8
0ygYiy0iRb0cNSRYLhiEcSF4uXUIQpHztMJHKOxjz9F1rM5qZSRtO4PFsgxV
MjcFUXtTNTtVDmDq4jZzPRyip7GgDWaldBqmXdH1sbK4qvJAgILS50fZ7/cg
5R/m0dV2DSf4CKz/WgLaunBxH7q+LAQBHy5LNx4PhcJiv5LlpfTLafbj3jX+
OHXHb6Jx3RsYXa9mt5Gjn0Znf8d8JAD1tm+BSwOQLCXJvdxusNkzxVSk4uQk
/4lD+pe4zicugWR/XE9jd2uDQFCF8ysYBNnCixzhxoHug4BaF8/kQ34UASTi
SYm7DcaTLrH4hDPzhMWzjIw6cssAT4Y0Gcs2iE2Q81uj6JicElfj2/OhZOiQ
MjNklj6J3nekwnJF1dXM8R6A4k3Z9lvp0aZGNjz0X8I5GHZ3MICT/TfR0b7w
OPyFvPC24kgZHgS7Fu+I8C5hO77dlNHrsHAYnZd923lhXJYsiBATMTwEijjw
SVQlHWW9dFkh7xDv+yoYnCSL3mSg8thpUxbml94yg9lD0ocBPEzVNeQJsyap
XiZloRCdJ3F8T/D5qZG+fXoHqoLeJsE61ZRsGgWbK5mKBLqfTzxQ50dLaZo7
FeXVvGxDIkeD1pOpLMxHkLrMkC3lqH4/3oYtewNyz61yJGqe4+Snvvd8vyfW
lkpjuZPAggDE5aP4NUqVtR2COWQcOagPdksmbgw1AkKgtghMp5xmw5njym/G
MFL6NwXRnaaxG1V5SAR7mtmkSK5ah3zQe0S06ei1kBpt0oZZMsa9a5h/ED0Z
lzIxzWSjbIYg9lO649gDauKwa/FKkglYrP2u4wcsAHMAPUTmUQvfvV1E/MXP
zXaYaQfpdMNyeq6HoilhYUNLCD+Og44dqvqPBaBSnPUafWh5ncwbdURJEzcS
z/hiLFJRd2cliSjOz5aqG7K+trhqfCPW4FRxMUxIgu7KQUKHdCUJKsDEPqT3
pwSnEOy/iMY7VHlfRXLIKEaoTKxSkZi4NWFA80VtssC3L591B9nhqy8eZ+en
z06ziydnr86fP2OHhb+lzNl8BGTQajzVMWZiKFGwSJJXzBus/Jmnt20NQgv8
/w+/+Jv5fG4Fm6Sm8W0y1OpuIIfiIodek7Kh2sDoQMOUJAo3FRkfRvAugWkY
cOHqvA+a0g5Twg+TMviR1oumSAMR193j1heszwd14D3pE7OpYMLcwTchyMey
mXYuLBLifOSV76OQ4WCXcHrHdhuxxu3sir6wjmEhDChXASSMoVagU55PKgF6
x3p6btHjNtduD46m+AiLCktkmZ0UbYuGeKWCPnTfnXHI5oxowTgqkiD3Ob7j
roVKwp5LdyKV0cavVBYYSWeckXBCqfAUlv9WF6YtOOTIZoKYs6adcZSL4h6M
jvvU4RUk8LH+Gl/z/6qrjEjNUImiAhvhaWIWitg2lqEmo2aAUfpTuuviM1/Z
OzmU/SLygD7WAREgJ5cusfOk5NhTCYr6l4I+mmESq1ollwXGMld497ZUJD7W
4gb1TIY5hqfq46AyWlo3yEs6LsHK1TyR0g4dyf0g13Ls0Fh9CCTJUu3dcjHG
FdHxbE6jSWP2rgHSSK/glqL8CoJunch7CUpOkCvFWG58iQdKefww6FdJVh2T
7+gDKNUl6HNbfPqjdLN03d2L+WqOBbrPnzzF7y+en748snkZ2zq/gdvA3kAb
UvY+hCyVaEYEnv9MGWxcyLI2xT5Gg5J7hJCp9WADADzwBJgfnNGD1qbPIDzJ
8PE7JRJn++wZYjar3hhBg0XJXNP0e2i9ZTuus6NReWu2sBjkl37FYT5konet
yyi3sPi6qKrGHiHqtLtm69nzf8+y3+H5nGf5OkgYTV03dwhxFmRUNo8tgEFp
bowOWeO9107sgu1N+xsGQ16Hkmtox0dXJcUINbHd0YG5a9J5vs3VFeYRStmo
Wpo/4RDT1B7we5jtdQGy521e9upskM4KFBadr5utsH3fDGUoaYnTguYyGcbj
WDIQy9iHgYdp0umFY56MYLgXK9zv+srd7DAleh8kJzgI7XqBaVjSCsu+C4mp
EHfkPqmjNn5ChCuQ/fVGFyFrmvvK42GvejabtTlq/ZR8TtVwSFYjMsxppGhV
43w+F0OPZ2RPhO0+29rLiVMJqCkpzGrRFs7THuRLh8yR0C1KvLMbJfmdeLfx
2Riyi4u4pHCP3mHwIQDtOt90UlqHovRz7icAr3r/EedZBTm0SU6dLljjeGNk
66IgRtulyxRvIKSWlOx78+QRM2MQskF6FOe1kiclvQTHj+mArUyvyd9XzLx0
AKEDQq/+fzZexHYJITZs93RcraWTFZZpWSufeZKvbquuuD9jTToVPVI5Mln+
Y1mnR7BfwDjDtSd8bX8HvhnQ4XtzzfJenHKw7n8Ir4wx4G9ilA5f/y5cMhr9
YMz1xX4ZjJ5GFun3iBBqFW2x0RKm37drbDpjUuhzBTXW6iXjeVxGRoqyigj0
XvlkeBpDZglMKkgqcypNTin0gBCCoUd72Gqq6MLkS7o+yGERN/DfJXuf+mtX
yYK5ITsquFudA9w0iExCIBAd8fETwmasuSqqWHJIqL0TyMARLYq2tpT+aOr8
iZgEV3abKt85TVArWaiiyMOIujhqxBdykqqD6TktdRHsylUthXYpcjIPIsqw
4oezJcpog/JDVHJgZ52IntcquFCTH/hmkumYnL3mZ00VgCnZ3uKD5W3akykK
YSYA2rjC7AFTILdecoy3cwKq041tegskKhp1mGL1X7g1Hr6Q5pta2eD/HWYP
W9E4UisaqWMyKWzhPbBtRpP1TFTWjeWHU2wKKT3ymMQpOfZnzuG7KewNUk2M
nKdIqWEb4p4K/MwfdtmPewIYfgT8VCPyWACQHpPMumiWeADmSimfhU+LfjGf
qofWOl8dbQ1WZ1wtPPrMbhx5jvru74wBcWZNb9XED3+fJzOO4piRtLhlbzeX
3tLEx6vEOUwz0/YrUBN2yBw4GQNew7oi/vtj4/z2Js/bfBcUKRU3qI9Dty7I
1vTbJbp6q957DCMHhrJaYVi0EOqmgoeE4kpW5qCqDQUMYJvfeeY6IzmCbQO1
0lV9KPQFbldVrkuJMLAu/ojPjsVRPTs+HQ/poS8ndxcmOR3kqrtalIKlY2W+
ptT7zoNGq12ZPnf7chcZiEFdRO6VO+WIrVlZzzjvxF0kX11nvCu1TwSPu0QT
MwQILbcLWrKW68pj5jVN51MitePYE1sceE8kx5EFhadjISqMRtzAF0Fah6EJ
WVSzBw/K18SJfI9jVUbYEy+3QOucBz1DrRfSJzC4UkOa7xGmq97ZhTzcR70Y
rX1BFMV5TwT3YAgX/emQwagh6dRkpy+xaEPI7NDD9Xnow3LIaVAMKjUtyxyU
wLVp3NhxJI27R8NoL60R5yoSB7gJavGgWZHpdjTaz2i0Gddb02RvvMnUnpPT
pkoPpBnZD/tXZBqDPYh+de3B3pr/j/68Tf/KYzyc02eHF3sa0mWfzP2L/slP
52/f3zrexxgPtIPX/vM0PzfRr/6okz/37wqXOOrZeA848xOfevqo72yYlwLP
o/Co3348v2MIixRvP5u/v5W8jzGiw34wuEoDLDAfRIcdsIjBcsytTqby+RXF
E961osELk8nDsKGIZbBqt8KSIHXBDb3bIq48l+xQO3nEwwYbdaa9UdYRlaTx
3LFjCTPgfnZNYxxw8nFiHb5cQR5qJL4o5KWp07Ev3LCLOlslEyO51qZvtzP5
hBe1Z4IotWIPuBj2ItIs+m3Yxz6d9c0yV9jk2Mtdk0/vXN4YBDGGwdQ6MIsf
LT5y6euL3KsI3HTyWbi85BUJmpjtW0JYKtTEo7LdTeI9VTOiJk6mHxun3JD0
DuJ+UJupyi8LjONFmmYLYdvgESydMKharNGYKRVkGnV7T1bwDSXmSCD9JdqD
zREd9EeyIrU3lu/VIJrI9KXREaR7LkBxYHCjTatZbNeck/KODhqc5N2NOt+x
QD1mYAkAmXapnAZU07Q83psjG5hCippUj8gOafpXRXV3tNmz6+aFdMGWo3bX
nIMQIkuIzWZxuX2WzqC94tUXj+/vykkT/T2UjHNBh03PQu0oIv/BXcL4TYnU
MUXqNBIy6s+npXvH6OpCfTKuDqknTda3+Py702+yIC48LmOGqjY+NSOjZJl7
O2Yj5YVTFoKQwbq2MI3rkqRx3AN7rvjdrRUldoZMNczO3sMw8FFSYTQHKtHq
Pexf77wOezwmzuoRIMdezdOH5gXvBNF5Y0foVMdYW7OhMHBNcDBfBButpA7n
DNmPtWUMtKMg0EaQLuzBI3quj7ZPadyuR98eM/E/iuwFdG2E9u05p3HnspqD
izdcEmIZpBwFx4qnQcDMu65ZMO/ZV/VM/ZujwtHymhOFqRgXMe51sywqEyjv
jRM+ujg2J6Tj5/82QpnyHvqCf8nqrwGx7PcLZ+KbBRlF2iYCCy6XSkQDgRUR
ni5/p2mTKs24lGcXIN4UHEptkJ9cRQH9w/h2D+ogTh3A/GFIsCnBRdzLoc25
s4skCaNuapmYXHw+NttZ41Ec0uadA8xKkYKNiEhwrkRpbGA4Q28ZgE+8uIgu
xK8TmURpcXvItsZOVgTznWHZEQiJYuVCybHeuhI6TSDxHb988yaM5al3afbv
SowpBozVah3jVvdSk8KMYZ/bFlXRd/xLq97dzcEMCpM/sVkstu08e8IfoVBB
n9CB7r1VcOfFTcTXxEKLFxBYHy3s0Q1iShu7Vgn62hAn9rFK9Cy6e2AtqWH2
l0llTALG3WtqTZU63jS2ei/XQppsx+jrRQO/og9jUmmbBSdQ445yRUwjrSt3
f5UZfzUxzp1OtQvIV1AG0wrP9yD804zCtVnck0i+6xx5MqBM15eLblCIqgvo
kjgm8j2FV015DJIaE62v2sg+0SaKKHb08jBn6B8lSeyREu6QK5JYcLdk4VJz
lJmPo5zwDCu8GTKIlN6zri4UE/ZJBWiM6Ar7LgW2GMe4TKzqGJYUOeZSYpu8
lI6ZYgcYYGhS6JDamyhv/J5Mge5xqvoyjT6jueCzQTbMQDI57e60v5gk/EC1
u2e9WQw4Wwu0QhML0h0m1VE3M5e5Z4+LcjaKK7hLJQcUB0l5QXE7YCZ1UzWr
nd7ScF4KndlgrBrliPNMgSvXhyAngGBKXO6dOdBA95ASqi3526ffeLemU0d1
3RLjgyQGput32arNN9feKSvVCobtt7NnRfPJvxPwEVzjCqgqXnsRwSpipPXg
CUZhhvs4gIn+CUSvIPVqHy5JOywXC3hLgCIX/WVQXDxWaDXaKSC0GtE2R8nX
PRJ4M0PaatMTif+0BYeVcVBkzi01GtcSy61TSsOZJmd74Yxg3VITpmKPzBQk
SxobgZvVGgWC/E3vvv7Pk0rstbmrYvV7EVCyOIBtTBLlGAN3B/2sZBgd9GGf
slZTkdznXMjSEzFlSol62njKd7Co0G5Asn3TbA4cbdtnSFQ77jwZRGLKT37g
O7QPTMQpM428Kt+6v6wcF9R59ix8AnJgW97kix1QAc5BlNqEvwdl+Q/4/UUB
ZB8N4mMPUPp76ksQQbBbWFNWRbupuM/HssAc87C4IIo73WTy7cvzk+xHTEwt
i/7qpMsX66iI2o+Tx75M2gldTgqmJOHfVUWLG82HpcPIpLQueyG79u4Ocixn
JhsvMsOcqaUQy0Q58M+SoYPw8e+fPn/55A/Rvs8MzifSObHEgOcbHKU7kmhP
4pKgU9BjzxZMcb0xKaMXVTMnBscR20hsYPbhcfiUYskksNlHPw6Sbn75FuJ0
lb/j+nkqWXwittnJ10fvuqF93qK7VyhvnySiFPct1igB77jcu0JNxSV098rd
QCNrn8xmM8qAmgQE5nGD2U3Z90ImsT4q9twT6mnzlbAWEHDIdd6GrVE6HWrZ
cK9KsgIwj1fq67ruAbVCNnmSnb/KTjuM9+fbzsni320rrIEn0LHfICKeSTa3
SMfuWyHtwwEntrXCKyd7UufzXmrOaXGaIu+w+FXHbVtAHlnCebFf9aefzs4v
zp4/e/Xy+TcXP/8s/odb7rXWNhWKy3nl6qbCQuIJ5rh2fDR7OAUSpfl/sin6
Aujn1yAqUDU32kfHJkBUEA5OKdaU/f/IfA9NsT2gjovXU0mRoPo43B7xWkdb
FmwfFm5ZFz2eCoZ9snmIUma2/XXTkiCtj+OrnDCgxjWcYlubR/kDqd0XvHjV
bOul9DYjBMYke0SLlZhyecz5gdv/oz2AuWiu+vcHmE5HuydA3PMl99uDMWTv
i1y7nhSmOeoeENmhRkEkczjzsfRVaer5AXrUs25TwnWTYmJUYK3jfphX1l7t
Kj6XfPS7BvRI3ephjmlhWHFZ9BJ4usuq8rWHBukJGEDcYCwrnv4y3/SFxn4f
TVGHICPO5nrXYZQ9rpUqBuYVCLb1DLa1Lju206iprWq2S1eQy/jMLVcmmCg9
OuyOJuhBkAri7hX7oeXop3Xq/lma64qE+lQwqojj6rjzycIRNCuqOEqDUWMA
3+FGDDdP1Cj9uOyk1N2rvHuN7vIXom0EFpVLSlejUHFGiFwQ2geAc8Q7JgqN
lGg95Hx/QDTEmRYoMmdffs2lYhyKSQkdRwZMV0I5JZn9iCUoKZ1ER5Rd7y7b
EgU8eLSpqfi5QDtxMKNkexJ+ERJcVP+qXK6vrWznHC6vGrRRgyLf5iL2R5R4
qklhKHHe7JkrMEnrG3jLF+hap9J8lKLc8a94k/PX7GkJerDihawJKUJ/gddR
SotFcAGkL4ddnFZDkhJkZBTz7YRvy3rZ3HLxcTS3AT5IaThQb4CgsVJ6Gm2X
V0/bPSznwLfCrzF7mJZ/RIZY597Fa3mLYkex6eAS/DeP0HZ/XvcUk6LzxaRu
GAUedKRIUp1AeWf0eMKKUxJlbjQnulBzWNu5iTjCrupO6bzvkoCwbtU+NqWO
3E5LxEkIUTgRTQg3cwct+U8Tl50Bh3N3SC0LXQQc0Hdp+CPOl54XM5CcAsWt
u3HpReoc2ChXaoMttJv20lnYGNIDQKPgsV43dXpA7TzNy4NBwkPS5hGEGad+
BkdipBZzyBh1azIhvPplWWmhF2O1gC8u3Ig9Zab774jPoSK7yDstHpbcAlJz
vwnOkDdxfB/GdEEkbHK++TpBpuDAuyM71Qd1tWnQsxj09/oaVOUbDAFDMsFp
kn5PHruSu6NlivUM67iXSLPGppJCpTFWa1iAR+10zcdRZM6eI9Xctlgyl84k
Tp81PtZRIKH4D1C+KlrTQIEVzShmVsQa31YORdBbztLS2xuSJzYehhVA73Fu
XHLIWymxQbZrXCFBV9z244okGN+0d/53FGD8xylOO6YCTcIvLPdjuyKVuzJP
eIYxFVVNdtzpZXQPpJUg7aiJ/OO6XF3PKjioyqtEkgvMJseRtR2qjP8pgbgG
oVHFT6dMGE3g4UN+LHzkaA5qAZUIQFsYXauu8OtAOlWxwb8rUJygAgKXxSLH
FLc1hxaoHCWxZZ4ON+0qr8UvokVGaq44q8sAxAD5hCyWWxa7SOvlKB+fuvW0
aFfK4wPdUdvGiYjsE3Kc7AN/nPiy6FN//1hUyWMdSBQfdM5gUG499foPWaFV
Xw/PBW6xFuPS8q9AMZqWrXkjJ0iyMgUy6YacrSjwWbGG40UYpjbFm03VcOK+
UunKlU/kswcBFb9Hmccl83KzMXdoUmCHD90sc7UtuUArx5AgPLY9z0BeWkmS
HuTQA4x2UnG6rKS2VjgWSd88iE8oy5cYjkj5VzYguqd0frNaOMd6CUI5X6vE
FyKw1oHDPI60HLvNnPep0osKhiYGRtSCoMpjgvWQjMkEmwrkcd8hRM2OtKWX
ETBNADyKx5hBSv6C5cihoAXXb310N0ZvawvgYMWQkoVHEx8yGpGlscdJRD3d
iwhvOmqpwunPxOfpktZIJug9cM/+JO2aWP/0hZ6Mn5QCHXknpshtDgRnEcTT
3HuuEBpMvMP5pAEJRx9hzC2B5fwqVGKI8FeUQGJq7U33Y5pKFUyAQW9sFuaR
CQUmkIU/bxfXJUqZSCODPh1Io25AAqIcRN/wQ4IO8GItsOh8o/F6rh4ib9UF
pC4xa3HHyf1a9xUIUr1C9bJGAQaJI9fLXLZs2JL2dOwCBDGZcqtjjvXO3N4a
UOUOd5yUAzIqwFXsAP11EA/GZgczrov7JuFHq1UqD8lReaQ8+6Ye3DJDoQP/
VySBBOyGVHJSRvPK4SWd3Zn1Z/pYdMeG7l6PwRqznv8WYfiLpioXu+zLAu3D
p1wwp6Vql0xiuDkYWtZ6V3/LvI7dBtYwx1Jt/SPje4mZZiE3Mc5iLg1JtEPC
HMyXmODUb9N6rmAa4w8Tt0mpPb5N5DgyXTcEjT90g9u4ge0lc+z9E9wv+Ul4
f3rSAGRmKlIgcY5OLo5oeWN9GPeCzHn09m9H2yndPVuWo7UZo2LebEZ85/dZ
17BF7x1AGPYEnqck/RcgG/3008svz3796JNfozGra6otC5oUTavEMbBdrhqK
2MWCDeZaBkU3TE90FwOHxMW49dhGZAMkpF02VbTBQgJwzShyKWwLGZW4p4we
Vmn9WrhnQLnJJVKUlTHfZ+7KRhkcoOhuYDlsVXNO+p2IMUwyI6n1e7KYAVV+
mi+eX7BUd/r9hUixGFh04InfyBkr/R73fg1odRBeQqr4JYjqi3tQPgq0oMpc
1Pp3OijJozE2zapmJ4KmNHlzAQn+XKkEuWZJXbwzSjjCLFBTzkYjVPI6Oiq2
QGg8B5nsNq4u3KVWVl5Gpde2dSUnwW4MFMXD5Zs0GuuCnOpUZHYEGWjb+kwr
CsILk3MfpNN5Exm88acPJm8tL8Hs4VSGMSUZG0NjJp+aj95OXG5zPNMDM/tb
JMWzUyviyPhKO+K065HE6lTVARrfWHnuOVKcsh3kP/8gcPobRtK/ghoG5ufj
6JNf+78/t189/CiuYfC3rONvHEPAY2oSzNKfxIns0ReIgeM/969h4Nd0j4IK
5pEf4g9/8Kf9jqn+8W9v3+cwjwZoM/gxhS8+db9+xr/9av5eV/MehnlgUWKk
sghdQoM1cskf+PcUgYSIja+LPjcSYaaETUU4XFNIPUZHSpMwLwP663H37mLM
HCNhv+QnIvWGf/x0kn0ArHfGHFhFhrKvin8+GOX8PjLMJqsf/DyZ/PRTPNjP
PwuvHbemxlICC01hYKyEv7a+r4dPTLosWDd6OAcZc8Pnf1WwV5QVyXx8bnle
A8/FbJQgN3OtRjFQibhyYd1hYB83Xvd8NCgW50LdTStNjZV3r3zoEkDmWHfi
eZAk6yBF/bclIwQ0163UybxpXmMYdQfvLLcV/qrNILiP9tSFeuV2y5fFyiX2
jMFJCxR8QqHNTqqaRtpVeB+iSm9UE4DWaOt5gQBNDqmhphEY1z6NJ8b17ps8
yJ+9q4LEyKlrg7F363J/n+ISUsWK0MacBpqodloB16X33gGaX913Ptu7y1fN
ShQrTYDCdEnXO5jO4NaR1exiqzfEZ6QeLNufnp3Xv+Y97XtZoCeFwf2DCsug
tImP0O1CFyp+kbdl19i2cRLBiamdSd30c6I1w3Tb4bNEtGJH275djZ/ABAQ/
+6qdQWCBMxwPSqEEQdWxZk6OYzJHXTY3BZmtwzKckcnTqjww602hLRJhwW96
b+6SrSbC6H0fRO0gSahCFd23Nfo/vDdpUbaL7RrNSZjKHsfbxwlulA7hKtPE
4eeBo7cDuAcW1nWJVfLR61tUFeNu3vv4aUrCyHtKwtiTgSeFDdmLhPWA9VEO
GCjU99Pdh5IQ+caqFsOlFeHKVnl/rcVwE8RiLUE11W4OCAd7YKsqo86YDmsd
MnnvU4lQfw69NaGp2nNmVHhLoE//F4v7Kn8OVAEA

-->

</rfc>