A couple worth reading.
https://tools.ietf.org/html/rfc7011
https://tools.ietf.org/html/rfc3917
From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, September 5, 2016 at 11:59 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: Terry MacDonald <terry.macdonald@cosive.com>, OASIS list <cti-cybox@lists.oasis-open.org>, Allan Thomson <athomson@lookingglasscyber.com>, "Kirillov, Ivan" <ikirillov@mitre.org>, Patrick Maroney <Pmaroney@specere.org>
Subject: Re: [cti-cybox] Network Connection Object
I feel like all parties would be best to go and read a bit on IPFIX/Netflow and refresh on all it contains, as it seems the conversation is assuming that a flow is
just the 5 tuple.... The 5 tuple is just the KEY, it does not describe the entirety of a flow...A lot of the information people are classifying as "raw packet" or "packet headers", actually exists in a standard Netflow record. Flow records have TCP flags and
ICMP type/codes for example.
Wondering if any of the Cisco folks want to chime in? The behaviour I was previously describing RE unidirectional flows and flows without ACK, is standard behaviour in Netflow.
--
Sent from my mobile device, please excuse any typos.
Jordan, Bret --- Re: [cti-cybox] Network Connection Object ---
|
From:
|
"Jordan, Bret" <bret.jordan@bluecoat.com>
|
|
To:
|
"Terry MacDonald" <terry.macdonald@cosive.com>
|
|
Cc:
|
"OASIS CTI TC CybOX SC list" <cti-cybox@lists.oasis-open.org>, "Allan Thomson" <athomson@lookingglasscyber.com>, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Patrick
Maroney" <Pmaroney@specere.org>
|
|
Date:
|
Tue, Sep 6, 2016 7:44 AM
|
|
Subject:
|
Re: [cti-cybox] Network Connection Object
|
We just need to remember the whole purpose of STIX and CybOX is to share TI in a lossless way. I would also argue that if there is a standard way that everyone is already using, we should just use that. Historically I feel we had a "not-invented-here"
problem. Let's not reinvent the wheel or boil the ocean. If we are providing basic summary data of a network flow, then that sounds great for something that CybOX can and should do. If we are talking about actual packet headers than CybOX should NOT do that,
we should just include the headers in a libpcap or libpcap-ng format.
Bret
Sent from my Commodore 64
So as I see it we have a few different levels of summarization we can make...
1. The individual raw packet (full detail for a single packet)
2. The protocol headers for a single packet (connection level information)
3. Summary of the protocol information and type of connection over the lifetime of a single bi-directional connection between two hosts (summary bidirectional traffic flow for a single connection)
4. Summary of bidirectional traffic flow from multiple hosts to a single endpoint, or from a single host to multiple endpoints (summary bidirectional traffic flow for multiple connections)
I personally think they are all important to map, but for different use cases. Summary information allows the sharing of different traffic patterns that could be used as observed data to support a trip that a threat actors uses. Summary of a single traffic
connection could demonstrate how a particular attack works.
The question is, can we do all of them, and can we do it in a way that is simple to use, rather than trying to conflate these different objectives into a single object?
Cheers
Terry MacDonald
Cosive
On 4/09/2016 7:21 AM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
Let's model some of these real examples and see where the wheels come off the bus.
Bret
Sent from my Commodore 64
So... two points...
- It is incorrect to assume that SYN without ACK is not a flow. It is. Such network traffic is indeed reported as a network flow. We call it a "unidirectional flow", and it's often anomalous. Unidirectional flows can also occur with UDP, sometimes anomalous
sometimes not.
- Therefore, even if you split this, I would still be modeling the behaviour Patrick describes as a flow, it would just mean I now have to link other data to it, whereas now that data is an extension, because I need to be able to affiliate for example these
src/destTCP flags with my flow.
--
Sent from my mobile device, please excuse any typos.
Patrick Maroney --- Re: [cti-cybox] Network Connection Object ---
Sounds like we are in total agreement. So, do we the (CTI TC) have consensus on two forms of representations (please take my characterizations in a general sense):
(1) Network Flows (in the traditional sense)
(2) Network traffic/protocol artifacts.
If so, let's move forward with defining each of these forms.
Pat I totally agree, and I believe we need a way of doing this... I just not agree with overloading objects to make them do more use-cases than they should. I believe we have a use-case for the concept of a Network Flow and the current
Network Connection object really speaks to that use-case.
Also, as I stated in my previous email, think we need an object that can easily and intuitively characterize these other things.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
In deciding this, I would like to emphasize that what we need to characterize may not fit within the bounds of expected behavior. I will again cite Covert Channels.
Nation State and Determined Adversaries regularly use a number of stealth methods to obfuscate command & control and data exfiltration. For example, these covert
signals may be embedded in an outgoing TCP SYN packet to which there is never a SYN/ACK, and therefore never a “Flow” (this is just one of dozens of examples). The Destination IP may not be the actual Destination (especially the case with Covert Channels
using UDP as the signal transport layer).
For those that will respond with: “…sure, but these are fringe cases”, I respond with: “You may never realize the extent to which these TTPs may actually be used
in your networks (or customer’s networks) until those of us with knowledge of specific instantiations can express to you how to detect these methods of covert communications.”
>> IPFIX allows far more than basic 7-tuple and as you know CyBox network connection has the ability to contain that information.
That’s true. My point was moreso that, at least for me, the term “network flow” is strongly associated with basic network connection metadata such as that encompassed
by 7-tuple netflow. Maybe others don’t have the same connotation.
>> For me, we are arguing a nuanced definition of what information is represented when one system ‘attempts’ to communicate with another. An attempt does not necessarily
mean they actually connect. It just means there was a communication in at least one direction.
This is indeed nuanced, but I think the semantics of ‘attempted’ connections can also clearly be represented as a network connection with state; e.g., a TCP connection
with just a SYN and no SYN-ACK from the server. I’m not sure if state is something that is semantically associated with a network flow.
Hi Ivan – IPFIX allows far more than basic 7-tuple and as you know CyBox network connection has the ability to contain that information.
I think the key point to keep in mind is whether connection implies actually ‘a connection’ when one does not exist.
For me, we are arguing a nuanced definition of what information is represented when one system ‘attempts’ to communicate with another. An attempt does not necessarily
mean they actually connect. It just means there was a communication in at least one direction.
Therefore, for me a flow is more accurate a term than a connection.
But it’s a very nuanced argument and I could easily see both are acceptable.
I’m not really a fan of “Network Flow”. Our current Network Connection Object includes extensions such as HTTP and Network Socket that go far beyond simple network
flow. When I hear “network flow”, I think of the basic 7-tuple netflow representation, and my concern is that users will think the same when seeing the name of this Object, which is misleading.
I would like to propose that we rename the Network Connection object to Network Flow object. Then if needed, created a specialized Network Connection State object to handle some of the use cases John-Mark was talking
about, namely devices that may want to emit events in CybOX when a connection is opened or closed.
As it stands right now, the current Network Connection object is really describing a Network Flow. Making this name change might really help remove some of the ambiguity associated with it.
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
|