OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-cybox] CybOX Objects/Relationships


To clarify and help frame the discussion around CybOX with regards to TLOs and being a stand-alone language:
  • By standalone, we mean simply that instances of CybOX data could be created and shared in the same manner as STIX, MAEC, etc.
    • The implications of this are as follows:
      • CybOX would need to have some default container for use in instances (e.g., the “CybOX Package”)
      • Observation would most likely need to be defined in CybOX, as otherwise CybOX would just be sharing Objects and Actions with no context
        • Related entities such as those that deal with information source (the tool(s) that produced the observation) would similarly need to be defined as part of CybOX
      • CybOX may need to support data markings and versioning, so that they can be applied to data shared in a “CybOX Package”
      • CybOX could be produced/ingested by tools without needing STIX, MAEC, etc.
  • By “set of types”, we mean that CybOX would only define the types (i.e. Classes) around Objects and Actions, but the context and usage for these types would be defined by the languages that use CybOX
    • The implications of this are as follows:
      • CybOX would define a smaller set of entities
        • No need for any container entities such as the CybOX Package
      • In STIX, the Observation would define the semantics around observations of CybOX Objects and potentially Actions
      • In MAEC, CybOX Objects and Actions would be used to define the semantics around malware behavior
      • Users of CybOX could add data markings, versioning, and any other properties to CybOX entities as they see fit, but these properties would not have to be defined natively in CybOX
I think ultimately the question posed to the TC is, do we see a need for the ability to produce and consume standalone CybOX instances? E.g., for use by sensors or other tools that could produce instances of CybOX data? Or should CybOX instead be defined as a common set of data models that are wrapped and used by other languages for a standard representation of such data?

Regards,
Ivan

From: <cti-cybox@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Thursday, April 7, 2016 at 12:55 PM
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Objects/Relationships

That matches my current thinking as well. It will be interesting to see what everyone else thinks :)

BTW feel free to comment on the GitHub Gist JSON Examples [1] directly. I can then roll the comments back into the main document or just create a new document around examples (most likely).


Regards,
Ivan

From: Bret Jordan <bret.jordan@bluecoat.com>
Date: Thursday, April 7, 2016 at 10:16 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Objects/Relationships

My vote....

Q1) Should CybOX define a set of top-level objects (TLOs) and be capable of being used in a standalone capacity? Or should it just define a set of types that are used in languages that incorporate CybOX?

No, CybOX should not be a standalone thing.  It should be used by higher level languages.  


Q2) Should CybOX Objects be defined using a relationship-driven approach, or one based on embedded Objects?

This needs to be done on a case by case basis.  There might be some cases where it makes sense, but in turn there will be some where it will not make sense at all.   There needs to be a good middle ground.  


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." 

On Apr 7, 2016, at 09:44, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

We’ve put together a writeup on the questions surrounding CybOX Object and Relationships that stemmed from the CTI Common discussion (I’ve also attached a PDF copy for those who can’t access Google docs):


Fundamentally, the questions that this is trying to address are:
  • Should CybOX define a set of top-level objects (TLOs) and be capable of being used in a standalone capacity? Or should it just define a set of types that are used in languages that incorporate CybOX?
  • Should CybOX Objects be defined using a relationship-driven approach, or one based on embedded Objects?
Feel free to add any comments directly to the Google doc, or to this email thread. This is likely to be one of the main topics of discussion for next Thursday’s CybOX working session call.

Regards,
Ivan
<CybOXObjectsRelationships.pdf>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]