| This is a great example where we really need to have the specification “say what we mean”, not “do what I mean”.
A time range where one expects a timestamp is ambiguous. Looking at this discussion two days later, I see like seven different interpretations of what a time range means when one expects a time stamp. That is begging for interoperability failure.
I think we all agree the limited ISO 8601 specification is the way to specify a timestamp. We agree the limited ISO 8601 specification is the way to specify a time range. However, I would like to be able to say we agree that we will specify what fields must have a timestamp (give me a range and I will fail) and what fields have a time range.
Myself I would like to see a list of objects for which it is presumed ranges would be valid - to me, that would be the minority, not vice-versa.
Like I say - it totally fundamentally changes the way you have to write your software if you have to deal with time windows everywhere vs a discrete time. I think the use cases where time windows are needed should be clearly delineated.
A time window in terms of how software is written is not the same as a timestamp with a confidence factor.
-
Jason Keirstead
STSM, 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>"Barnum, Sean D." ---02/02/2016 02:04:37 PM---I definitely see your point for fields that MUST always be discrete. Maybe default to the general ti
From: "Barnum, Sean D." <sbarnum@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Mark Davidson <mdavidson@soltra.com>, "Wunder, John A." <jwunder@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date: 02/02/2016 02:04 PM
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
Sent by: <cti@lists.oasis-open.org>
I definitely see your point for fields that MUST always be discrete.Maybe default to the general timestamp and for fields that MUST be discrete define a more limited version without ranges?SeanFrom: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, February 2, 2016 at 12:54 PM
To: "Barnum, Sean D." <sbarnum@mitre.org>
Cc: Mark Davidson <mdavidson@soltra.com>, John Wunder <jwunder@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.So what happens if there is a feild where a discrete timestamp is the only thing that makes sense, but the producer puts a range in it, and everyone who consumes it does not process it properly as a result...? That is my main issue with this being a format that can be used in any timestamp field. A piece of software needs to know how they should parse that field... as a range or not a range... because that has very broad ramifications.
-
Jason Keirstead
STSM, 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>"Barnum, Sean D." ---02/02/2016 01:42:46 PM---My understanding is that "2015-03-01T13:00:00Z” would explicitly be a discrete time and "2015-03-01T
From: "Barnum, Sean D." <sbarnum@mitre.org>
To: Mark Davidson <mdavidson@soltra.com>, "Wunder, John A." <jwunder@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date: 02/02/2016 01:42 PM
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
Sent by: <cti@lists.oasis-open.org>
My understanding is that "2015-03-01T13:00:00Z” would explicitly be a discrete time and "2015-03-01T13:00:00Z/” would indicate an unbounded range starting at that time.
The presence of the “/“ makes it explicitly a range.
By my understanding there are really only 4 variations here:- "2015-03-01T13:00:00Z” : discrete time
- "2015-03-01T13:00:00Z/” : unbounded time range starting at "2015-03-01T13:00:00Z”
- “/2015-03-01T13:00:00Z” : unbounded time range ending at "2015-03-01T13:00:00Z”
- "2015-03-01T13:00:00Z/2015-03-01T14:00:00Z” : bounded time range between "2015-03-01T13:00:00Z” and "2015-03-01T14:00:00Z” (this example would be the same as saying "2015-03-01T13:00:00Z” with a precision=“hour”)
This really does not sound complex to me to parse or understand.
I would think quite a few time fields do not necessarily fall as always discrete or always a range. I would say this is likely true of the majority of incident related timestamps.
For example, as part of an incident investigation you discover that a registry key on a system was changed to a particular value. If you had an endpoint monitoring tool in place noticing events like registry key changes you would likely assert a discrete timestamp for when the change occurred. In other (most from what I have seen operationally) cases you don’t have visibility to determine exactly when the change was made but rather you have a point in time slice that shows the new value and a previous point in time slice that shows the old value so you know that the change occurred sometime in between.
From what I have heard from operations, IR and intel folks this sort of thing where a time may be discrete and may be a range is very common.
Pat, please feel free to correct me if my understanding is wrong.
Cell: (609)841-5104
Email: pmaroney@specere.org
---------------------------------------------------------------------
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]
|