So I think we are finally getting somewhere..... Before we claim that we agree, let me paraphrase and summarize just to make sure:
1) A timestamp format of yyyy-mm-dd-Thh:mm:ssZ MUST be used
Examples:
2015-11-23T13:35:12Z (for 1:35:12 in UTC format)2) All timestamps MUST be in UTC a UI will change them as needed for an analyst
3) A timezone offset will NOT be used, all times will be recorded in UTC4) Timestamps can have any level of sub-second precision that they support and a simple regex should be used in code to determine the precision
Examples:
nanoseconds = '2015-11-24T09:42:54.003259294Z' microseconds = '2015-11-24T09:42:54.003259Z' milliseconds = '2015-11-24T09:42:54.003Z'
etc.5) There will be no extra precision field
Open questions
A) If the time of day is not known should it be:
i) zeroed out
Examples:
'2015-11-24T11:00:00Z' (known only to the 11th hour)
'2015-11-24T00:00:00Z (known only to the day)
ii) not included, just like the sub-second (if we do this, is this a violation of RFC3339)
Examples:
'2015-11-24T11Z' (known only to the 11th hour)
'2015-11-24TZ (known only to the day)
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 24, 2015, at 06:24, Wunder, John A. <> wrote:
I have a slight preference for Trey’s approach but would also be fine with Terry’s.I prefer Trey’s because IMO support for a standard as-is is better than redefining the standard. RFC3339 allows for accuracy to any arbitrary (second) value and therefore the vast majority of date/time libraries will be able to support that. His approach allows us to use the standard as-is. In fact, the requirement for millisecond precision may make things more difficult for those who just want to use RFC3339 processing libraries because they have to get those libraries to produce *our* version of RFC 3339 rather than anything compatible with the standard.I don’t think it will allow accuracy to the day unless we move back to ISO 8601 with all the other openness that it brings. But, I tend to agree with Terry that it will matter very little in almost every circumstance so we shouldn’t worry about it.JohnOn Nov 24, 2015, at 5:28 AM, Trey Darley <> wrote:On 24.11.2015 02:36:50, Terry MacDonald wrote: I think that we have to put this whole discussion in perspective. Most organizations have difficulty in discovering they have a breach within days and weeks, not within a second. So going with B) iii) and having the precision within 1 second realistically is good enough in my opinion. It is far more likely that all the clocks on the network are not synchronized, and all the tools are reporting different and unrelated times and that they are way more than a second out of alignment with each other. The zeroed out millisecond timestamp doesn’t impact us much when we have real-world problems such as that.I agree with Terry however...On 23.11.2015 20:51:09, Wunder, John A. wrote:This is not to say that we need a precision field, just that if wedo it should be explicit rather than implicit....I also agree with John. On the one hand, I can't count the numberof times I've seen investigations get thrown under the bus due toclock-sync issues. On the other hand, recent history has shown thathistorical assumptions made about datetime can come back to bite uswith a vengeance.So I think we should just use the standard explicitly. The producercan use the level of precision they support and intend to communicate,the consumer can easily recognize the level of precision coming fromthe producer, and handle it appropriately. Doing this in the mannerillustrated below imposes less burden on the consumer than handling anoptional 'precision' field while accomplishing the same goal.<snip>#!/usr/bin/env pythonimport renanoseconds = '2015-11-24T09:42:54.003259294Z'microseconds = '2015-11-24T09:42:54.003259Z'milliseconds = '2015-11-24T09:42:54.003Z'seconds = '2015-11-24T09:42:54Z'minutes = '2015-11-24T09:42Z'# You get the idea...timestamps = [nanoseconds, microseconds, milliseconds, seconds, minutes]nano_re = re.compile(r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{9}Z')micro_re = re.compile(r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{6}Z')milli_re = re.compile(r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z')sec_re = re.compile(r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z')min_re = re.compile(r'\d{4}-\d{2}-\d{2}T\d{2}:\d{2}Z')for ts in timestamps: if nano_re.match(ts): print('Found nanosecond time...') elif micro_re.match(ts): print('Found microsecond time...') elif milli_re.match(ts): print('Found millisecond time...') elif sec_re.match(ts): print('Found second time...') elif min_re.match(ts): print('Found minute time...')</snipThere! Entirely explicit, uses RFC 3339 as intended, and there's oneclear way of doing things without resorting to optional fields.-- Cheers,Trey--Trey DarleySenior Security Engineer4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430Soltra | An FS-ISAC & DTCC Companywww.soltra.com--"It is always something." --RFC 1925
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
