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: [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> 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>
To:"Patrick Maroney" <Pmaroney@Specere.org>, 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>
Date: Wednesday, October 26, 2016 at 8:00 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Ivan Kirillov <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.

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Wednesday, October 26, 2016 8:54:32 AM
To: 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>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, October 26, 2016 at 3:30 AM
To: "cti@lists.oasis-open.org" <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> 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
 
C5: Cross-Cores Cache Covert Channel
Cl´ementine Maurice , Christoph Neumann , Olivier Heen , and Aur´elien Francillon
 
Cache Storage Attacks
Billy Bob Brumley
 
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
 
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
 
 
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
 

 




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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