Subject: [sacm] [draft-ietf-sacm-information-model] SACM components (except at endpoints) MUST have time sync (#25)

From: Danny Haynes <[email-masked]>
Date: Fri, 14 Aug 2015 08:16:16 -0700

[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?

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/25

---

From: Danny Haynes <[email-masked]>
Date: Fri, 21 Aug 2015 02:56:28 -0700

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/25#issuecomment-133358937

---

From: henkbirkholz <[email-masked]>
Date: Fri, 21 Aug 2015 04:26:45 -0700

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 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).

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/25#issuecomment-133377238

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 21 Aug 2015 12:44:58 +0000

I agree.  I think it's particularly important to differentiate between a status update (observed state at a point in time) and a state change (an attribute, property, or compliance of the endpoint changed from one value to another).  I also like the list of timestamps, though I think they probably need more complete definitions with examples to ensure everyone understands them the same way.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of henkbirkholz
Sent: Friday, August 21, 2015 7:27 AM
To: sacmwg/draft-ietf-sacm-information-model
Subject: Re: [sacm] [draft-ietf-sacm-information-model] SACM components (except at endpoints) MUST have time sync (#25)

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

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/25#issuecomment-133377238> . <https://github.com/notifications/beacon/AKbE0WROXvTtnP9n5pQPtujhmOaKlndfks5opwJ1gaJpZM4FrvO0.gif>