| Maybe we have two types of fields....
1) Discrete fields, such as the timestamp for things like, I created this Indicator at X. These fields would NOT have a precision field.
2) Fields where the time might be open to discussion. This would enable us to get rid of the precision field, which in my mind is harder to process than a range where I can easily do time.Time math.
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."
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.
sean
Under the proposed structure, how would a consumer differentiate between a timestamp (e.g., “this report was produced at XYZ”) vs. a time range with an unbounded end (e.g., “this indicator is valid from now until eternity”)? If I understand the proposal correctly, there would be no way for a consumer to decide whether "2015-03-01T13:00:00Z” is a timestamp or a time range.
Personally, I think we should be explicit about which fields are timestamps and which fields are time ranges (at least in the spec).
Which fields don’t fall cleanly into either category?
Thank you. -Mark
I would agree in principle though I believe there are some time fields that may not fall cleanly into one camp or the other (sometimes they are discrete and sometimes a range). Personally I like Pat’s proposal below. Using the range would potentially allow us to remove the precision field as well as really it is just asserting a range by specifying a floor and scope.
sean
IMO Pat’s proposal is a good approach to represent ranges, I would just want to clearly define which fields are ranges and which are atomic times. I think it will be very hard on consumers if they might get either for any given field.
John
I would prefer this to be a separate TimeRange object if at all possible. If there are places we require a timerange, then lets create something that works there. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company We are reaching final consensus on our CTI TimeStamp deliberations. This is a proposal to add a simple ISO 8601 Standard extension to the CTI TC TimeStamp specification that enables _expression_ of both "Absolute Time" and "Time Range" . (1) Adopt the ISO 8601 <start>/<end> construct. (2) All of the constraints we are placing on the CTI Timestamp format remain intact:* "Absolute Time": "2015-03-01T13:00:00Z" "Time Range": "2015-03-01T13:00:00Z/2016-05-11T15:30:00Z" (3) Parsing of the ISO 8601 <start>/<end> construct should be straightforward (i.e., using standard date-time libraries that support ISO 8601, regex). *Note : This proposal only argues for the narrow adoption of the "/" Separator and would not allow any of the other ISO 8601 "Time Range "shortcuts" (e.g., "2014-2015", "2015-11-13/15", "2015-02-15/03-14"). There is significant benefit for use cases where there is a very real need to express events, actions, observables, COAs, etc. in time ranges. For example- statutory incident/intrusion reporting deadline requirements (measured increasingly for many in hours/days) guarantee a need express and revise events in time ranges while investigations gather evidence and more accurately establish the sequence of events and timelines. There are also many relationships that are more effectively expressed in time ranges, vs. fixed points in time. Hopefully you see the value in adding this ISO 8601 capability to "our thing".
|