cti-stix — archive

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

From: John Wunder
To: [email protected]
Date: Tue, 28 Jul 2015 13:06:00 -0000

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: Make relationships top level constructs (for STIX, CybOX) Consider different transport mechanisms (for TAXII) Consider different serialization formats (for STIX, TAXII, CybOX) Consider approach to Observable patterns/instances (CybOX) ???? 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. John From: < [email protected] > on behalf of Mark Davidson Date: Tuesday, July 28, 2015 at 8:22 AM To: "Jane Ginn - [email protected] ", Terry MacDonald, " [email protected] ", " [email protected] " Cc: " [email protected] ", " [email protected] " Subject: [cti-taxii] RE: [cti-stix] Re: [cti-taxii] Fwd: Proposal - Allow a client to request an object based on its ID 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: [email protected] [ mailto:[email protected] ] On Behalf Of Jane Ginn - [email protected] Sent: Tuesday, July 28, 2015 12:58 AM To: Terry MacDonald < [email protected] >; [email protected] ; [email protected] 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. [email protected]