Subject: [sacm] SACM Timestamp Accuracy Principle

From: "Haynes, Dan" <[email-masked]>
Date: Fri, 25 Sep 2015 12:09:39 +0000

Just catching up on an Endpoint ID Design Team action item to add a GitHub issue and send a message to the list regarding what we are calling the "timestamp accuracy principle".

During the 09-04-2015 Endpoint ID Design Team meeting, there was discussion around the fact an enterprise will have different sensors.  Some will detect changes as soon as they occur whereas others will detect them during a periodic scan.  Furthermore, others will be detected on the endpoint and others will be observed off of the endpoint.

The main point is that depending on how sensors operate will depend on how accurate the timestamp associated with the change will be.  For example, if a sensor is only running once every 12 hours, the change probably happened at some point in time prior the scan. Furthermore, it is then up to the administrator to determine if that accuracy is good enough for their purposes. Similarly, you don't know that an endpoint has a vulnerability until someone discovers that the vulnerability actually exists (e.g. a vulnerability researcher is able to exploit it).

With this in mind, the design team was in agreement that we need to state this fact (and others we find) as a key principle of SACM in the Information Model before we discuss the constructs in the Information Model and how they are perceived.  This information can be captured in the newly added "Operational Considerations" section of the information model.

Does adding text around this topic, to the "Operational Considerations" section, make sense?  Are there other key points that we should capture?

Thanks,

Danny

[1] Corresponds to GitHub IM Issue #28 (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/28).

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 25 Sep 2015 09:42:38 -0400

There's also the accuracy of the time stamp itself, which has two 
considerations:

* The time sensitivity of the particular observation.  A DHCP lease, for 
example, can easily be on the order of days, so millisecond time 
accuracy is not necessary to have a high confidence in correlating an 
observed IP address against an entry in a DHCP server log.

* The relative error bounds.  That is, the amount of possible error 
bound between the different observers that are being correlated. If, for 
example, the time sources for a network observer and a DHCP server are 
both far off the correct time but are synced to the same inaccurate time 
server, then the correlation of their data will have a high reliability.

--gun

On 9/25/2015 8:09 AM, Haynes, Dan wrote:
>
> Just catching up on an Endpoint ID Design Team action item to add a 
> GitHub issue and send a message to the list regarding what we are 
> calling the “timestamp accuracy principle”.
>
> During the 09-04-2015 Endpoint ID Design Team meeting, there was 
> discussion around the fact an enterprise will have different sensors. 
>  Some will detect changes as soon as they occur whereas others will 
> detect them during a periodic scan.  Furthermore, others will be 
> detected on the endpoint and others will be observed off of the endpoint.
>
> The main point is that depending on how sensors operate will depend on 
> how accurate the timestamp associated with the change will be.  For 
> example, if a sensor is only running once every 12 hours, the change 
> probably happened at some point in time prior the scan. Furthermore, 
> it is then up to the administrator to determine if that accuracy is 
> good enough for their purposes. Similarly, you don’t know that an 
> endpoint has a vulnerability until someone discovers that the 
> vulnerability actually exists (e.g. a vulnerability researcher is able 
> to exploit it).
>
> With this in mind, the design team was in agreement that we need to 
> state this fact (and others we find) as a key principle of SACM in the 
> Information Model before we discuss the constructs in the Information 
> Model and how they are perceived.  This information can be captured in 
> the newly added “Operational Considerations” section of the 
> information model.
>
> Does adding text around this topic, to the “Operational 
> Considerations” section, make sense?  Are there other key points that 
> we should capture?
>
> Thanks,
>
> Danny
>
> [1] Corresponds to GitHub IM Issue #28 
> (https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/28).
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 25 Sep 2015 19:30:12 +0000

It's probably worth noting that most SACM use cases don't require very specific accuracy.  Many use cases are fine with time period granularity measured in seconds, minutes, or even hours.

It may also be worth discussing how the source of data governs the accuracy of the timestamp.  Timestamp accuracy will be different if information is obtained from log files, or monitored in real time through a running daemon or service, this is in contrast to tools that do periodic local or over-the-network discovery scans and determine what changes have occurred by conducting diffs against a previous scan result.  If an over-the-network scanner is discovering changes by doing analysis of differences between scans, then the scan interval governs the accuracy of change detection, which may range into months.  At that point, it's only meaningful to discuss when the change was discovered and not so much when it occurred.

