Re: [cti-stix] STIX timestamps and ISO 8601:2000

["Wunder, John A." <jwunder@mitre.org>]

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.

John

> On Nov 24, 2015, at 5:28 AM, Trey Darley <trey@soltra.com> 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 we
>> do it should be explicit rather than implicit.
>> 
> 
> ...I also agree with John. On the one hand, I can't count the number
> of times I've seen investigations get thrown under the bus due to
> clock-sync issues. On the other hand, recent history has shown that
> historical assumptions made about datetime can come back to bite us
> with a vengeance.
> 
> So I think we should just use the standard explicitly. The producer
> can use the level of precision they support and intend to communicate,
> the consumer can easily recognize the level of precision coming from
> the producer, and handle it appropriately. Doing this in the manner
> illustrated below imposes less burden on the consumer than handling an
> optional 'precision' field while accomplishing the same goal.
> 
> <snip>
> #!/usr/bin/env python
> 
> import re
> 
> nanoseconds  = '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...')
> </snip
> 
> There! Entirely explicit, uses RFC 3339 as intended, and there's one
> clear way of doing things without resorting to optional fields.
> 
> -- 
> Cheers,
> Trey
> --
> Trey Darley
> Senior Security Engineer
> 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
> Soltra | An FS-ISAC & DTCC Company
> www.soltra.com
> --
> "It is always something." --RFC 1925