OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.

#!/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...')

There! Entirely explicit, uses RFC 3339 as intended, and there's one
clear way of doing things without resorting to optional fields.

Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
"It is always something." --RFC 1925

Attachment: signature.asc
Description: PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]