|
I think we should really look at solving these as separate use cases from the base use case of a network flow / connection.
Jason can you share how you do this or how you would propose doing this, if for example you were not using the network connection object? Let's figure out what it needs to look like before we figure out where it should go.
Bret
Sent from my Commodore 64
There are at minimum 3 cases to be considered which we see very often in the real world:
- One single host attempting connection to many different destinations on the same port ( Port scanning network for an open service; multiplicity is on source port and on destination IP )
- Many hosts attempting connection to a single destination on the same port ( typical DDOS attack; multiplicity is on source IP and source port )
- One single host attempting connection to one other host on many different destination ports ( Port scanning a single host; multiplicity is on destination port and sometimes also source port )
We see these often enough that we create optimized flow constructs for them (we call them "Superflows" in our product) so that you don't end up with enormous data duplication.
I have no problem with the idea of figuring out a way to handle this via a Network Connection extension of some sort, if we can determine a way to do that without resulting in confusion.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security |
www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif> "Jordan, Bret" ---08/26/2016 04:45:42 PM---I agree that finding a better way to do it, would be good... I personally do not like overloading th
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Terry MacDonald <terry.macdonald@cosive.com>
Cc: Jason Keirstead/CanEast/IBM@IBMCA, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 08/26/2016 04:45 PM
Subject: Re: [cti-cybox] Network flow object suggestions
Sent by: <cti-cybox@lists.oasis-open.org>
I agree that finding a better way to do it, would be good... I personally do not like overloading the Network Connection object to document DDoS and Port Scanning.. I would love to see some proposals for how best to document them.
The port scanning option represents the worst case scenario from a structure standpoint.
One SRC talking to Multiple DST IP addresses and on each DST IP Address talking to multiple Ports.
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."
On Aug 26, 2016, at 13:18, Terry MacDonald <terry.macdonald@cosive.com> wrote:
Which is what the multiplicity in the STIX sighting relationship object is for. We should keep the network flow object for recording one flow, and use the sighting for saying 'and other stuff like this'.
Cheers
Terry MacDonald
Cosive
On 26/08/2016 22:13, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:
Multiple sources and dests is not to handle multicast. It is an encoding optimization to handle DDOS and port scan attempts. Without it, to encode a DDOS you may have 100,000 duplicate objects.
Sent from IBM Verse
Jordan, Bret --- Re: [cti-cybox] Network flow object suggestions ---
Good catch, I have not really gotten to that object yet... So yes, I would agree, I am not sure why we would allow a list for the source/src/initiator
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."
On Aug 25, 2016, at 15:24, Terry MacDonald <terry.macdonald@cosive.com> wrote:
Hi all
I have some questions about the network flow object.
----
The first is about the multiplicity of the source_refs.
Multicast traffic always so comes from a single source. So does a network broadcast. So is there any reason to have the source as a list when there is always just one source? Am I missing something?
We should really change its name to src_ref, and restrict it to one object-ref.
----
The second is around the list of options in the protocols field. We should probably provide an open vocabulary taken from both the IANA protocol list and the IANA services list to provide people a list of common options they should use. Otherwise
we'll hit problems like people putting in 'ip' rather than ipv4 or ipv6, which is ambiguous.
Cheers
Terry MacDonald
Cosive
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
|
