FWIW this was the same reason for "multiple sources" - to be able to model DDOS without having thousands of objects.
-
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 
"Kirillov, Ivan A." ---06/15/2016 02:55:46 PM---Ah yes, thanks for pointing this out (and no worries about missing the call). I thought there was a
From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 06/15/2016 02:55 PM
Subject: Re: [cti-cybox] For review: Network Connection Object
Sent by: <cti-cybox@lists.oasis-open.org>
Ah yes, thanks for pointing this out (and no worries about missing the call). I thought there was a use case for having multiple destination addresses, and couldn’t remember what it was so I erroneously thought it was related to IP multicast. Port scanning does sound like a valid application for having multiple destination addresses, though it’s something that we’ll probably want to document well (i.e., regarding valid applications of multiple destination addresses) to avoid confusion.
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, June 15, 2016 at 10:49 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] For review: Network Connection Object
Hi - first, apologies I could not attend this call (it seems I am in perpetual conflict with the cybox working call).
RE "multiple destinations for a network connection" - The use case for this is not IP multicast, it is to be able to handle port scan attempts (either scanning 1 port across many hosts, or scanning multiple ports across one host, or both). A port scan is best modeled as a unidirectional flow to many destinations simultaneously. Otherwise, to handle the port scan you have to create X thousand network connection objects, all with the exact same information, but different destination endpoints.
I don't have enough context from below to discuss the "HTTP as relationships" question, but it sounds a bit overly complex on the surface... what is the benefit of this approach?
-
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 
"Kirillov, Ivan A." ---06/15/2016 01:44:17 PM---We had a good discussion around the Network Connection Object today during the CybOX working call. H
From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 06/15/2016 01:44 PM
Subject: Re: [cti-cybox] For review: Network Connection Object
Sent by: <cti-cybox@lists.oasis-open.org>
We had a good discussion around the Network Connection Object today during the CybOX working call. Here are some of the main open questions/takeaways:
- · We discussed the overall goal of the Network Connection Object for MVP, which is to have something that is stable and useful for the majority of use cases around network connections, and can then be expanded in future releases as needed.
· It was pointed out that having multiple destinations for a network connection doesn’t make sense (IP multicast doesn’t work this way), so we’ve reverted dst_refs to dst_ref to allow only a single destination per network connection.
· We discussed which fields should be required for a network connection; there was consensus that dst_ref should be required, and likely src_ref as well. However, it was pointed out that there are cases where you may not want to share data about the source of a network connection (it could be sensitive data), so we haven’t decided yet if we’ll mandate that src_ref is required.
· There was some discussion of whether extensions such as HTTP should instead be separate Objects that are associated with a network connection via relationships. The notion is that these are complex structures which could be Objects in their own right and could also be used in a standalone capacity as separate Objects.
· We briefly discussed the possibility of a network packet object/extension, and there was consensus that it made sense. It’s not clear if this is something that should be MVP, however.
The rest are documented under the “Open Questions” for the Object: https://docs.google.com/document/d/1oPAHN6nitdVF60RuDlajq0VuN6S_p_RP3ZE48yOBBfQ/edit#heading=h.j4fc21y66bxr
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Wednesday, June 15, 2016 at 7:39 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] For review: Network Connection Object
Yeah, I agree – flow payloads are different from packet payloads, so we’d need a separate extension for the latter.
Regards,
Ivan
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, June 15, 2016 at 6:38 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] For review: Network Connection Object
IMO per-packet payloads would not belong in the "flow" extension, they would go into a "packet" extension (of which one could make a list). A flow is a different concept than a simple collection of packets.
-
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 
"Kirillov, Ivan A." ---06/14/2016 06:24:56 PM---The Network Connection Object is finally ready for review: https://docs.google.com/document/d/1oPAHN
From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 06/14/2016 06:24 PM
Subject: [cti-cybox] For review: Network Connection Object
Sent by: <cti-cybox@lists.oasis-open.org>
The Network Connection Object is finally ready for review: https://docs.google.com/document/d/1oPAHN6nitdVF60RuDlajq0VuN6S_p_RP3ZE48yOBBfQ/edit#heading=h.rgnc3w40xy
There are a number of open questions around this Object, including the following:
- Right now all fields are optional - should any be required?
- Should protocols be broken down by OSI layer, as in the current implementation?
- Things like IP don’t fit cleanly into the OSI model
- Does the initial collection of extensions make sense?
- Are any missing?
- Should the HTTP extension also characterize responses? At the moment it only characterizes HTTP requests.
- The flow extension currently captures an entire network connection payload - should we consider capturing per-packet payloads as well?
Regards,
Ivan