Re: [cti] Network Traffic Object External Relationships

[Sean Barnum <sean.barnum@FireEye.com>]

I think a little clarification is needed here.

 

On Slack, Bret asked if anyone understood why âencapsulates_refsâ and âencapsulated_by_refsâ were agreed to be broken out into separate Relationships rather than stay embedded.

I responded with the below characterization of a typical CTI use case for network traffic and why breaking out these relationships would be necessary to support that use case.

 

Well, the encapsulated relationships should definitely be broken out for anyone who may wish to use deterministic ids for NetworkTraffic as the relationship between the two NetworkTraffics is definitely not inherent or immutable. It may be so for a single observation but not for the observables in general. Imagine that you found a given malware sample beacon out (NetworkTraffic(id=x;src_ref=ip1;dst_ref=ip2;protocols=âtcp")), then upload (to the same infrastructure) a system information profile of the infected system (NetworkTraffic(id=x;src_ref=ip1;dst_ref=ip2;protocols=âtcp");Relationship(source_ref=NetworkTrafficx; target_ref=FileY;relationship_type=âcontainsâ)) and then finally pop a reverse shell and tunnel the traffic (to the same infrastructure) using ssh inside the normal TCP/IP traffic ((NetworkTraffic(id=x;src_ref=ip1;dst_ref=ip2;protocols=âtcpâ);(NetworkTrafficx(id=z;src_ref=ip1;dst_ref=ip2;protocols=âsshâ);Relationship(source_ref=NetworkTrafficx; target_ref=NetworkTrafficz;relationship_type=âencapsulatesâ)). If you were to publish/share this info you would want to clearly express that all three interactions were from the same source to the same destination which is possible with a deterministic id on the NetworkTraffic. Further, as you can see encapsulation relationships are not true of the observable at all times and placing âencapsulatesâ as an embedded relationship would not convey what is wished to convey and would actually convey incorrect info. Does that make sense?

 

Bret responded that he does not think this is realistic because NetworkTraffic objects would always have full detail including specific temporal details of when they occurred.

My assertion (as stated many times in the thread) is that while the use case of wanting to express full detail of network traffic including temporal details is a valid use case and should be supported, it is NOT the only use case for NetworkTraffic and is in truth not even the typical use case for NetworkTraffic within the CTI domain. CTI analysis is about analyzing and understanding what is happening and why (who, where, when, etc) in order to enable good security decision making. The foundational data at the bottom of the pile for CTI are pure observations, typically captured with tools and often fully fleshed out in detail. The CTI analysis process then looks across all of this, often with tools, to filter down to which observations are relevant then use further analysis on those to filter down to which details of those observations are relevant and then iteratively connect the dots with these to higher order SDO type CTI constructs. The reality is that the vast majority of observable info shared as part of CTI is NOT fleshed out detail but rather just the bits that are relevant to understand the contextual association or meaning intended. It is VERY common in CTI to reference network traffic ONLY with the dst_ref and protocol to convey an outbound connection to some network address without any further detail.

 

As you can see from the example above and hopefully from my attempt at some contextualization the example we were discussing (and I guess disagreeing on) in the Slack thread is very different from the one Bret provided in this email.

 

The example Bret provides below is about ânetwork flow between two points during a certain time elementsâ.

This is a perfectly valid use case and I do not disagree that for this use case where you are specifically bounding the object to a very specific network flow at a specific time the âencapsulates-refâ relationship could be viewed as inherent and immutable and okay to be embedded.

However, this is NOT the only valid use case (not even the most common) and for the common situations where you want to convey an âencapsulatesâ relationship between two NetworkTraffic objects that are more abstractly characterized (without specific time bounding such as simply an outbound connection to a specific address) then you need to have the relationship broken out otherwise it forces you to convey incorrect information.

 

 

>> But to me that does not make sense as that is not how the network works.

 

STIX is not about conveying information on âhow the network worksâ. It is not a network traffic/flow representation standard. STIX is a CTI information standard and is about conveying CTI information.

CTI information may, based on context, include BOTH detailed characterizations of âhow the network worksâ AND more commonly more generalized information about intelligence that does not require everything about  âhow the network worksâ.

STIX MUST support both contexts.

 

This was my assertion in the Slack channel and very much is still my assertion here.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, April 24, 2019 at 12:47 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Network Traffic Object External Relationships

 

All,

 

Sean and I have been having a disagreement on slack, so to get consensus we need the rest of the TC to weigh in on this topic.

 

The Mini-Group proposed that the following embedded relationships on the Network Traffic Object SCO be made external.

 

encapsulates_refs

encapsulated_by_refs

 

 

I disagree with this change and think they should remain embedded, now that I understand why this was proposed. A network flow between two points during a certain time elements does NOT change its encapsulation on the fly.  This is not how the network works.  

 

So say I document that HTTPs traffic between 1.1.1.1 and 2.2.2.2 on port 4242 was tunneled over SSH from Jan1 to Jan2.  That tunneling is over SSH for the time frame that the network traffic object is being described.  You would not then say that the same Network Traffic Object is now being tunneled over some other encapsulation (say DNS TXT records) at a different time. 

 

In my mind, you would create a second Network Traffic Object for that event and then you would link the two network traffic objects together.  This would then allow you to express confidence in your assertion that these two network traffic objects are in fact the same or similar enough to be viewed as the same thing.  But reusing a Network Traffic Object is, IMO, wrong.

 

Sean thinks that you should have one Network Traffic Object and be able to reuse it over and over and say that it was encapsulated in X in January, and Y in February, and Z in March.  But to me that does not make sense as that is not how the network works.

 

I would like to hear what others have to say. If I am wrong, please let me know. 

 

Bret

 

 

 

 

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.