OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-taxii] RE: [cti-stix] Re: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID

I agree, Mark. It's hard to keep track of what all is going on with so many issues, many of which are impacted by other issues (making Sighting a top level object is impacted by top-level relationships and CybOX patterning, and this request proposal is impacted by the different TAXII operating models that might be considered, plus others).

IMO it would be nice to come up with a set of high-level changes that can be addressed first, before talking about everything else. A notional list I came up with off the top of my head is:
  1. Make relationships top level constructs (for STIX, CybOX)
  2. Consider different transport mechanisms (for TAXII)
  3. Consider different serialization formats (for STIX, TAXII, CybOX)
  4. Consider approach to Observable patterns/instances (CybOX)
  5. ????
I know simplifying the data model was a big priority but that doesn't need to happen all at once. Adding a top-level sighting object really only impacts Indicator and Observable so can probably wait. Even the serialization formats may not be a show-stopper, assuming whatever is considered is able to represent the required data.

This specific approach would also be impacted by switching from QName identifiers (per https://github.com/STIXProject/schemas/issues/301) too, but I wouldn't really consider that an overarching issue.


From: <cti-taxii@lists.oasis-open.org> on behalf of Mark Davidson
Date: Tuesday, July 28, 2015 at 8:22 AM
To: "Jane Ginn - jg@ctin.us", Terry MacDonald, "cti-taxii@lists.oasis-open.org", "cti-stix@lists.oasis-open.org"
Cc: "cti-cybox@lists.oasis-open.org", "cti@lists.oasis-open.org"
Subject: [cti-taxii] RE: [cti-stix] Re: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID



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.



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.

-------- 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.



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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]