I definitely agree Mark - One concern I have as we start to look at adding a few new objects in 2.0 is that STIX is beginning to look like a large list of “things”
with no real purpose of cohesion.
I believe we can improve this situation with the use of “packages” (not to be confused with the Package object). By looking at what we are trying to accomplish
from a top-down perspective, these packages *should* start to materialize. Or… we will find things that don’t belong and can be eliminated.
*side note – OpenTPX does this it seems, and if nothing else, it makes the spec MUCH easier to digest for newbies.
My personal challenge is that I don’t know what I would make the STIX packages.
·
Certainly DICTIONARY would be a package (at least it seems clear to me), with Observable and Indicator most likely going in there, but then what?
·
Is Incident, and Sighting part of an EVENT package? (I never thought of this before, but there might be some overlap between these 2 objects, no?)
·
Once we get to Campaign, TTP, ExploitTarget, and CourseOfAction, we seem to enter in a higher level of abstraction and analysis that I’m not sure people
are even doing much with currently. Perhaps they all go into an ANALYSIS package?
My lack of CTI expertise is starting to come out here, so if anyone is interested in exploring this more, I’m sure they will also have a better feel for what the
packages should be. If the interest isn’t there, so be it, but I feel there could be payoffs going forward if we bite this off now. It could help us analyze proposals for other new objects to measure fit in our packages (and therefore cohesion to the STIX
“mission”)
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Davidson II, Mark S
Sent: Monday, October 26, 2015 8:53 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] STIX 2.0 Architecture - Relationships, Sightings, and Targeting
As I followed the list traffic over the past week or so, I couldn’t help but feel like we’re at a level of abstraction lower than we need to be. Consider the very good IndicatorType / Vocabulary discussion – I spent some time thinking about
how we’ll keep track of the discussion’s outcome and the many similarly scoped discussions (See: 154 open issues [1]) that will occur as we work toward the future. I think there’s such a volume of interdependent factors that we’ll have a hard time deciding
any particular issue without also consider all other open issues – something that feels a bit insurmountable given the sheer volume of topics. (Note: This is in the context of STIX 2.0 - I feel that updating the vocab for STIX 1.2.1 is a separate discussion
and I am not trying to make a statement about it).
With that in mind, I challenged myself to come up with a higher level topic that might help us move forward. I don’t particularly care if my topic gets picked or not, but I do think we need to be a level of abstraction higher to start.
IMO, a good topic for discussion would be: What should the STIX 2.0 Architecture look like?
The architecture was touched on in a few of the earlier cti-stix discussions (Relationships, Sightings, Targeting), which IMO makes the architecture a good candidate for early discussion. I’ve thrown together a notional diagram containing
STIX 1.2 components [2] and the top level objects that have been discussed so far (please let me know if I missed yours!).
My hope is that by raising this topic we can identify dependencies, preconditions, and differences of opinion. If we need to know more about relationships before we can move forward – what are those things? As with any early stage discussion,
there will be open items that can only be resolved later on; my hope is that we can reach a common starting point.
Thank you.
-Mark
P.S. In terms of following the process stated in STIX SC call, please consider this message my vote for the STIX architecture being the highest priority topic to work through.
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.