RE: [cti] Patterning Feedback -Timescales/Periodicity

["Back, Greg" <gback@mitre.org>]

From my understanding, what Eric is talking about (based on Pat's suggestion), is limited to the "WITHIN x <time unit>" Qualifier on pattern expressions, not the timestamp precision fields. The former currently allows multiple ways of expressing the same thing (WITHIN 5 MINUTES and WITHIN 300 SECONDS), which could be solved by requiring "SECONDS" but allowing X to be an integer or floating point. Switching to a single unit eliminates multiple ways of doing the same thing (as well as expanding the range of possible time scales), which I'm in agreement with.

I'm not a huge fan of the current approach to timestamp precision fields, but I think it's a good compromise. I don't think there's any duplicate functionality inherent in those fields. 

> -----Original Message-----
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of
> Bret Jordan (CS)
> Sent: Wednesday, October 26, 2016 2:04 PM
> To: Eric Burger <Eric.Burger@georgetown.edu>; cti@lists.oasis-open.org
> Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> Eric,
> 
> 
> 
> 
> Two questions:
> 
> 
> 
> 
> 1) Are you proposing we base this on a UNIX timestamp or staying with our
> current RFC3339 timestamp..
> 
> 
> 
> 
> 2) Are you proposing we get rid of the precision field?  If so, how does one
> say that this happened in May 2015 but I am not sure I remember which day?
> 
> 
> 
> 
> The reason I ask these questions, is I have heard others complain about this,
> over and over.  I just want to make sure we get this right as we will have to
> live with it for a very LONG time.
> 
> 
> 
> 
> Bret
> 
> 
> 
> 
> ________________________________
> 
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Eric
> Burger <Eric.Burger@georgetown.edu>
> Sent: Wednesday, October 26, 2016 12:55:59 PM
> To: cti@lists.oasis-open.org
> Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> Proposal is that any time specification be in seconds with arbitrary precision
> and specification. Specification can be integer, floating point, or floating point
> scientific notation. Depending on the use of the, feel free to truncate or say
> “Sorry Dave, I cannot do that.” I.e., if I am sending you a CYBOX thingy saying
> the time between event A and event B is 3.44E-6 seconds, but you cannot
> distinguish anything less than microseconds, feel free to truncate to 3.0E-6.
> Or, if I am sending you a STIX thingy that says “look for an event that occurs
> precisely 7.64773828432385745010105868734202934508245094345845098
> seconds, but you can only distinguish microseconds, we need to decide
> whether you need to be able to signal to the sender that you cannot accept
> that value, because it is way more than your precision, or you can silently
> truncate the value to the precision you care about.
> 
> 
> 	On Oct 26, 2016, at 2:29 PM, Bret Jordan (CS)
> <Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com> >
> wrote:
> 
> 	This really begs the question, and I am sorry in advance, but did we
> get our timestamp and timestamp-precision stuff all wrong????  If so, we
> should really fix that now.  The dynamics of the community that put us down
> this path have changed.
> 
> 	So Eric, as our resident current academic, what would like propose
> we do here?
> 
> 	Bret
> ________________________________
> 
> 
> 	From: cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org>
> <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> > on behalf of
> Eric Burger <Eric.Burger@georgetown.edu
> <mailto:Eric.Burger@georgetown.edu> >
> 	Sent: Wednesday, October 26, 2016 10:47:35 AM
> 	To: cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org>
> 	Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> 	Upon reflection, I have convinced myself the only unit should be
> seconds, with no specified precision.
> 
> 	Yes, the examples given are nice and SQL-like and human readable.
> 
> 	I would offer that examples with those nice, human readable decadal
> time units are thoroughly unrelated and of near zero value towards a MVP.
> Why? Because that nice, human readable format, either as specifying
> patterns or for displaying what was detect, is a role of the user interface
> software. It is not a role of the data format.
> 
> 	One and only one data format specification: seconds.
> 
> 	Allow integer, floating point, and scientific notation.
> 
> 	We are totally done - interoperability guaranteed or your money
> back.
> 
> 	For those who want to display or enter pattern in seconds,
> milliseconds, femtoseconds, jiffies (3E-4s), moments (90s), or millifortnights
> (~1210s)* will be happy. They can do whatever they want, without having to
> convince everyone to adopt those time units in the language.
> 
> 
> 
> 	* Yes, there is an IETF RFC that uses millifortnights as a time unit.
> 
> 
> 
> 		On Oct 26, 2016, at 11:58 AM, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com <mailto:Jason.Keirstead@ca.ibm.com> >
> wrote:
> 
> 		I can say from our perspective as someone who works on a
> product that does both Netflow as well as full 10gbps packet capture, a
> pattern like this would not be testable in real time, not would it be testable in
> the packet captures themselves.
> 
> 		With Netflow this level of resolution simply doesn't exist in
> the first place. With hardware  packet capture, you still don't have that true
> NS esolution, because the clock resolution on the card tops out between 8ns
> and 15-20ns depending on the vendor and clock mechanism. Furthermore
> with full packet capture based forensic solutions, that resolution of time is
> not normally retained when the packet enters the forensics userspace
> anyway so you can't even test it using the tool.
> 
> 		In short; yes there may be some theoretical use case here for
> nanoseconds but IMO the probability of implementation is near zero. It is
> certainly not MVP.
> 
> 		I won't even discuss picoseconds. The hardware doesn't
> exist.
> 
> 		--
> 		Sent from my mobile device, please excuse any typos.
> 
> 
> 		Kirillov, Ivan A. --- Re: [cti] Patterning Feedback -
> Timescales/Periodicity ---
> 
> From:	 "Kirillov, Ivan A." <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >
> 
> To:	 "Patrick Maroney" <Pmaroney@Specere.org
> <mailto:Pmaroney@specere.org> >, cti@lists.oasis-open.org
> <mailto:cti@lists.oasis-open.org>
> Date:	 Wed, Oct 26, 2016 10:26 AM
> Subject:	 Re: [cti] Patterning Feedback -Timescales/Periodicity
> ________________________________
> 
> 
> 		Pat – I have yet to see from you any real examples of
> patterns around 10 GbE metadata/PCAP captures, just the theoretical notion
> that it may be possible. As such, I don’t think this meets the bar of being
> MVP for patterning.
> 
> 		Regards,
> 		Ivan
> 
> 		From: Patrick Maroney <Pmaroney@Specere.org
> <mailto:Pmaroney@specere.org> >
> 		Date: Wednesday, October 26, 2016 at 8:00 AM
> 		To: "cti@lists.oasis-open.org <mailto:cti@lists.oasis-
> open.org> " <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> >,
> Ivan Kirillov <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >
> 		Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> 		@Eric: I was going to argue for Planck Time precision as we
> will indeed one day be dealing with covert channels and remote sensing
> using quantum entanglement.  However, I thought I -might- get push back
> on this and compromised with Picoseconds. 😬
> 
> 		@Ivan: 10 Gigabit ethernet Netflows and metadata from
> PCAP captures and network/security appliances that operate at these
> speeds is the current application/use case.
> 
> 
> 		@All : I also agree with Eric.  My argument is only for the
> need, not how we meet the need.  Adding three words to the spec seemed
> to be a reasonable compromise.
> 
> 		Get Outlook for iOS <https://aka.ms/o0ukef>
> 
> ________________________________
> 
> 		From: cti@lists.oasis-open.org <mailto:cti@lists.oasis-
> open.org>  <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> > on
> behalf of Kirillov, Ivan A. <ikirillov@mitre.org <mailto:ikirillov@mitre.org> >
> 		Sent: Wednesday, October 26, 2016 8:54:32 AM
> 		To: cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org>
> 		Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> 		I completely agree with Eric on his comments regarding
> precision being arbitrary.
> 
> 		Also, given that our current set of Cyber Observable Objects
> does not model entities such as CPU cache where signal latency is in the
> realm of microseconds/nanoseconds/etc., can anyone (Pat or others)
> actually come up with a real pattern for detecting malice using our current set
> of Objects that requires such precision? I suspect not, though I’d be happy to
> be proven wrong.
> 
> 		Regards,
> 		Ivan
> 
> 		From: <cti@lists.oasis-open.org <mailto:cti@lists.oasis-
> open.org> >, Eric Burger <ewb25@georgetown.edu
> <mailto:ewb25@georgetown.edu> > on behalf of Eric Burger
> <Eric.Burger@georgetown.edu <mailto:Eric.Burger@georgetown.edu> >
> 		Date: Wednesday, October 26, 2016 at 3:30 AM
> 		To: "cti@lists.oasis-open.org <mailto:cti@lists.oasis-
> open.org> " <cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org> >
> 		Subject: Re: [cti] Patterning Feedback -Timescales/Periodicity
> 
> 		I thought this topic was discussed, argued, beaten to death,
> and the consensus was that precision was arbitrary and could be
> infinitesimal.
> 
> 		In a machine readable language, why are we using English
> words to describe units?
> 
> 		In a machine readable language, designed for exchanging
> information at machine speeds, why are we using human speeds to describe
> time?
> 
> 		I disagree with Patrick here that we should add three more
> decimal multiples. I do agree that in a machine readable language operating
> at machine speeds, we will have to make sure our language scales as those
> speeds get faster and faster. The current proposal fails to do that. As such,
> unless we are willing to use the Planck Time (~ 5 x 10-44 s) as the base unit,
> we will always be wishing we had smaller decimal multiples.
> 
> 		Here is a counter proposal:
> 		1: Pick exactly two time units. One for humans, one for
> machines. I would offer seconds and picoseconds.
> 		2: Allow for integer, float, and scientific notation for the time
> specification.
> 
> 		Integer seconds covers 136 years of time in just a 32-bit
> integer. That should be more than enough time to correlate two events in
> human scale.
> 		Integer picoseconds covers 213 days of time in a 64-bit
> integer. That should be more than enough time to correlate any two events
> in machine scale. For that matter, it really should be enough time to correlate
> most events in human scale.
> 
> 		Is this future proof? When we have optimal quantum
> computers, we can still have expressions that say:
> 		The wavelength changes within 2.5E-42 seconds or The
> wavelength changes within 2.5E-27 picoseconds
> 
> 		Saying we will have to add femtoseconds, attoseconds,
> yadda, yadda is not future-proof.
> 
> 
> 
> 			On Oct 25, 2016, at 8:48 PM, Patrick Maroney
> <Pmaroney@Specere.org <mailto:Pmaroney@specere.org> > wrote:
> 
> 			Re: It is really critical that we get more technical
> review of this 'Patterning' approach before moving to a Committee
> Specification Draft (CSD)
> 
> 			“Our CTI lexicon MUST allow representation of
> events at the timescales/periodicity of the operational domain we (and our
> machines) are observing, measuring, and conveying to others.”
> 
> 			This is particularly true of a CTI patterning language
> specifically tasked with describing and detecting temporal event
> relationships.
> 
> 			A sampling of citations:
> 
> 			10 Gigabit Ethernet Transmissions Technologies
> 			Joe Lutz: Chief Cook and Bottle Washer
> 			http://www.sonet.com/EDU/10ge.pdf
> <http://www.sonet.com/EDU/10ge.pdf>
> 
> 			C5: Cross-Cores Cache Covert Channel
> 			Cl´ementine Maurice , Christoph Neumann , Olivier
> Heen , and Aur´elien Francillon
> 
> 	http://www.s3.eurecom.fr/docs/dimva15_clementine.pdf
> <http://www.s3.eurecom.fr/docs/dimva15_clementine.pdf>
> 
> 			Cache Storage Attacks
> 			Billy Bob Brumley
> 
> 	http://www.springer.com/cda/content/document/cda_downloaddo
> cument/9783319167145-c2.pdf?SGWID=0-0-45-1496482-p177303495
> <http://www.springer.com/cda/content/document/cda_downloaddocume
> nt/9783319167145-c2.pdf?SGWID=0-0-45-1496482-p177303495>
> 
> 			Eliminating Cache-Based Timing Attacks with
> Instruction-Based Scheduling
> 			Deian Stefan, Pablo Buiras , Edward Z. Yang , Amit
> Levy , David Terei , Alejandro Russo , and David Mazières
> 
> 	https://cseweb.ucsd.edu/~dstefan/pubs/stefan:2013:eliminating.pd
> f <https://cseweb.ucsd.edu/~dstefan/pubs/stefan:2013:eliminating.pdf>
> 
> 			Understanding Contention-Based Channels and
> Using Them for Defense
> 			Casen Hunger, Mikhail Kazdagli, Ankit Rawat, Alex
> Dimakis, Sriram Vishwanath, Mohit Tiwari The University of Texas at Austin
> 			http://users.ece.utexas.edu/~tiwari/pubs/HPCA-15-
> contention.pdf <http://users.ece.utexas.edu/~tiwari/pubs/HPCA-15-
> contention.pdf>
> 
> 
> 			Respectfully request that we add the following 3
> words to the specification for those who need to express these periodicities:
> 
> 			PICOSECONDS
> 			NANOSECONDS
> 			MICROSECONDS
> 
> 
> a WITHIN xMILLISECONDS | SECONDS | MINUTES | HOURS| DAYS | MONTHS
> | YEARS a MUST be an Observation Expression or a preceding Qualifier. All
> Observations that match a MUST occur, or have been observed, within the
> specified time window.
> 
> If there is a set of two or more Observations matched by a, the most recent
> Observation timestamp contained within that set MUST NOT be later than
> the delta of the earliest Observation timestamp within the set plus the
> specified time window.
> 
> Example:
> ([file:hash.SHA-256 = '13987239847'] ALONGWITH [win-registry-key.key =
> 'hkey']) WITHIN 2 MINUTES
> 
> The above Pattern Expression looks for a filehash and a registry key that
> were observed within 2 minutes of each other. The parentheses are needed
> to apply the WITHIN Qualifier to both Observation Expressions.
> 
> 
> 			Patrick Maroney
> 			Office:  (856)983-0001
> 			Cell:      (609)841-5104
> 
> 			<image001.png>
> 
> 			President
> 			Integrated Networking Technologies, Inc.
> 			PO Box 569
> 			Marlton, NJ 08053
>