Re: [cti-cybox] CybOX Objects/Relationships

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

OK - that makes sense to me if we can figure that out.

So, Cybox object IDs are not GUIDs, they are only unique within the containing observation or other container.

-
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


"Wunder, John A." ---04/13/2016 08:57:24 AM---What if CybOX relationships only valid within the context of a given CybOX container? In other words

From: "Wunder, John A." <jwunder@mitre.org>
To: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 04/13/2016 08:57 AM
Subject: Re: [cti-cybox] CybOX Objects/Relationships
Sent by: <cti-cybox@lists.oasis-open.org>

---

What if CybOX relationships only valid within the context of a given CybOX container? In other words, all of the objects in a MAEC analysis package have local IDs and local relationships, but cannot be related to objects in a different analysis package. Same with a STIX Observation…so Dean’s use case is possible, but it doesn’t require that CybOX objects be TLOs. This seems like a pretty good tradeoff between global relationships (which do indeed get tricky if they’re embedded in versionable STIX or MAEC TLOs) and no relationships.

John

From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, April 13, 2016 at 6:24 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>, Patrick Maroney <Pmaroney@Specere.org>, Terry MacDonald <terry.macdonald@cosive.com>, John-Mark Gurney <jmg@newcontext.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Objects/Relationships

Here is the big reason I am against relationships in cybox... you can't do them without IDs. 

As soon as we add IDs to cybox constructs, they are no longer immutable facts. What does a piece of cybox turn into at that point, because it's not a fact anymore, it's an instance. Can I revoke a chunk of cybox? Can I version a chunk of cybox? What does it mean to version or revoke an IP? Furthermore, if cybox facts now have IDs - why do we need an observation object at all? An observation's whole purpose in life was supposed to be to contain an instance of cybox... but if the cybox fact is itself now an object, why do we have observation?

Sent from IBM Verse

Kirillov, Ivan A. --- Re: [cti-cybox] CybOX Objects/Relationships ---

From:	"Kirillov, Ivan A." <ikirillov@mitre.org>
To:	"Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, "Jerome Athias" <athiasjerome@gmail.com>
Cc:	"Patrick Maroney" <Pmaroney@Specere.org>, "Terry MacDonald" <terry.macdonald@cosive.com>, "John-Mark Gurney" <jmg@newcontext.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, cti-cybox@lists.oasis-open.org
Date:	Tue, Apr 12, 2016 6:36 PM
Subject:	Re: [cti-cybox] CybOX Objects/Relationships

---

To be fair, CybOX 2.x did support relationships between Objects [1], the issue (IMO) was that they were far too numerous and weren’t implemented consistently. E.g., Email attachments were captured as references to File Objects, whereas files that contained other files (e.g., Zip archives) were implemented using the explicit relationship structure.

I understand the concern that there isn’t consensus on relationships, and so it may not make sense to implement them for the 3.0 MVP. However, as John mentioned, the way we design the data models around our CybOX Objects is fundamentally impacted by whether we support relationships or not. Thus, it would require a major revision of CybOX, including overhauling the majority of the CybOX Object data models, if we decided that we don’t wish to support relationships today and then decide to add them in a future release.

Also, I’m with Terry, Jerome, and Pat on the issue of relationships being a fundamental CybOX building block. I think our current thinking has been heavily influenced by the discussion around the Observation structure and use case, but it’s important to remember that CybOX is designed to support a wide range of use cases. I would venture to say that more complex types of observations, such as those performed in digital forensics, require the ability to construct a graph between the observed “nodes”; this can only really achieved with relationships. Besides this:

1. If we don’t support relationships and instead replace them with embedded fields/objects, there is the assumption that we understand ALL of the possible relationships between the set of CybOX Objects. I would say that this is a dangerous assumption to make, and accordingly it significantly limits how CybOX Objects can be used. It also means that anytime we want to add the ability to relate an Object to another, we must release a new (minor) version of an Object.
2. Semantically, relationships can allow for more accurate characterization, especially when referring to “ethereal” relationships such as those around hostname/domain name resolution. IMO, it is more accurate to state that a domain resolved to an IP address as a relationship rather than as an intrinsic property of the domain name.

Therefore, I don’t see why we can’t simplify the CybOX Object model and also support relationships. IMO, I think it would make sense to use embedded Objects wherever possible, and limit the set of valid Object->Object relationships to those around “ethereal”/contextual relationships and also perhaps those around containers (Object->”contains”->Object). Also, it’s worth mentioning that if STIX doesn’t want to support relationships in Observations, it doesn’t have to. 
 
[1] http://cyboxproject.github.io/documentation/object-relationships/

Regards,
Ivan

From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, April 11, 2016 at 6:32 AM
To: Jerome Athias <athiasjerome@gmail.com>
Cc: Patrick Maroney <Pmaroney@Specere.org>, Terry MacDonald <terry.macdonald@cosive.com>, John-Mark Gurney <jmg@newcontext.com>, Ivan Kirillov <ikirillov@mitre.org>, Bret Jordan <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX Objects/Relationships

Pat/Jerome; As I mentioned, it is easily possible to come up with use cases for this. However, we can come up with use cases for almost any construct - including a large number of constructs that we have already decided are not required for MVP. I am simply questioning the need of this for MVP.

I would argue that since this capability never existed in STIX 1.X, it is not needed for MVP.

To channel Bret... STIX 1.X has been around for years and there isn't a single product that implements the spec fully... I do not believe it should be a goal to add constructs to cover every possible use case in the initial release, especially when there is no consensus in sight, and we therefore have ample opportunity to get it wrong.

It is much easier to add cybox relationships in a future release than to get rid of them because we find out screwed them up.

-
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


Jerome Athias ---04/10/2016 04:47:59 AM---I strongly concur with that. Also i would note that CTI should benefit users of various

From: Jerome Athias <athiasjerome@gmail.com>
To: Patrick Maroney <Pmaroney@specere.org>
Cc: Terry MacDonald <terry.macdonald@cosive.com>, Jason Keirstead/CanEast/IBM@IBMCA, John-Mark Gurney <jmg@newcontext.com>, "Ivan A. Kirillov" <ikirillov@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 04/10/2016 04:47 AM
Subject: Re: [cti-cybox] CybOX Objects/Relationships
Sent by: <cti-cybox@lists.oasis-open.org>

---

I strongly concur with that.
Also i would note that CTI should benefit users of various maturity/capability levels unless envisioned otherwise 

On Sunday, 10 April 2016, Patrick Maroney <Pmaroney@specere.org> wrote:

Re: "In most scenarios it wouldn't matter... I'll normally be looking for the malware, not the email it was sent in (which would be constantly morphing)"

This may indeed be a completely valid statement from a given vendor specific perspective.

Speaking from the perspective of the organizations actually dealing with 100s to 1,000s of targeted attacks/week: the root objective is to proactively detect and stop all variants of such attacks dead in their tracks at one's perimeter (not at the exploitation phase where the malware is in it's final delivery/execution state). Sharing all of the details of such attacks allows us to collectively develop the signatures necessary to meet this objective.

Understanding the characteristics of attack packages, containerization, targeting patterns, etc. and *how* they "morph" over time is much more valuable for predictive analytics, pro-active perimeter defense, and attacker attribution.. The same principles also apply to the malware payloads of course, but these can also be constantly morphing.

This type of intelligence sharing and analysis is how one develops highly effective methods of detecting and stopping new campaigns (and attack packages containing new 0Days).


Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

_____________________________