OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [Non-DoD Source] Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct. (UNCLASSIFIED)


+1 (two distinct objects)

I don't get in on these conversations much as I am still trying to catch up.  But I do know for a fact that today at a DoD meeting with the Cyberspace Community of Interest we were discussing reports having time ranges.  I believe this is a requirement for a large organization that is and intends to keep using STIX (now CTI)...

James Bohling
Cyberspace Interoperability
Joint Staff J6, DD C5I
Data and Services Division

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Tuesday, February 02, 2016 7:55 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>
Cc: Patrick Maroney <Pmaroney@Specere.org>; OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: [Non-DoD Source] Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 


The "every timestamp field can be a range" part is new to me. 

I don't see how we can make that a TLO field blanket interchangeable. There will be some object types where a single fixed timestamp is all that would be valid. And there will be other object types where a time range would be all that would be valid.

I would rather keep timestamp and time range as two distinct ideas. I don't see a benefit in jamming them into one object.

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

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

"Jordan, Bret" ---02/02/2016 01:20:32 AM---I have thought a lot about this, since Pat first brought it up and I believe he has a solid case for

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date: 02/02/2016 01:20 AM
Subject: Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
Sent by: <cti@lists.oasis-open.org>


I have thought a lot about this, since Pat first brought it up and I believe he has a solid case for this. I do think that this might be a bit weird in the UI treatments if every timestamp allows a range. But that is an implementation issue. I have questions of how this differs from precision. And if we do this, can we not just drop the extra precision field? That could make processing so much easier. 

Before we accept this, I would love to see some normative text written and added to the pre-draft specs. I would like to see some examples of how precision would effect this and the normative text that would surround it (or can we just drop the precision field). 

Can we also get a line or two of text that talks about what to do if your tool can only support one timestamp? I am guessing you would take the first one? 



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 1, 2016, at 21:35, Patrick Maroney <Pmaroney@Specere.org < Caution-mailto:Pmaroney@specere.org > > wrote:
		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 < tel: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
		Integrated Networking Technologies, Inc.
		Desk: (856)983-0001 < tel:(856)983-0001 > 
		Cell: (609)841-5104 < tel:(609)841-5104 > 
		Email: pmaroney@specere.org < Caution-mailto:pmaroney@specere.org > 

[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]