[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] CybOX Objects/Relationships
That seems reasonable to me – I also think it doesn’t make sense that CybOX Objects would be globally unique. Therefore, what if we say something like:
Also, as far as the standalone vs. TLOs issue, it appears that there is rough consensus on having CybOX serve as a collection of types that are used elsewhere, rather than as a standalone language. Are there any other thoughts on this matter?
Regards,
Ivan
From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, April 13, 2016 at 6:08 AM To: John Wunder <jwunder@mitre.org> Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org> Subject: Re: [cti-cybox] CybOX Objects/Relationships OK - that makes sense to me if we can figure that out. 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 ---
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] 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 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]