Subject: Re: [sacm] SACM UC1 And Related Requirements

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 14 Jan 2013 10:04:18 -0500

This is a good starting list of requirements.  To update the charter, we need to turn these requirements into work items.  Before we do that, I'd like to check a few assumptions and I also have a few questions.  Questions/comments inline below marked [DAW].  I'd appreciate any feedback.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, December 11, 2012 1:39 PM
To: [email-masked]
Subject: [sacm] SACM UC1 And Related Requirements

All:

After trolling through some of the SACM mailing list, and reviewing SACM BoF minutes from IETF 85 and the current Use Case draft looking for requirements, and here's what I've pulled together so far:

 *   UC1 must provide coverage for enterprises of various sizes and include support for assets delivered by third-parties
 *   Asset representation/identification should support those delivered by a given Service Provider (SP)
 *   Supporting data formats and/or protocols should support assessment of SP-provided assets
[DAW: I believe based on previous discussions, that we are planning to treat SPs as large enterprise that have a need to manage assets supported by their infrastructure. The bullets above map to Critical Controls (CCs) 1 and 2: inventory of authorized/un-authorized devices and inventory of authorized/unauthorized software.  To do this assets will need to be identified and some portion of the state of these assets (e.g. software inventory, configuration controls) will need to be collected/published.]

 *   Must provide a method of defining a target system (asset identification; asset classification)
[DAW: I am trying to understand the specific requirement(s) here.  To create an asset baseline (CC 1), it will be necessary to have a standardized mechanism to identify the assets that are part of the baseline.  It will also be necessary to identify the digital policies (acceptable states) that apply to one or more targets.  I am assuming the latter is what is being discussed here: a mechanism to define applicability of policy to a target asset.]

 *   Must provide a method of selecting acceptable state policy (test expression)
[DAW: I am interpreting this as comparing the set of digital policies (acceptable state), using an applicability concept, against a collection of assets to determine what policies (test expressions) are suitable for collection and evaluation.]

 *   Must provide a method of retrieving data collection instructions (activity class: configuration, patch, vulnerability, inventory; object representation; state representation)
[DAW: I am interpreting this as a method to acquire the digital content (test expression) that is needed to perform data collection.  This could be a request to a content repository.]

 *   Must provide a method of expressing state collection values (collection language: technical, interrogative; object representation)
[DAW: I am interpreting this as a method to represent the results of collection.  This is essentially a tuple of collected attribute, value, and possibly the method (test expression) used to collect it.  What is missing is a method to publish or make available this information to a data repository (asset database, CMDB, etc.) for further analysis.  Is this a requirement?]

 *   Must provide a method of comparing actual to expected state values (test evaluation; test expression)
[DAW: This is the process of evaluating the collected values against the appropriate acceptable state.]

 *   Must provide a protocol for connecting to a content repository containing SACM content
[DAW: This seems like a generalized restatement of, or at least a refinement defining the need for a network protocol that supports the earlier requirement related to retrieving data collection instructions.]

 *   Must provide a protocol for querying SACM content held in a content repository
[DAW: This would support the earlier requirement related to selecting acceptable state policy.  It would enable querying content based on applicable attributes to determine what digital policies (test expressions; test evaluation) apply to a given asset.]

 *   Must provide a protocol of retrieving SACM content from a content repository
[DAW: This seems like a generalized restatement of the earlier requirement related to retrieving data collection instructions and test evaluation content.]

 *   Must provide a protocol for curating SACM content in a content repository
[DAW: There has been some discussion around focusing on the read side of this problem first before getting into writes/modifications.  This might be an area where we can limit the scope of work relative to the charter.  In this scenario, we would standardize read access to content (query and retrieval) while leaving publication and updates proprietary for the time being.]
In addition to the above, I would like to suggest that we take certain requirements from CSIS 20 Critical Security Controls [1] under the following controls:

 *   Critical Control 1: Inventory of Authorized and Unauthorized Devices
 *   Critical Control 2: Inventory of Authorized and Unauthorized Software
 *   Critical Control 3: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
 *   Critical Control 4: Continuous Vulnerability Assessment and Remediation
 *   Critical Control 5: Malware Defenses
 *   Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

I have not yet parsed through each of the Critical Controls, but anticipate more detailed requirements to come out of them.  I emphasize that we will not be seeking to meet every requirement expressed by a given Critical Control.  For example, we may not be in a position to express "authorizations" for software installed on an operating system in a given context.  But, Critical Control 2 does require accurate and meaningful asset identification (as does Critical Control 1, for that matter), which is something with which we should be concerned.

I have this Friday (12/14) dedicated to fleshing out these requirements.  If you have contributions to make, I respectfully request that you do so before then.

Regards,

Adam

[1] http://www.sans.org/critical-security-controls/