[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] Network flow object suggestions
Also since CybOX relationships are all embedded ID references anyway this is essentially just the same solution and would require making src_ref and dst_ref an array. Off the top of my head having a superflow object (option 3) would be a good idea. Smaller, more tightly focused objects seem like a win to me. That said…will there be other places where we need an object to represent what’s effectively an aggregation of many of a different object? If so, will this pattern (option 3) also work
for those cases? John From:
<cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> I see two problems with this approach
Based on this discussion thread and that on Slack, it seems like we have a few options with regards to the Network Connection Object in this context:
·
Option 1: Keep the Object the way it is (i.e., src/dst_refs and src/dst_ports)
o
Pros: Supports characterizing DDoS, port scanning, basic point-to-point connections, and everything in between
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. ·
Option 2: Restrict src/dst_refs and src/dst_ports to singletons (i.e. src_ref/dst_ref and src_port/dst_port) and add a “Superflow” extension (with src_refs/dst_refs and src_ports/dst_ports)
o
Pros: Base set of properties are clear and easy to use, DDoS and port scanning are supported by extension and can still use “valid” properties such as
protocols. Extension can be created and added post-MVP. o
Cons: Semantic overlap between base src/dst properties and those on the Superflow extension ·
Option 3: Restrict src/dst_refs and src/dst_ports to singletons (i.e. src_ref/dst_ref and src_port/dst_port) and add a new “Superflow” Object (with src_refs/dst_refs and src_ports/dst_ports)
o
Pros: Base set of properties are clear and easy to use, DDoS and port scanning are supported by new Object. Object can be created and released post-MVP, and could have its own capabilities, such as the ability to specify
port ranges (as an example). o
Cons: Semantic overlap between Network Connection Object – some properties (e.g., protocols) would likely need to be duplicated. Personally, I I’m leaning towards option 2 or 3. I think we need to make sure that the “base” Network Connection Object is semantically accurate and easy to use by implementers,
and we can add support for DDoS and port scanning characterization down the road.
>>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> 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> 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 On 27/08/2016 7:45 AM, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
wrote:
Cheers
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.
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]