Agree 100% on the nanoseconds - if not useful, they should be dropped.
I want to pick up debate here we were having on the Slack channel before it went kapoof. I do not think we should be coming at this from the point of view of "this could be theoretically useful for <x>". This is exactly how STIX got so complicated in the first place.
We should be coming at this from the point of view of
- What is the minimal amount of information to communicate this data point
- OK, now, what additional information *beyond the minimum" is required to fulfil all identified workflows.
Notice I am using the word "workflow", not use case, this is on purpose. All of these decisions should be made from the point of view of an end to end workflow - not only the producer making the data, but also the consumer of the data, and what usefulness it could provide them.
So far the requirement for a precision field has assumed that there is a use case on the recpient side for this data - I challenge this. Lets assume we have a mandatory nanosecond-accurate timestamp. What is the workflow by which I would create a timestamp that would not have nanosecond accuracy, send that to a consumer, and then have the consumer improperly process the information or take invalid action based on that? A use case on Slack was presented by @sbarnum that you could use this for high precision temporal analysis - but I assert that said analysis still does not require a precision field, because in the only use cases where you would be doing that action, the data would always have precision (no one is going to take human-generated incident responses and perform millisecond-level temporal analysis on them, that doesn't make any sense)
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
"Struse, Richard" ---11/23/2015 03:42:45 PM---Are there any generally-available tools or technologies that produce timestamps with nanosecond prec
From: "Struse, Richard" <>
To: "" <>, "Jordan, Bret" <>, Trey Darley <>
Cc: Jason Keirstead/CanEast/IBM@IBMCA, Jerome Athias <>, "" <>, "Wunder, John A." <>, Patrick Maroney <>, "Sean D. Barnum" <>
Date: 11/23/2015 03:42 PM
Subject: RE: [cti-stix] STIX timestamps and ISO 8601:2000
Sent by: <>
Are there any generally-available tools or technologies that produce
timestamps with nanosecond precision today? If we can't identify any I
would suggest that we support 6 digits (microseconds) and be done.
This is a trivial but important way that we can communicate to the broader
community that we are rooted in real-world practice.
-----Original Message-----
From: [mailto:]
On Behalf Of Tony Rutkowski
Sent: Monday, November 23, 2015 2:23 PM
To: Jordan, Bret; Trey Darley
Cc: Jason Keirstead; Jerome Athias; ; Wunder,
John A.; Patrick Maroney; Sean D. Barnum
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
It's not inconceivable that fractional microsecond
values matter in virtualization environments.within
the same facility. On a larger scale, the uncertainties
associated with the timestamp value will make
nanosecond precision moot.
Has anyone articulated what the overhead
differential is of an _expression_ with a precision
of microseconds versus nanoseconds?
-t
On 2015-11-23 01:08 PM, Jordan, Bret wrote:
> I miss typed in my last email, I meant to say micro seconds not
> milliseconds, aka 6 digits of precision not 3 digits of precision.
> Wireshark and other networking / security tools are able to work with
> and provide 6 digits of precision. That is VERY common. What is not
> really common today is 9 digits of precision.
>
