| I can agree with all of this... The one clarifying point is that a CybOX relationship != a STIX relationship. Those are two different things. The STIX relationship will have a lot of extra baggage that CybOX will not want or need.
Thanks,
Bret Bret Jordan CISSPDirector 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."
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:
- 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.
- 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.
Regards,
Ivan
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
<graycol.gif>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
_____________________________
<graycol.gif>
|