SACM components (except at endpoints) MUST have time sync

[djhaynes]

[From our discussion on 8/14/15 on the Endpoint Identity team call]
I postulate that, within the SACM components domain, reliable and
trustworthy time synchronization is necessary:

(a) To support authentication, replay-defense, etc. in SACM transport
bindings of SACM data models;

(b) To timestamp collected SACM attributes and their metadata; and

(c) To correlate an event stream (timestamped) with SACM attribute
values at a given point in time, in order to make policy and/or
remediation decisions.

I propose that the following two conformance requirements be defined
in the information model and be normative for all SACM data models
and all SACM transport bindings of those data models:

(1) SACM endpoint collectors SHOULD implement time sync and
add correct timestamps to all collected SACM attributes.

(2) SACM components, except endpoints, MUST implement time sync
and add correct timestamps to all collected SACM attributes.

Comments?

[djhaynes]

To further expand on the proposal, I propose that a set of SACM-relevant timestamps should be defined. For example:

1. the time an "event" happened (based, for example, on an audit log entry)
2. the time an event record was discovered or collected by the sensing application
3. the time an event or data element was received by the manager/aggregator (regardless of which tier)

If we can define the timestamps that are of interest, then we can determine which "should" or "must" have rigidly synchronized timestamps applied. I suggest that if all the timestamps end up being "should", then timestamp synchronization is unenforceable.

[henkbirkholz]

Proposed text regarding Timestamps probably depends on text regarding the topics Data Source, Data Origin, Data Provenance, Attributes/Events & Time Synchronization.

There is a strong tie between Data Source & Data Origin (and therefore Data Provenance) and the different types of Timestamps here. Also - as Ira pointed out on the list - time synchronization and coping with the lack of it is important in this context (An internal SACM component residing on the Data Source/Target Endpoint might have to deal with an async or even no local source of time).

The timestamps discussed in the EIDT were about:

• creation
• observation/collection
• publish*
• relay* (think ZebraNet)
• storage

*those are from scenarios with high delay or significant retention time in a collector (or intermediate proxy) due potential loss of connectivity. Sometimes the distribution of information simply takes some time.

Also, there should be a clear differentiation between Events and Attributes. In the context of SACM, they are similar. Basically, an Event is a point in time the value of an (endpoint) Attribute changes (or the availability of an Attribute changes, as Adam pointed out). While there has been consensus about this definition, the current drafts focus primarily on attributes (their observation and association via container/relationships) and not events(treams).

[henkbirkholz]

Is limiting the scope of these text passages to collection necessary? How does this sound?

(1) SACM components residing on target endpoints SHOULD implement time sync and
add correct timestamps.

(2) SACM components that do not reside on target endpoints MUST implement time sync
and add correct timestamps.