Different SACM use cases will lend themselves to different temporal granularities.

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 Gunnar Engelbach
Sent: Friday, September 25, 2015 9:43 AM
To: Haynes, Dan; [email-masked]
Subject: Re: [sacm] SACM Timestamp Accuracy Principle

There's also the accuracy of the time stamp itself, which has two considerations:

* The time sensitivity of the particular observation.  A DHCP lease, for example, can easily be on the order of days, so millisecond time accuracy is not necessary to have a high confidence in correlating an observed IP address against an entry in a DHCP server log.

* The relative error bounds.  That is, the amount of possible error bound between the different observers that are being correlated.  If, for example, the time sources for a network observer and a DHCP server are both far off the correct time but are synced to the same inaccurate time server, then the correlation of their data will have a high reliability.

--gun

On 9/25/2015 8:09 AM, Haynes, Dan wrote:
Just catching up on an Endpoint ID Design Team action item to add a GitHub issue and send a message to the list regarding what we are calling the ?timestamp accuracy principle?.

The main point is that depending on how sensors operate will depend on how accurate the timestamp associated with the change will be.  For example, if a sensor is only running once every 12 hours, the change probably happened at some point in time prior the scan. Furthermore, it is then up to the administrator to determine if that accuracy is good enough for their purposes. Similarly, you don?t know that an endpoint has a vulnerability until someone discovers that the vulnerability actually exists (e.g. a vulnerability researcher is able to exploit it).

With this in mind, the design team was in agreement that we need to state this fact (and others we find) as a key principle of SACM in the Information Model before we discuss the constructs in the Information Model and how they are perceived.  This information can be captured in the newly added ?Operational Considerations? section of the information model.

Does adding text around this topic, to the ?Operational Considerations? section, make sense?  Are there other key points that we should capture?

Thanks,

Danny

[1] Corresponds to GitHub IM Issue #28 (<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28).

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

---

From: Ira McDonald <[email-masked]>
Date: Fri, 25 Sep 2015 15:43:05 -0400

Hi,

My two cents.

Part of this discussion leads inevitably to one of the "hard" questions, to
wit,
"What is your time source?"

Endpoint data provenance without valid timestamps is vaporware.

This is pretty much a burning question in quite a few IETF WGs and other
SDOs at present, because such things as certificate revocation and session
resumption windows depend quite critically on "everyone understands time
similarly."  But "everyone" in any field of interest almost never does.

