[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] Network Connection Object
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
Let's model some of these real examples and see where the wheels come off the bus.
Bret
Sent from my Commodore 64So... 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 ---
From: "Patrick Maroney" <Pmaroney@Specere.org> To: "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: "Allan Thomson" <athomson@lookingglasscyber. com >, "Kirillov, Ivan A." <ikirillov@mitre.org>, "OASIS CTI TC CybOX SC list" <cti-cybox@lists.oasis-open.org >Date: Fri, Sep 2, 2016 7:03 PM Subject: 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
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.
Thanks,
Bret
Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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."
On Sep 2, 2016, at 14:11, Patrick Maroney <Pmaroney@Specere.org> wrote:
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.”PatFrom: <cti-cybox@lists.oasis-open.org > on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Friday, September 2, 2016 at 4:10 PM
To: Allan Thomson <athomson@lookingglasscyber.com >, Bret Jordan <bret.jordan@bluecoat.com>, OASIS CTI TC CybOX SC list <cti-cybox@lists.oasis-open.org >
Subject: Re: [cti-cybox] Network Connection ObjectHi Allan,>> 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.Regards,IvanFrom: Allan Thomson <athomson@lookingglasscyber.com >
Date: Friday, September 2, 2016 at 1:38 PM
To: Ivan Kirillov <ikirillov@mitre.org>, Bret Jordan <bret.jordan@bluecoat.com>, OASIS CTI TC CybOX SC list <cti-cybox@lists.oasis-open.org >
Subject: Re: [cti-cybox] Network Connection ObjectHi 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.allanFrom: "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Friday, September 2, 2016 at 11:36 AM
To: Allan Thomson <athomson@lookingglasscyber.com >, "Jordan, Bret" <bret.jordan@bluecoat.com>, OASIS list <cti-cybox@lists.oasis-open.org >
Subject: Re: [cti-cybox] Network Connection ObjectI’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.Regards,IvanFrom: <cti-cybox@lists.oasis-open.org > on behalf of Allan Thomson <athomson@lookingglasscyber.com >
Date: Friday, September 2, 2016 at 11:34 AM
To: Bret Jordan <bret.jordan@bluecoat.com>, OASIS CTI TC CybOX SC list <cti-cybox@lists.oasis-open.org >
Subject: Re: [cti-cybox] Network Connection ObjectI like that suggestion.AllanFrom: OASIS list <cti-cybox@lists.oasis-open.org > on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, September 2, 2016 at 9:58 AM
To: OASIS list <cti-cybox@lists.oasis-open.org >
Subject: [cti-cybox] Network Connection ObjectI 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.
Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]