All,
As I consider the discussion on these lists, it strikes me that there is probably a fundamental dependency on a decision (or decisions) that have yet to be identified
on-list. For instance, I like Terry’s suggestion that “Query by ID” be specifically called out as a use case that we solve. However, I have a hard time thinking through any potential solution(s) because I get stuck on where it “fits” – is it TAXII 2.0 / STIX
2.0, TAXII 1.x / STIX 1.x, or something else? And if “Query by ID” (for instance) fits best in STIX 2.x / TAXII 2.x, what direction are those efforts headed in? They are blank slates, at least in terms of this group’s shared understanding – I’m sure plenty
of people have good ideas that just need to be socialized.
The heart of what I’m saying is this: I have a hard time conceptualizing the discussions on this list without knowing the direction of STIX/TAXII/CybOX. Therefore,
at least for me, the version of STIX/TAXII/CybOX we are working on, plus the direction of that particular version, seems to be the fundamental discussion we ought to be having.
It’s no secret that we all have fundamental changes we’d like to see in a major revision of STIX/TAXII/CybOX, but we do not – as a group – have a consensus direction
that we are driving toward. Without that consensus direction, it will be difficult to have a productive discussion about particular features or use cases, because any decision might end up being fundamentally altered by higher level decisions made later on.
So let’s make the higher level decisions first.
I’ll close by encouraging the group to think at a very high level about STIX, TAXII, and CybOX. Where should these efforts be headed? Are fundamental changes
indeed necessary, or should we instead focus on incremental progress? Or, to take a slightly different perspective, pick your favorite proposal and attempt to think through a solution; what dependencies does that solution have and what assumptions do you make?
Those dependencies and assumptions are the higher level issues the group should be thinking about.
Thank you.
-Mark
PS – I’ve added the CybOX and CTI lists because I think my message is applicable to both. My apologies for those of you that might receive this email in quadruplicate.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jane Ginn - jg@ctin.us
Sent: Tuesday, July 28, 2015 12:58 AM
To: Terry MacDonald <terry.macdonald@threatloop.com>; cti-taxii@lists.oasis-open.org; cti-stix@lists.oasis-open.org
Subject: [cti-stix] Re: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID
So Terry:
How would this Use Case deal with a 'Confidence' rating... or a 'Sighting' ... and..., as you have probably noted... there is some discussion of having the 'Report' object be devoid of data... What would be the impact there with
respect to this 'Relationship' object you are proposing?
Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us
-------- Original Message --------
From: Terry MacDonald <terry.macdonald@threatloop.com>
Sent: Monday, July 27, 2015 09:01 PM
To:
cti-taxii@lists.oasis-open.org,cti-stix@lists.oasis-open.org
Subject: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID
Hi All,
I'd like to propose that TAXII and STIX querying abilities are reviewed and checked to make sure that a client is able to request an object based on its ID, and be returned it (if it is authorised by the producer).
This must directly support proposal to allow a top-level relationship object. It would mean that if a user received just the relationship object they would know that there was a relationship with an object with a certain ID, but they wouldn't necessarily have
the object itself. This functionality would allow a client to then subsequently request which ever data nodes' it wishes at either end of the relationship.
Note: This has the knock on effect of forcing the ID namespace to be tied back to the organisations domain name. If we did that, and mandated what services need to be provided by TAXII
at what location, then it would be easy for a client to know how to request get from the relationship to actually contacting a TAXII server to request the actual object from the original source.
This would also work if an organisation wanted to be anonymous. It would need to provide the details through a 'broker' service which would translate the original ID sent by the anonymous
producer to an ID within the broker's namespace. Then if any external consumers wanted more information then they would contact the broker, who would then forward that request to the original consumer. If the original producer says yes they can have it, then
the broker says yes, and the consumer gets the information. Its a win/win.
I am aware that TAXII/STIX can do this already, but this is really about making sure that this use case is noted and supported.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
M: +61-407-203-026
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of
my employers.