Doing automotive OTA firmware updates based on GPS time (don't laugh)
is flaky design that is all too common.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Sep 25, 2015 at 3:30 PM, Wolfkiel, Joseph L CIV DISA ID (US) <
[email-masked]> wrote:

> It's probably worth noting that most SACM use cases don't require very
> specific accuracy.  Many use cases are fine with time period granularity
> measured in seconds, minutes, or even hours.
>
> It may also be worth discussing how the source of data governs the
> accuracy of the timestamp.  Timestamp accuracy will be different if
> information is obtained from log files, or monitored in real time through a
> running daemon or service, this is in contrast to tools that do periodic
> local or over-the-network discovery scans and determine what changes have
> occurred by conducting diffs against a previous scan result.  If an
> over-the-network scanner is discovering changes by doing analysis of
> differences between scans, then the scan interval governs the accuracy of
> change detection, which may range into months.  At that point, it's only
> meaningful to discuss when the change was discovered and not so much when
> it occurred.
>
> example, can easily be on the order of days, so millisecond time accuracy
> is not necessary to have a high confidence in correlating an observed IP
> address against an entry in a DHCP server log.
>
> * The relative error bounds.  That is, the amount of possible error bound
> between the different observers that are being correlated.  If, for
> example, the time sources for a network observer and a DHCP server are both
> far off the correct time but are synced to the same inaccurate time server,
> then the correlation of their data will have a high reliability.
>
>
> --gun
>
>
> Just catching up on an Endpoint ID Design Team action item to add a GitHub
> issue and send a message to the list regarding what we are calling the
> ?timestamp accuracy principle?.
>
> discussion around the fact an enterprise will have different sensors.  Some
> will detect changes as soon as they occur whereas others will detect them
> during a periodic scan.  Furthermore, others will be detected on the
> endpoint and others will be observed off of the endpoint.
>
> The main point is that depending on how sensors operate will depend on how
> accurate the timestamp associated with the change will be.  For example, if
> a sensor is only running once every 12 hours, the change probably happened
> at some point in time prior the scan. Furthermore, it is then up to the
> administrator to determine if that accuracy is good enough for their
> purposes. Similarly, you don?t know that an endpoint has a vulnerability
> until someone discovers that the vulnerability actually exists (e.g. a
> vulnerability researcher is able to exploit it).
>
> With this in mind, the design team was in agreement that we need to state
> this fact (and others we find) as a key principle of SACM in the
> Information Model before we discuss the constructs in the Information Model
> and how they are perceived.  This information can be captured in the newly
> added ?Operational Considerations? section of the information model.
>
> Does adding text around this topic, to the ?Operational Considerations?
> section, make sense?  Are there other key points that we should capture?
>
> Thanks,
>
> Danny
>
> (<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28).
>
>
>
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 25 Sep 2015 16:46:17 -0400

There is some historical work done in the past about trusted
timestamping such as RFCs 3161, 3628, etc. but I am not sure if any of
it is relevant.

On Fri, Sep 25, 2015 at 3:43 PM, Ira McDonald <[email-masked]> wrote:
> On Fri, Sep 25, 2015 at 3:30 PM, Wolfkiel, Joseph L CIV DISA ID (US)
> <[email-masked]> wrote:
>>
>> meaningful to discuss when the change was discovered and not so much when it
>> occurred.
>>
>> example, can easily be on the order of days, so millisecond time accuracy is
>> not necessary to have a high confidence in correlating an observed IP
>> between the different observers that are being correlated.  If, for example,
>> the time sources for a network observer and a DHCP server are both far off
>> the correct time but are synced to the same inaccurate time server, then the
>> correlation of their data will have a high reliability.
>>
>>
>> --gun
>>
>>
>> this fact (and others we find) as a key principle of SACM in the Information
>> Model before we discuss the constructs in the Information Model and how they
>> are perceived.  This information can be captured in the newly added
>> ?Operational Considerations? section of the information model.
>>

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 25 Sep 2015 21:13:17 +0000

Mr Misell,

I agree that seems important.  I'm having trouble envisioning how hard or easy it would be to implement that data collection.  I've never tried to discover where any given endpoint is getting its time from, whether it was set once when it was deployed, then allowed to drift over time (unless a local user resets it), whether it comes from an NTP server, or whether it's coming from another source.  In the case of an NTP server, you would have to know how the NTP server was getting its time, whether from GPS, an atomic clock, or some other thing.

I'm also struggling to figure out how knowing this information would figure into the business logic I would run on the data the repository receives or what I would show to my users in the displays.  I'm hoping you can contribute your knowledge to flesh those concepts out.

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

-----Original Message-----
From: David Misell [mailto:[email-masked]] 
Sent: Friday, September 25, 2015 4:44 PM
To: Wolfkiel, Joseph L CIV DISA ID (US)
Cc: Adam Montville
Subject: Re: [sacm] SACM Timestamp Accuracy Principle

This email was sent from a non-Department of Defense email account, and contained active links. All links are disabled, and require you to copy and paste the address to a Web browser. Please verify the identity of the sender, and confirm authenticity of all links contained within the message.  

Wolfkiel,

I used to work in a national regulated carrier. Time is highly regulated in the Telco space, it would not be unreasonable to define these CNI end points as SACM endpoints also with their own characteristics. We should also reference the codes defining which type of time source was used, potentially with suitable keys

Kind Regards,

Dave

David S. Misell MBCS CISSP
Skype misell.dave
+44(0)7710380044
0207 7239135
Http://linkedin.com/in/misell
Caution-db.tt/ncfgMm3J

On 25 Sep 2015, at 20:30, Wolfkiel, Joseph L CIV DISA ID (US) <[email-masked]<mailto:[email-masked]>> wrote:

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

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, September 25, 2015 9:43 AM
To: Haynes, Dan; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] SACM Timestamp Accuracy Principle

--gun

Thanks,

Danny

