[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] Network flow object suggestions
I see two problems with this approach
- It will create a huge amount of bloat to have to define a Cybox object for every IP involved in a DDOS, which routinely number in the thousands to tens-of-thousands. If every one is wrapped in an object, you're talking about a very large amount of graph objects that actually do not deserve to be TLOs.
- You can't use this method to describe port scans, as there is no "Port" object.
-
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
Terry MacDonald ---08/29/2016 11:35:23 PM---Hi Ivan, IMHO the network connection object should model what a network connection
From: Terry MacDonald <terry.macdonald@cosive.com>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Cc: Jason Keirstead/CanEast/IBM@IBMCA, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Bret Jordan <bret.jordan@bluecoat.com>
Date: 08/29/2016 11:35 PM
Subject: Re: [cti-cybox] Network flow object suggestions
Sent by: <cti-cybox@lists.oasis-open.org>
o Cons: Semantic overloading of src_refs leads to complexity, especially from a user’s standpoint. Could lead to interoperability issues with CybOX content that uses the Network Connection Object.
o Cons: Semantic overlap between base src/dst properties and those on the Superflow extension
o Cons: Semantic overlap between Network Connection Object – some properties (e.g., protocols) would likely need to be duplicated.
>>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.
Agreed – given that there’s no single definitive source of protocols, I think we’ll likely have to create an open vocabulary with a set of common protocols taken from IANA and other places.
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Monday, August 29, 2016 at 7:49 AM
To: Terry MacDonald <terry.macdonald@cosive.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Bret Jordan <bret.jordan@bluecoat.com>
Subject: Re: [cti-cybox] Network flow object suggestions
It sounds like we need another call on this topic. Trey and I are available at 10:00am EDT tomorrow if that works – let’s try to address this topic and put the finishing touches on Network Connection.
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Saturday, August 27, 2016 at 9:57 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Bret Jordan <bret.jordan@bluecoat.com>
Subject: Re: [cti-cybox] Network flow object suggestions
True you can't model all the ddos connections in the sighting object, but my understanding is that you were only supposed to model a selection of connections within the sighting as examples of the connection if you were wanting to track connections. You wouldn't model all the connections you saw. In which case you would have 3 or 4 observed data objects, each with an example of one ddos connection in them (out something like that).
I don't like the idea of conflating yet another layer of 'multiplicity' into CybOX/STIX.
Cheers
Terry MacDonald
Cosive
On 27/08/2016 7:45 AM, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:
I am unsure how you would encode a DDOS using sighting in this manner without duplicating the network connection, can you give an example?
-
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
Terry MacDonald ---08/26/2016 04:18:57 PM---Which is what the multiplicity in the STIX sighting relationship object is for. We should keep the n
From: Terry MacDonald <terry.macdonald@cosive.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: cti-cybox@lists.oasis-open.org, Bret Jordan <bret.jordan@bluecoat.com>
Date: 08/26/2016 04:18 PM
Subject: Re: [cti-cybox] Network flow object suggestions
Sent by: <cti-cybox@lists.oasis-open.org>
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:
|
|
|
|
| |
|
|
|
|
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."
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]