Subject: [sacm] SW inventory M&A review

From: Chris Inacio <[email-masked]>
Date: Tue, 15 Nov 2016 01:43:47 +0000

I haven’t made it through the whole document. I’ve skimmed it beyond my detail reading, but here is my feedback:

Shared Storage with Executable

The SW-PV will delegate which SW-PC(s) will be responsible for reporting software inventory changes updates on shared storage systems with software installed which will be inventoried. SW-PC SHOULD be able to determine if certain file system components are network shared and if so determined MUST default to not reporting changes on such shares unless otherwise directed by the SW-PV.

Baselines (for virtual dynamic provisioning)

A SW-PC system may inform the SW-PV of a baseline configuration in which all sub-ordinate SW-PC’s conform for their initial state. An SW-PC so configured will then be responsible for transmitting event notices to the local inventory repository to the SW-PV. When a new endpoint enters supervision of a SW-PV, it may be so configured to send a baseline identifier instead of a complete inventory.

This is designed to allow standard desktop enterprise configuration deployment in a more efficient manner, but more importantly in environments with virtual desktop deployment, an ability for virtual desktops to express their configuration without the burden of always sending complete inventories.

________________________________

NIT page 10:

As such, it needs to allow a security tools to make decisions based on up-to-date information about an endpoint’s software inventory without creating an excessive burden on the enterprise’s network.

“a security tools”

NIT page 11:

goal for this specification is ensuring that all SW PCs and PVs, regardless of the vendor who created them, are able to interoperate in their performance of these duties.

I think it should be SW-PCs and SW-PVs

NIT page 11:

support real-time understanding of the state of endpoint in a network

“of an endpoint”?

page 11:

In such a scenario, it is necessary that any PC be able to report any changes to its software inventory evidence collection in

change “PC” to “endpoint”

page 12:

Are “Non-Assumptions” facts?

page 18:

Why “MUST” a SW-PV support targeted requests?

page 19:

"For changes to the endpoint’s Software Inventory Evidence Collection that occur while the SW-PC is not operational, upon becoming operational the SW-PC needs to make a best guess as to the time of the relevant events (possibly by looking at timestamps on files), but these values might be off.”

This seems very problematic to me. Can’t we just record metadata about (1) when the SW-PC starts being active & (2) it’s observation time of the change.

page 21: "All SW-PVs MUST be capable of requesting and receiving change event attributes.”

Why “MUST” a SW-PV support requesting change events?

page 22:

“The SW-PC MUST ensure there is no coverage gap (i.e., change events that are not recorded in the SW-PC’s records) in its change event records.”

add “within an EID Epoch” to the end of that sentence.

--
Chris Inacio
[email-masked]<mailto:[email-masked]>