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?
Discussion around this Object will be one of the main topics of tomorrow’s working call.
Regards,
Ivan