[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
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.
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 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:
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 _____________________________ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]