Re: [cti-stix] Timestamps - Proposal (UTC)

[Eric Burger <Eric.Burger@georgetown.edu>]

OK, bad Eric coming back from a hiatus. Wish I caught up five days ago. Anyway, here goes:

Not using UTC was based on this single comment:

On Nov 24, 2015, at 6:04 PM, Foley, Alexander - GIS <alexander.foley@bankofamerica.com> wrote:
> We have years of experience with this at $dayjob, where many logs that might eventually be parsed into STIX start from times represented in local time zones.  In our experience, “defaulting” to UTC leads to all sorts of people / process / technology side effects, such as when a parser assumes UTC inputs and the person utilizing the parser does not know or realize to write the logic to convert local time into UTC.

I strongly, strongly, strongly disagree, with one caveat. If the goal is to come up with a standard that /mostly/ works in the United States, China, or India. Notice the ‘or’ and not ‘and.’ Worse, having times in local time zone is sort of OK and will work most of the time, except for when it does not, like 2005 in the US.

If the goal is to work with a standard that works everywhere in the world and is immune to local, flavor of the day definitions of “local time,” the *ONLY* option is UTC. The world cannot agree to a single repository to lookup what local time is. The Internet community has put one up on a volunteer basis, but it explicitly states that it is not normative, may be wrong, and will almost certainly be out of date. [1]

I would offer two observations on the single objection to UTC. The first is if someone is /modifying/ their system to /generate/ STIX, then they will know they need to convert local time to UTC. Done. Not a problem. The second is if someone is /writing/ a parser to bring log files /into/ STIX, then they will know they will need to convert whatever time format the log is into UTC. Done. Not a problem.

If you have a multi-time zone enterprise (most of us do), then you are *already* dealing with either doing everything in UTC and converting at the client for display or converting local time into UTC for storage.



[1] https://www.iana.org/time-zones

> On Dec 4, 2015, at 5:27 AM, Trey Darley <trey@soltra.com> wrote:
> 
> On 01.12.2015 20:57:07, Paul Patrick wrote:
>> I’m on-board with this
>> 
>> 
> 
> 100% support this. Thanks for driving the discussion to consensus,
> Bret!
> 
> -- 
> 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 possible to aglutenate multiple separate problems into a
> single complex interdependent solution. In most cases this is a bad
> idea." --RFC 1925

Attachment: smime.p7s
Description: S/MIME cryptographic signature