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

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Sean - all I am concerned with is the format of the timestamp and the precision of said timestamp.

I am of the firm belief that we do not need to support a producer *or* an observer the capability to declare their precision, and having this in STIX is an example of needless complexity that has no practical use.

If there is a codified use case for nanosecond accuracy*, then just make the mandatory timestamp format include nanoseconds, and everyone who does not have milliseconds or nanoseconds will set all zeros.

* I would like to see this declared though - what is the actual (not theoretical) use case for nanosecond accuracy of an observation or a production?

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Barnum, Sean D." ---11/20/2015 03:03:14 PM---Jason, I think that part of the confusion here may be due to conflating two different kinds of times

From: "Barnum, Sean D." <sbarnum@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, Patrick Maroney <Pmaroney@Specere.org>
Cc: Jerome Athias <athiasjerome@gmail.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Date: 11/20/2015 03:03 PM
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
Sent by: <cti-stix@lists.oasis-open.org>

---

Jason,

I think that part of the confusion here may be due to conflating two different kinds of timestamps: production timestamps and occurrence/observation/assertion timestamps.

I am characterizing production timestamps here as timestamps associated with STIX content when it is created (I.e. the timestamp that goes along with ID to identify a specific version of content). I would agree with you that any system producing STIX content should likely have the capacity and the unambiguous clarity of when it is producing the content to assert a timestamp with millisecond precision.

I am characterizing occurrence/observation/assertion timestamps as time assertions when something is believed to have occurred, when some sort of observation was made or when some relationship or fact was asserted. These sorts of timestamps cannot be presumed to come from the same sorts of systems or unambiguous clarity as production timestamps. These sorts of things can come from all sorts of sensors or systems or people where such precision is simply not consistently possible. Also, it can be complicated by things like initial uncertainty (as Jerome pointed out) or by what level of precision given parties are willing to share. All of these are the sorts of realities in real-world threat intel that the community expressed which led to the inclusion of the precision field. 

Does that help at all?

sean

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, November 20, 2015 at 12:31 PM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: Jerome Athias <athiasjerome@gmail.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000

RE @Jerome - Even for an incident - what is the use case where I am reporting an incident but do not have millisecond resolution? What am I reporting the incident based on?

RE @Patrick - Same feedback for all below. All of the sources of those patterns would have, at minimum, millisecond resolution. In some cases they would even be nanosecond - in which case, conveying the mandatory milliseconds would not be a problem? Why do I have to convey a precision, it is implicit in the timestamp itself.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Patrick Maroney ---11/20/2015 12:09:45 PM---Use cases for precision: Conveying network or system event patterns.

From: Patrick Maroney <Pmaroney@Specere.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, Jerome Athias <athiasjerome@gmail.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Date: 11/20/2015 12:09 PM
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
Sent by: <cti-stix@lists.oasis-open.org>

---

Use cases for precision: 

Conveying network or system event patterns.

Network: 

Fingerprinting attack toolkits, attacker attribution, side-chain analysis for covert channel detection, attacker location determination, human vs. machine attack pattern assessment and determination.

System: 

Suggest that this community speak up for themselves, but conveying the results of Malware analysis and attack pattern characterization are two obvious examples. An excellent paper demonstrating CPU Cache manipulation for the creation of covert channels across virtualization compartments serves as an example.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org




On Fri, Nov 20, 2015 at 7:55 AM -0800, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:

I myself don't really see much a use case for precision. What is the use case? Why do I care about the precision of the producer, if it is second resolution or millisecond resolution?

Furthermore - do people actually envision a producer that does not have the capability to produce millisecond resolution? What would that be...? Someone with a watch?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Jerome Athias ---11/20/2015 11:27:48 AM---attached just a screenshot from my tool to illustrate the concern 2015-11-20 17:06 GMT+03:00 Wunder,

From: Jerome Athias <athiasjerome@gmail.com>
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 11/20/2015 11:27 AM
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
Sent by: <cti-stix@lists.oasis-open.org>

---

attached just a screenshot from my tool to illustrate the concern

2015-11-20 17:06 GMT+03:00 Wunder, John A. <jwunder@mitre.org>:
> 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.
>
> John
>
> On Nov 20, 2015, at 8:57 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM>
> wrote:
>
> 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.com
>
> Without 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.org
> Date: 11/19/2015 11:48 PM
> Subject: [cti-stix] Fwd: STIX timestamps and ISO 8601:2000
> Sent 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
>
>
>
>
>
[attachment "STIXBuilder_Precision.png" deleted by Jason Keirstead/CanEast/IBM] 
---------------------------------------------------------------------
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

---------------------------------------------------------------------
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 
[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]