[1] Corresponds to GitHub IM Issue #28 (<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>>Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>).

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

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 25 Sep 2015 17:20:44 -0400

It's not necessary for us to solve the problems for how to obtain that 
data about the provenance/reliability of the timestamps, just that we 
have the facility to include it.

I hope that looking at the RFCs that Yakov referenced will be good 
enough to give us an idea for what data needs to be communicated and 
leave it at that.

Given the open-ended n-tuple model that has been discussed, it's not 
even necessary to know right now exactly what data needs to be 
communicated, but we should at least determine at what level it needs to 
be tagged.  Just once for a group of data, for example, as a tag 
associated with every data item, or maybe allow timestamps at a grouping 
level so that multiple items with different time provenances can be 
grouped together without having to individually tag each data item.

--gun

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 25 Sep 2015 18:43:47 -0400

Sent from my iPhone

> On Sep 25, 2015, at 5:20 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> It's not necessary for us to solve the problems for how to obtain that data about the provenance/reliability of the timestamps, just that we have the facility to include it.
> 
+1

Kathleen 
> I hope that looking at the RFCs that Yakov referenced will be good enough to give us an idea for what data needs to be communicated and leave it at that.
> 
> Given the open-ended n-tuple model that has been discussed, it's not even necessary to know right now exactly what data needs to be communicated, but we should at least determine at what level it needs to be tagged.  Just once for a group of data, for example, as a tag associated with every data item, or maybe allow timestamps at a grouping level so that multiple items with different time provenances can be grouped together without having to individually tag each data item.
> 
> 
> --gun
> 
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 28 Sep 2015 17:04:16 -0400

It occurs to me that there's another way to address this, which is to 
make time correlation a part of the protocol.

For each SACM participant that communicates directly with another SACM 
participant, an exchange of the current time can also occur. That gives 
the participants an opportunity to record any time differences, which 
can be used to create a time corrected relative to the local system, and 
which can also be included in any communications passed on to other 
participants.

It was suggested a long while back that each communication would include 
a timestamp:  that would be sufficient as long it is guaranteed that 
that timestamp is the last piece of data added to the document prior to 
transmission (otherwise there's no way to account for how long it took 
to create the document).

Granted there's a limit to how accurate this would be and there are 
cases where it doesn't help (for example, a node that acts as a broker 
for multiple SNMP-only devices would report its own time and not 
necessarily be able to report a corrected time for any of those devices).

But the question is, is that level of accuracy good enough for SACM 
purposes?

--gun

On 9/25/2015 6:43 PM, Kathleen Moriarty wrote:
>
>
> Sent from my iPhone
>
> On Sep 25, 2015, at 5:20 PM, Gunnar Engelbach 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>> It's not necessary for us to solve the problems for how to obtain 
>> that data about the provenance/reliability of the timestamps, just 
>> that we have the facility to include it.
>>
> +1
>
> Kathleen
>> communicated, but we should at least determine at what level it needs 
>> to be tagged.  Just once for a group of data, for example, as a tag 
>> associated with every data item, or maybe allow timestamps at a 
>> grouping level so that multiple items with different time provenances 
>> can be grouped together without having to individually tag each data 
>> item.
>>
>>
>> --gun
>>
>>
>>> To: Haynes, Dan;[email-masked]<mailto:[email-masked]>
>>> [1] Corresponds to GitHub IM Issue #28 (<Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28 <http://Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28><Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28 <http://Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>>>Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28 <http://Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28><Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28 <http://Caution-github.com/sacmwg/draft-ietf-sacm-information-model/issues/28>>).
>>>
>>>
>>>
>>>
>>> <http://Caution-www.ietf.org/mailman/listinfo/sacm><Caution-www.ietf.org/mailman/listinfo/sacm 
>>> <http://Caution-www.ietf.org/mailman/listinfo/sacm>>
>>>
>>>
>>>
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Sep 2015 21:49:35 -0700

I am having a problem with what is needed here because I am seeing a number of different things that time can be recorded for and I am not sure that the accuracy requirements are the same for all of them.

1.  I observed this statement at a given time:  This may not be possible for all devices as not all devices that report are going to have a clock yet along an accurate clock.  Even if they have a clock it may not be synchronized with the system.

