Subject: [sacm] Requirements Removed from the SACM Use Cases Draft

From: "Waltermire, David A." <[email-masked]>
Date: Sun, 18 Aug 2013 22:48:03 +0000

Nancy,

The following are requirements from the Use Cases document that I removed. They should be added to your requirements document draft instead. I left the XML tags in place to make them easier to drop in your draft.

>From the section titled "data collection":

          <t>One or more data formats MUST be identified to describe instructions, data collection
            methods, to drive data collection (e.g. technical, interrogative).</t>
          <t>One or more data formats MUST be identified to instruct what posture attributes need to
            be collected for a specific set of endpoints. <list>
              <t>A method MUST be provided to include OPTIONAL instructions on describing what
                content must be run on the endpoint.</t>
              <t>A method MUST be provided to include OPTIONAL instructions that determine how to
                collect data supporting any particular test for that endpoint.</t>
            </list>
          </t>
          <t>A method MUST be provided for retrieving data collection instructions from a remote
            host (see Section <xref target="sec-capability-content-management"/>).</t>
          <t>One or more data formats MUST be identified to capture the results of data collection. <list>
              <t>This expression MUST be capable of supporting the characterization of assets and
                any related configuration settings that together compose an endpoint. <list>
                  <t>A mechanism MUST be provided to identify the software and hardware asset
                    instances that compose an endpoint. <list>
                      <t>An asset identifier SHOULD be able to be determined in an automated
                        manner</t>
                      <t>An asset identifier, as communicated between entities, SHOULD be held to a
                        minimal size.</t>
                      <t>An asset identifier SHOULD be able to represented in a simple unambiguous
                        manner, such as a reference, so that its embedded use in places like
                        applicability clauses for individual benchmark tests can be kept from making
                        their usage unwieldy.</t>
                    </list>
                  </t>
                  <t>A mechanism MUST be provided to associate configuration settings values to the
                    installed software.</t>
                  <t>A mechanism MUST be provided to identify additional collected posture
                    attribute/value pairs related to an endpoint.</t>
                </list>
              </t>
              <t>A mechanism MUST be provided to identify the endpoint the results pertain to (see
                Section <xref target="sec-capability-asset-management"/>.</t>
              <t>A mechanism MUST be provided to associate the data collection method with the
                collected value.</t>
              <t>A mechanism MUST be provided to include provenance information describing what
                sensor of software collected the data.</t>
              <t>A mechanism MUST be provided to include entailment information, perhaps by
                reference, describing the methodology used to collect the data.</t>
            </list>
          </t>
          <t>A method of communicating data collection results to another system for further
            analysis MUST be identified.</t>
          <t>TODO: Communicate, unambiguously and to the necessary level of detail**, the asset
            details between software components</t>

>From the section titled "Assessment Result Analysis":

          <!-- TODO: Use of an applicability concept, against a collection of assets to determine what policies (test expressions) are suitable for collection and evaluation. -->
          <t>A method MUST be provided for selecting acceptable state policy, describing how to
            evaluate collected information, based on characteristics of the endpoint and
            organizational policy.</t>
          <t>A method MUST be provided for comparing collected data to expected state values (test
            evaluation).</t>
          <t>Any results produced by analysis processes MUST be capable of being transformed into a
            human-readable format.</t>

>From the section titled "Content Management":

          <t>A protocol MUST be identified for retrieving SACM content from a content repository</t>
          <t>A protocol MUST be identified for querying SACM content held in a content repository.
            The protocol MUST support querying content by applicability to asset characteristics. <list>
              <t>TODO: Determine what content can or must be run on the endpoint</t>
            </list>
          </t>
          <t>A protocol MUST be identified for curating SACM content in a content repository. Note:
            This might be an area where we can limit the scope of work relative to the initial SACM
            charter.</t>