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.