Subject: [sacm] Information model of a SACM component

From: "Kahn, Clifford" <[email-masked]>
Date: Sun, 9 Nov 2014 17:18:58 +0000

All,
In draft-ietf-sacm-information-model-00, section, 4.4, SACM Component, says:

   Although SACM components are mainly covered by the SACM architecture,
   we have some remarks.  TODO: Move them?

The remarks do seem misplaced. I'd like to move them to an appendix for now, and then to another home, probably the architecture. OK?

Moving the remarks would leave the section empty. But that's wrong; we do need to model information about SACM components. What information?

Here is a suggested list of things model about a SACM component. 

- Software component of the SACM component
- Software instance of the SACM component -- this is the actual SACM component. I suppose SACM Component is a subclass of Software Instance. 
- Endpoint on which the SACM component runs
- Who administers the component - whether I trust it depends on whether it's an experimental lab component
- Information about the capabilities of the component.**
- Information about soundness.* If the component makes a particular assertion, can the assertion be taken as true? Or are there false positives?  
    - We might want more than a Boolean here. We might want information about the rate of false positives, or even the conditions that bring about false positives. 
- Information about completeness.* If the component *doesn't* make a particular assertion, can the assertion be taken as false?

Some of the above things -- software component, for example -- should be modeled as relationships. Some will be modeled as attributes of the SACM component object.

* Thanks to Kim Watson for pointing out these issues. The language is not hers, and I don't say it fully captures her points. 
   In mathematical logic, soundness means that you cannot prove anything that's wrong.  Completeness means that you can prove anything that's right. I am adapting those uses.  

** For an Endpoint Attribute Collector, we need a description of the Endpoint Attribute Assertions it is capable of producing. Again, thanks to Kim Watson for pointing out the need for this. The need is to let another SACM component to determine whether all parts of the enterprise are adequately monitored, or to find any gaps in coverage. ISSUE: Do we have a use case for that? Do we want to embrace this use case? 

I wonder whether the description of a collector's capabilities can be just like a matching criterion, as outlined in my message "Information Model of Guidance: a Sketch", from Mon 11/3/2014 2:44 PM. It would be a simple description of the set of all Endpoint Attribute Assertions that this component could potentially produce. However, I don't know whether that notation captures the nuances we need. 

To be accurate, the description will have to take several things into account: 
    - The capabilities of the software component
    - Where the collector is deployed. An internal collector on endpoint X can produce Endpoint Attribute Assertions only about X. A network-based collector will have visibility only into parts of the network.
    - Configuration settings of the collector (including vendor-specific settings)
  
I suggest that we *not* specify how the description gets populated. We can leave that to implementers. We just need a sufficient notation to meet the use case (if we're tackling the use case).

What are others' thoughts?

Best,
			Cliff

Clifford Kahn
Principal Engineer/Technical Lead

---

From: "Watson, Kimberly" <[email-masked]>
Date: Mon, 10 Nov 2014 14:09:55 +0000

Thanks Cliff, you did a pretty good job of capturing the thoughts.

Some examples of how I have run into these issues and why I feel it is important to consider them in the development of the information model...

Different collectors report the following conditions differently: did not try to collect, failed to collect, collected and passed, collected and failed. Clearly these are 4 very different posture assertions, but an evaluator that consumes collection from these different sources cannot tell the difference and must make assumptions as appropriate for the organization.

Some collectors can report on a condition for a large set of endpoints, but its accuracy is not as good as a different collector that may only be collecting over a subset of endpoints. An example is that I might want to use my automated patch management system as the "primary" source of determining what patches are installed on all my windows devices. An endpoint-based software inventory agent may state that a set of patches are not applied/installed on an endpoint. I want the endpoint agent to be an "authoritative" source - basically, it always trumps the patch management system if it says a patch is/is not installed.  This is my operational language - primary sources minimize false negatives and authoritative sources minimize false positives. I think Cliffs language of soundness and completeness capture the ideas and are probably more appropriate for describing components in an information model.

There are times that a collector has the capability to collect endpoint posture information, but it is currently not tasked to do so. it would be really valuable to know what collectors can collect what attributes for what endpoints...then when you need a piece of information you can find the best collector and task it...right now, we usually only know that a collector can collect what it currently reports.

--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534

-----Original Message-----
From: Kahn, Clifford [mailto:[email-masked]] 
Sent: Sunday, November 09, 2014 12:19 PM
To: [email-masked]
Subject: [sacm] Information model of a SACM component

All,

  

Best,
			Cliff

Clifford Kahn

---

From: "Adam W. Montville" <[email-masked]>
Date: Mon, 10 Nov 2014 09:11:16 -0600

> On Nov 10, 2014, at 8:09 AM, Watson, Kimberly <[email-masked]> wrote:
> 

Should the concepts of soundness and completeness be included in requirements?

> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm