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


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.

Get Outlook for iOS

 


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

 

 




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