2. I reported these statements at a given time:  This is needed for inferring synchronization and would be generated as part of the protocol to send the data to the consumer.  This may not be done for all provider-consumer interactions.  

3.  I received these statements at a given time:  This should always be computable, but it may not need to be computed for all provider-consumer interactions.    This is needed to deal with endpoints that might either not have a clock or have a clock out of skew.

I care about the accuracy of statements 2 and 3, I am not sure that have a strong requirement for 1 to be globally synchronized.  The difference between 1 and 3 can provide some correction about the time on observations would be.

Jim

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 29 Sep 2015 06:40:05 -0400

The property you are describing is, within
the time community, known as low *uncertainty*.
There is a reasonably good slide deck on all
the variables and terms and how they fit
together on the OMG site from some years ago
at
http://www.omg.org/news/meetings/workshops/DOCsec-2002_Proceedings/03-1_Humenn-Lewandowski_Assured_Trusted_Time_Stamping.pdf

NIST's basic handbook on the subject provides
similar information in a more generic setting.
http://tf.nist.gov/general/pdf/1498.pdf

A time stamp that does not have the needed
uncertainty can be a significant potential vulnerability
in some systems.

--tony

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 29 Sep 2015 12:06:32 -0400

There may well be cases where an absolute time value is needed, so we 
should include the ability to record that along with information to 
communicate the quality or level of uncertainty of that time value.  I 
don't have a good feel for what data fields will be sufficient to 
communicate that -- time source at a minimum, but I don't want to hazard 
a guess at what the other data items would be. This can also be helpful 
information if the time source is inconsistent.

But as far as SACM goes, I think relative time is the most important.  
That is, what the difference in reported time is between SACM 
participants.  Knowing this allows the SACM component to correct the 
time stamps relative to its own clock, giving a higher reliability when 
correlating data between multiple nodes.

By making this time correction a part of the SACM protocol, time 
correction can be determined for each SACM component that data transits, 
so it will always be reliable relative to the current component (within 
some degree of error bounds).

As a final step, any SACM component that produces a product (printed 
report, archiving data, etc) can make a final correction relative to a 
known time server

more inline...

> 1.  I observed this statement at a given time:  This may not be possible for all devices as not all devices that report are going to have a clock yet along an accurate clock.  Even if they have a c…

Exactly.  But this is two different problems:

1)  Devices that do not have access to a time source.  Time will still 
be recorded via each SACM component it passes through.  The cases where 
this is most likely to happen is something like a SACM gateway to SCADA 
equipment, where the SACM component is acting as a gateway to be able to 
query devices that are not capable of implementing a SACM agent.  So, 
while the actual source will not be able to timestamp the data, the SACM 
component acting as the gateway can, and that should be authoritative.

2)  Devices with inaccurate/unsynchronized clocks.  A non-issue, because 
the SACM component communicating with these devices will be able to 
compare times and determine the delta, therefore providing a way to 
correct the time from the device relative to all other SACM components.

What this can't address is pulling archived data, such as from a log, 
where the log does not contain any time information or there is 
insufficient data to calculate the time difference.  I expect this to be 
very rare, but still it's necessary to be able to flag such data.  In 
that case, there's no point in trying to time-correct the data.

> 2. I reported these statements at a given time:  This is needed for inferring synchronization and would be generated as part of the protocol to send the data to the consumer.  This may not be done…

If it's part of the protocol it should be possible to be computed for 
all provider-consumer interactions.  If that consumer later becomes a 
provider to some other consumer, it will then have the information 
necessary for time to be locally corrected at the next consumer.

> 3.  I received these statements at a given time:  This should always be computable, but it may not need to be computed for all provider-consumer interactions.    This is needed to deal with endpoin…

For the purpose of forensics, time and time accuracy is very important, 
especially if forensics are being done pursuant to legal action.

But yeah, for cases currently covered by our existing use cases, time 
accuracy isn't that big a deal.  Most of the time this is information 
that will be ignored.  Still, we need to also persist the information 
necessary to compute a corrected time value whenever possible.

In any case, part of the communication should be determining the time 
difference.  In that way, even if the source does not have an accurate 
clock, the values it is reporting can still be corrected relative to the 
local clock, as will the data from any other source, so data can be 
correlated with a relative degree of reliability.