|
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 CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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.”
Hi 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,
Ivan
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.
allan
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.
Regards,
Ivan
I like that suggestion.
Allan
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.
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."
|