Re: [cti-cybox] CybOX Object Selection

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I would advocate against the "lets include it because it is easy" approach.

If there is not a strong use case for an object *or* there is not a strong champion on the list to advocate for it - then skip it (IE, an object should need a strong use case *and* a strong champion who actually uses it today in active use). Adding later is easier than revising or removing.

I have another proposal as well. There are a large number of objects in here that are only used by MAEC. I wonder if these should be grouped into some MAEC extension of Cybox if they have no strong champions outside of the MAEC realm. Thoughts?

-
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." ---02/02/2016 01:17:08 PM---As we discussed today, one the things we’d like to do soon is figure out the set of Objects that wil

From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 02/02/2016 01:17 PM
Subject: [cti-cybox] CybOX Object Selection
Sent by: <cti-cybox@lists.oasis-open.org>

---

As we discussed today, one the things we’d like to do soon is figure out the set of Objects that will make be included in CybOX 3.0: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Object-Selection. This will help us scope the release and allow us to prioritize efforts on some of the critical refactoring that needs to be done (e.g., around Network Connection).

Overall, there appeared to be consensus on NOT including any new Objects in CybOX 3.0 and focusing on refactoring the existing set from v2.1. While there wasn’t clear consensus on the green-field approach, it appeared that many thought it would serve as a suitable starting point for determining this set, with the following considerations:

1. For the Objects NOT included in the green-field approach, we should figure out the level of effort to include them. If it is minimal, then they could be candidates for inclusion. We will work on assessing this.
2. We need more input from the community on the Objects in the green-field approach and whether they make use of those Objects that may not be currently included (list below). Again, it’s worth noting that these Objects will likely be included in a future CybOX 3.x minor release.
3. There are Objects that may not be included but whose properties may be included in some of forthcoming refactoring. E.g., some properties relating to Network Flow may be included in the refactored Network Connection Object.
4. There’s some intelligent refactoring we can do to further reduce the Object set. For instance, the Windows Mutex Object can be represented as a relationship between a Windows Handle and a Mutex Object.

For #2, here’s the list of Objects that would currently NOT be included in the CybOX 3.0 Object set for the green-field approach (no known usage from CTI-stats or MAEC):

• Account
• Archive File
• ARP Cache
• DNS Cache
• GUI Dialog Box
• Image File
• Linux Package
• Network Flow
• Network Packet
• Network Route Entry
• Network Route
• Network Subnet
• Semaphore
• SMS Message
• Unix File
• Unix Network Route
• Unix Pipe
• Unix Process
• Unix User Account
• Unix Volume
• URL History
• Volume
• Win Computer Account
• Win Critical Section
• Win Event Log
• Win Event
• Win Filemaping
• Win File
• Win Hook
• Win Kernel
• Win Mailslot
• Win Hook
• Win Memory Page Region
• Win Network Route Entry
• Win Prefetch
• Win Semaphore
• Win System
• Win System Restore
• Win Task
• Win User Account
• Win Volume
• Win Waitable Timer
• X509 Certificate

Regards,
Ivan