I have been going back and forth on the usefulness of the precision field. Perhaps we could easily get by in a workflow condition to NOT have a precision field as Jason states.
Things I think we can agree on so far:
1) A timestamp format of yyyy-mm-dd-Thh:mm:ss.mmmmmm+-hh:ss MUST be used
Examples: 2015-11-23T13:35:12.000000+00:00 (for 1:35:12 in UTC format)
2) All timestamps MUST be in UTC format a UI will change them as needed for an analyst
3) Timestamps will have 6 digits of precision
4) Any values that are not known will be zeroed out, say I only know the date not the time
Example: 2015:11:23T00:00:00.000000+00:00
Open Question(s):
A) Is it valid to put in a timezone offset from UTC? Or must the value be actually "in" UTC.
Example 2015-11-23T13:35:12.000000-06:00
B) Do we actually need to manually say what the precision is? Meaning do we need to call out that it is a "year", "month", "day", "hour", "minute", or "second".
i) Sean believes we need this
ii) Jason does not believe we need this. I think I am starting to lean towards Jason on this.
Lets focus on what we can agree on (the stone in the path) and focus our discussions on the remaining open questions. This will enable us to drive this seemingly easy win to consensus.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Nov 23, 2015, at 13:02, Jason Keirstead <> wrote:
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 KeirsteadProduct Architect, Security Intelligence, IBM Security Systemswww.ibm.com/security | www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown <graycol.gif>"Struse, Richard" ---11/23/2015 03:42:45 PM---Are there any generally-available tools or technologies that produce timestamps with nanosecond precFrom: "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 PMSubject: RE: [cti-stix] STIX timestamps and ISO 8601:2000Sent by: <>
Are there any generally-available tools or technologies that producetimestamps with nanosecond precision today? If we can't identify any Iwould suggest that we support 6 digits (microseconds) and be done. This is a trivial but important way that we can communicate to the broadercommunity that we are rooted in real-world practice.-----Original Message-----From: [mailto:]On Behalf Of Tony RutkowskiSent: Monday, November 23, 2015 2:23 PMTo: Jordan, Bret; Trey DarleyCc: Jason Keirstead; Jerome Athias; ; Wunder,John A.; Patrick Maroney; Sean D. BarnumSubject: Re: [cti-stix] STIX timestamps and ISO 8601:2000It's not inconceivable that fractional microsecondvalues matter in virtualization environments.withinthe same facility. On a larger scale, the uncertaintiesassociated with the timestamp value will makenanosecond precision moot.Has anyone articulated what the overheaddifferential is of an _expression_ with a precisionof microseconds versus nanoseconds?-tOn 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.>
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
