| I would offer the important precision is not not hours, minutes, or seconds, but number of seconds. We also need to define whether the timestamp represents the middle of the range or the bottom.
For example, if I only transmit the hour portion of the timestamp of an event, then 12:00:00Z means anything from 12:00:00.000000000 to 12:59:59.999999999. However, if I transmit the closest hour portion of the timestamp of an event, then 12:00:00Z means anything from 11:30:00.000000000 to 12:29:59.9999999999.
Note that a typical data collection window is tenths of minutes. That is six seconds, not ‘seconds.’ I.e. 12:00:00Z means either 12:00:00Z - 12:00:05.999999999 or 11:59:57Z - 12:00:02.999999999.
My suggestion is (1) the timestamp represents the bottom of the range of the bucket and (2) the number is that for precision of less than a second (i.e., granularity of more than a second) is a bucket of seconds starting from the timestamp value with a precision number of seconds. So, examples would be:
12:00:00Z = event happened between 12:00:00Z - 12:00:00.9999999999Z [default precision = 1s] 12:00:00Z (precision = 60s) = event happened between 12:00:00Z - 12:00:59Z [formerly known as “minute precision”] 12:00:00Z (precision = 3600s) = event happened between 12:00:00Z - 12:59:59Z [formerly known as “hour precision”] 12:00:00Z (precision = 6s) = event happened between 12:00:00Z - 12:00:05.999999999Z [how else would you specify “tenth of a minute”?]
The use case as I understand it at a high level is so that when someone submits a timestamp of 12:00:00 zulu, we know the difference between if they truely mean exactly 12:00:00 on the button, or if they only have second level precision available to them. And this is required because we aren't mandating a fixed format, but RFC 3339 which is variable.
Eric Burger --- Re: [cti] Timestamp Serialization Question --- I’m still clueless as to the use case.
Not a negative statement, but I would like to see the concise reason we need ‘precision’ before I weigh in, if at all.
There tends to be two options for dealing with objects that have multiple timestamps and their corresponding precision. Sean and I have been talking through the pros and cons of these. We would like to get everyone's opinion. Which do you prefer, option 1 or option 2
Option 1: This option put the burden on the JSON serialization format to add an extra "_precision" field to each timestamp enabled field. This is a much flatter and easier to parse and process representation, but the con is it requires unique field names. {
"type": "incident",
"initial_compromise_time" : "2015-12-07T22:00:00Z",
"initial_compromise_time_precision": "hour",
"first_data_exfiltrated_time" : "2015-12-09T05:11:00Z",
"first_data_exfiltrated_time_precision" : "minute",
"incident_opened_time" : "2016-01-15T11:19:22Z",
"incident_closed_time" : "2016-01-19T17:24:017Z"
}
Option 2: This option will require a nested object and struct to store this data and will have an extra layer of indirection for all of those times when the timestamp is at the default precision. {
"type": "incident",
"initial_compromise_time" : {
"timestamp": "2015-12-07T22:00:00Z",
"timestamp_precision": "hour"
},
"first_data_exfiltrated_time" : {
"timestamp": "2015-12-09T05:11:00Z",
"timestamp_precision" : "minute"
},
"incident_opened_time" : {
"timestamp": "2016-01-15T11:19:22Z"
},
"incident_closed_time" : {
"timestamp": "2016-01-19T17:24:017Z"
}
}
Thanks,
Bret Bret Jordan CISSPDirector 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."
|