OASIS Cyber Threat Intelligence (CTI) TC

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








From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com >
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.








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
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


 

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" .


 


Proposal: 


 


 (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".


 



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

 

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









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, February 2, 2016 at 7:26 AM
To: 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.






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








From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com >
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.








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
+61 (407) 203 206
terry@soltra.com
 

 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


 

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" .


 


Proposal: 


 


 (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".


 



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

 

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










From: < cti@lists.oasis-open.org > on behalf of "Barnum, Sean D." < sbarnum@mitre.org >
Date: Tuesday, February 2, 2016 at 10:49 AM
To: "Wunder, John A." < 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.







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









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, February 2, 2016 at 7:26 AM
To: 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.






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








From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com >
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.








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
+61 (407) 203 206
terry@soltra.com
 

 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


 

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" .


 


Proposal: 


 


 (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".


 



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

 

How many other, widely-used standards allow time ranges as envisioned here.  As I think about trying to write code to consume this it makes my head hurt.  I feel that this is antithetical to our stated goal of making STIX/CybOX simpler, easier to implement and most importantly easier to consume.  Think about what this proposal would do to UIs for example.  Yikes!   Let’s be explicit where we need a time range.  Everywhere else I’d urge we stick with a single time. Please. J   From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Mark Davidson Sent: Tuesday, February 02, 2016 10:53 AM To: Barnum, Sean D.; Wunder, John A.; OASIS CTI TC Discussion List Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.   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     Attachment: smime.p7s Description: S/MIME cryptographic signature

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









From: Mark Davidson < mdavidson@soltra.com >
Date: Tuesday, February 2, 2016 at 10:52 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >, 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.








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










From: < cti@lists.oasis-open.org > on behalf of "Barnum, Sean D." < sbarnum@mitre.org >
Date: Tuesday, February 2, 2016 at 10:49 AM
To: "Wunder, John A." < 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.







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









From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, February 2, 2016 at 7:26 AM
To: 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.






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








From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com >
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.








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
+61 (407) 203 206
terry@soltra.com
 

 


From: cti@lists.oasis-open.org
[ mailto:cti@lists.oasis-open.org ]
On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


 

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" .


 


Proposal: 


 


 (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".


 



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

 

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 "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. sean From: Mark Davidson < mdavidson@soltra.com > Date: Tuesday, February 2, 2016 at 10:52 AM To: "Barnum, Sean D." < sbarnum@mitre.org >, 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. 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 From: < cti@lists.oasis-open.org > on behalf of "Barnum, Sean D." < sbarnum@mitre.org > Date: Tuesday, February 2, 2016 at 10:49 AM To: "Wunder, John A." < 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. 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 From: < cti@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Tuesday, February 2, 2016 at 7:26 AM To: 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. 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 From: < cti@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Date: Tuesday, February 2, 2016 at 5:39 AM To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct. 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 +61 (407) 203 206 terry@soltra.com From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ] On Behalf Of Patrick Maroney Sent: Tuesday, 2 February 2016 3:36 PM To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct. 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" . Proposal: (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". Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.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?


Sean









From: < 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


"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.

sean

From: Mark Davidson < mdavidson@soltra.com >
Date: Tuesday, February 2, 2016 at 10:52 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >, 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.

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

From: < cti@lists.oasis-open.org > on behalf
of "Barnum, Sean D." < sbarnum@mitre.org >
Date: Tuesday, February 2, 2016 at 10:49 AM
To: "Wunder, John A." < 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.

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

From: < cti@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Tuesday, February 2, 2016 at 7:26 AM
To: 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.

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

From: < cti@lists.oasis-open.org > on behalf
of Terry MacDonald < terry@soltra.com >
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney < Pmaroney@Specere.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

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
+61 (407) 203 206 terry@soltra.com


From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List < cti@lists.oasis-open.org >
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

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" .

Proposal:

(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".

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

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 "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? Sean From: < 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 "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]

Range capability totally makes sense to me. I just really don’t think that there should be fields where you can EITHER put a range or an atomic value. That kind of optionality is a recipe for incompatibilities.


If there are fields that we think need to be ranges, let’s just make them always ranges, and if people want to put a discrete value the start/stop are the same (range of 0ms). We can evaluate this on a case-by-case basis as we come to those fields, IMO
there’s no reason to go through and do it all now.


John








From: < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, February 2, 2016 at 1:08 PM
To: Sean Barnum < sbarnum@mitre.org >
Cc: Mark Davidson < mdavidson@soltra.com >, "Wunder, John A." < 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.





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


"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?

Sean

From: < 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


"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]

Can we schedule an hour call for later today or tomorrow to talk through this?  The one thing I like about this, is that we could get rid of precision field.   Pat, Please prepare a list of fields where a range would make sense.  Thanks, Bret Bret Jordan CISSP Director 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.   On Feb 2, 2016, at 11:08, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: 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? Sean From: < 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] Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

 

 


From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Tuesday, February 02, 2016 1:20 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Patrick Maroney <Pmaroney@Specere.org>
Cc: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


 
Can we schedule an hour call for later today or tomorrow to talk through this?  The one thing I like about this, is that we could get rid of precision field.  

 


 

 


Pat,


 


Please prepare a list of fields where a range would make sense. 


 


 










 


Thanks,


 


Bret



 


 


 



Bret Jordan CISSP

Director 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." 









 



On Feb 2, 2016, at 11:08, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:

 



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?

Sean

From: < 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]




 

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. On Feb 2, 2016, at 1:08 PM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: 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? Sean From:   < 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]   Attachment: smime.p7s Description: S/MIME cryptographic signature