| The users (incident responders, threat analysts, etc) as you call out, use tools, they do not use the model directly. And I would argue that vendors that produce tools for incident responders and threat analysts know those communities really well and get feed back from them all the time. Further, if vendors do not build tools that the users like, then they go out of business.
So if the standard says all of the times are kept in UTC, then it falls on the vendors that produce tools for these groups to make sure it works in ways that those groups want and need.
The reason we look at this from a standard, is to make sure we can guarantee interoperability.
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."
Makes sense to me. My only caution would be that I am pretty sure this suggestion was one that came up back during the community discussion on timestamps that led to the addition of the precision attribute and suggested practice of specifying timezones. It was ruled out at that time but I don’t recall the community reasoning that led to that decision. If we are going to revisit this, we will need to make sure that we have the appropriate voices (incident response, threat analysts, etc.) involved in the conversation. They are the ones with a clear understanding of the diverse “real-world” timestamp issues for threat intel.
I would suggest adding this as an issue in the tracker.
sean
Regarding timezone, I’ve always thought that we should be mandating all times should be UTC at the STIX/CybOX level. It should be up to the UI tools to display that UTC time in whatever timezone the viewer is in. We always made our logging tools record in UTC timezone, as it meant that we could capture data from around the world and it would make sense. Always having UTC makes it trivial when pulling together dates from many and varied places across the world. Rather than forcing specification of timezone, I would just like to mandate that the timezone will always be UTC, and that the tools that use STIX will do the translation when they present it to the user. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company One of the changes we made in STIX 1.1 was the addition of a “precision” attribute next to all timestamps (except for @timestamp, which was intended to always be precise to the second or millisecond). The intent was to allow producers to convey times that were precise to a millisecond/second (possible in ISO 8601), day, month, and year (not possible in ISO 8601). The use case was incident and report timestamps where implying millisecond or even second precision was not accurate…the incident was reported on a given day and so the full timestamp would need to fake the time portion of the day. To be honest I’m not sure that that use case is important enough to introduce the concept of precision, but we did explicitly add it in 1.1 so it’s something we should at least consider as an alternative to always requiring millisecond precision even in cases where’s it’s essentially faked. The other thing STIX added on top of that is that timezone is “strongly suggested” (it’s optional in 8601). I’d be in favor of making it required unless any implementors have objections. The problem is the "subset" potion. ISO 8601 actually does not specify how to represent milliseconds. So some people don't include it, some do, sometimes they also throw in nanoseconds... I think we should extend ISO 8601 in the spec to include milliseconds and make it mandatory, so that it is well known exactly what the time format will be. Millisecond resolution will be required for many pieces of software operating with STIX. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security | www.securityintelligence.comWithout data, all you are is just another person with an opinion - Unknown <graycol.gif> Jerome Athias ---11/19/2015 11:48:25 PM---Back to the future ---------- Forwarded message ----------From: Jerome Athias <athiasjerome@gmail.com>To: cti-stix@lists.oasis-open.orgDate: 11/19/2015 11:48 PMSubject: [cti-stix] Fwd: STIX timestamps and ISO 8601:2000Sent by: <cti-stix@lists.oasis-open.org>
Back to the future
---------- Forwarded message ----------
From: Jerome Athias <athiasjerome@gmail.com>
Date: 2014-02-10 10:10 GMT+03:00
Subject: Re: STIX Content Revision and Revocation
To: "Wunder, John A." <jwunder@mitre.org>
Cc : Terry MacDonald <terry.macdonald@gmail.com>, Patrick Maroney
<Pmaroney@specere.org>, "Grobauer, Bernd"
<Bernd.Grobauer@siemens.com>, "Taylor, Marlon"
<Marlon.Taylor@hq.dhs.gov>, DisplayName <patrick.maroney@mac.com>,
"Barnum, Sean D." <sbarnum@mitre.org>, Kyle Maxwell
<krmaxwell@gmail.com>, Dave Dittrich <dittrich@u.washington.edu>,
stix-discussion-list Structured Threat Information _expression_/ST
<stix-discussion-list@lists.mitre.org>
I would see xs:datetime as "an implementation of strings formatted
according to a subset of ISO 8601:2000, documented in RFC 3339."
http://www.w3.org/TR/xmlschema-2/#isoformats
http://tools.ietf.org/html/rfc3339
so no "differences"
2014-02-10 Wunder, John A. <jwunder@mitre.org>:
> Hey guys,
>
>
>
> I have a quick question about RFC3339 vs. XML Schema's dateTime. I looked
> into them briefly and as far as I can tell they are very similar...some small
> differences in what each allows (capital T to denote time vs. either capital
> or lowercase, things like that). Are there important differences that make
> RFC3339 better than xs:dateTime that I'm missing? The nice thing about
> xs:dateTime is that, as long as STIX is in XML it natively validates, vs.
> RFC3339 which we would have to validate (and wouldn't work as well in
> programmatic bindings).
>
>
>
> Note: I'm basing this off of this mailing list post regarding Atom, so it's
> very possible I just don't understand the differences:
> http://www.imc.org/atom-syntax/mail-archive/msg13103.html.
>
>
>
> Thanks,
>
> John
>
>
>
> From: Terry MacDonald [mailto:terry.macdonald@gmail.com]
> Sent: Sunday, February 09, 2014 8:20 PM
> To: Patrick Maroney
> Cc: Grobauer, Bernd; Taylor, Marlon; DisplayName; Barnum, Sean D.; Wunder,
> John A.; Kyle Maxwell; Dave Dittrich; stix-discussion-list Structured Threat
> Information _expression_/ST
> Subject: Re: STIX Content Revision and Revocation
>
>
>
> [+1] again on the RFC3339 (In UTC with 6 digits of precision) for me too
> please.
>
>
>
> Cheers
>
>
>
> Terry MacDonald
>
>
> Terry MacDonald
>
>
>
> On 10 February 2014 14:02, Patrick Maroney <Pmaroney@specere.org> wrote:
>
> [+1] For a universal (optional) timestamp attribute( (RFC3339 in UTC with
> at last 6 digits of precision for 'time-secfrac'). Understand we will need
> to defer on other related attributes (like potential CRUD/change modality)
> to give it the attention this needs However, this change would help lay
> the foundations for a unified temporal reference (or at least the ability to
> assert same ;-).
>
>
>
> Patrick Maroney
> Executive Director
> Defense Security Information Exchange (DSIE)
> Office: (856)983-0001
> Cell: (609)841-5104
> pmaroney@specere.org
>
> ________________________________
>
> From: owner-stix-discussion-list@lists.mitre.org
> <owner-stix-discussion-list@lists.mitre.org> on behalf of Grobauer, Bernd
> <Bernd.Grobauer@siemens.com>
> Sent: Sunday, February 09, 2014 2:48:01 PM
> To: Taylor, Marlon; DisplayName; Barnum, Sean D.
>
>
> Cc: Wunder, John A.; Terry MacDonald; Kyle Maxwell; Dave Dittrich;
> stix-discussion-list Structured Threat Information _expression_/ST
>
> Subject: RE: STIX Content Revision and Revocation
>
>
>
> Hi,
>
>
>
> I pretty much agree with Marlon's answers to the open questions put by Sean.
> Looking at
>
> draft 2 of version 1.1 of Stix, I would like to add my vote to Marlon's
> answer to question
>
> 10 "Should an additional @timestamp attribute be added to each contstruct.".
> Marlon
>
> prefers the attribute, and so do I: timestamp information is such essential
> information,
>
> that it should be on top-level right next to the identifier rather than
> somewhere below
>
> in the (optional!!) "Information_Source/Time/Produced_Time" element.
>
>
>
> Also: I think on must be able to add timestamp information to really every
> object
>
> that has an identifier: I am not sure that every object I want to timestamp
> has the 'Information_Source'-substructure:
>
> making '@timestamp' an attribute next to any place where an '@id' attribute
> occurs makes sure
>
> that any object can be timestamped.
>
>
>
> So, in short: although this comes rather late in the timeline of STIX 1.1: I
> really think
>
> that draft 2 should be changed with regards to the location of where the
> timestamp information
>
> is kept: make '@timestamp' a sibling of '@id', '@id_ref' and
> '@timestamp_ref' rather
>
> than keeping the timestamp in "Information_Source/Time/Produced_Time".
>
>
>
> Kind regards,
>
>
>
> Bernd
>
>
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|