All, I uploaded the notes from our recent face-to-face here:
https://www.oasis-open.org/committees/document.php?document_id=64007&wg_abbrev=cti . Thanks again to everyone who attended or dialed in. For those of you that weren’t able to make it, the notes are a pretty concise summary so I’d suggest just glancing through to see what all we talked about. I’m also pasting the full text below so that they’re searchable via e-mail. Thank you, John -- Sept 2018 CTI TC F2F Summary Notes Session 1: STIX 2.1 Review The majority of the discussion centered around how we develop and validate implementations for the newly added features. Summary and Consensus No real hard and fast rules were agreed to. The mood of the room was that we should communicate well, be reasonable, and evaluate things as a TC. There was a suggestion that even if code can't be made available, data should be made available and perhaps even posted to Github. Session 2: Infrastructure and Observables There was an extensive discussion of the various options, where we were able to narrow things down to a relatively small set of options. Observables options that the F2F participants felt were reasonable Summary and Consensus Many options were scoped out as not ideal based on the feedback provided by the F2F participants (those in the room and on the phone). The image above (and posted to Slack) captures design decisions and pros/cons. Option 1': 9 votes Option 3: 0 votes Option 7: 5 votes Path forward is to attempt use case modeling via at least Option 1' and 7, and continue the discussion via the broader TC. A use case document has been created in Google Docs here:
https://docs.google.com/document/d/1puPuKVWNSelrWH05yu9It99OuqQGdYo_Et0nmZKAZz8/edit . Session 3: TAXII Topics discussed were pagination, adding a limit parameter, adding URL collection ID aliases, and the STIX vs. TAXII media types. Summary and Consensus Pagination: We discussed how pagination currently works in TAXII and there was no desire expressed at the F2F to revisit pagination and do anything beyond what we already have. However, if a use-case is shown going forward, where what we have does not work, we will revisit. Add "limit": We will be looking to add a URL parameter of "limit" to allow the client to tell the server how many records to send. There were no objections voiced during the F2F. Add URL aliasing for collection IDs: We discussed how to add a URL alias for collection IDs and advertise that via the collection resource. There were no objections voiced during the F2F. Media types: There were no objections to the rough consensus we have had on previous calls. The current plan is to create a TAXII envelope to address the problems outlined by others and what has been seen in production. This solution will require that we add a URL parameter for identifying the versions of STIX that one wants to query for. One comment that the media type confusion is technically valid per the HTTP RFC. Session 4: Malware and Patterning Grab Bag The discussion touched on many topics, but most back-and-forth conversation happened around a few key topics: third-party patterning languages, how much patterning should do, and how malware results should be structured. Other topics that were touched on include actions, decomposing malware functionality into micro-attack patterns, and how malware relates to other objects. Summary and Consensus Future Observables No Consensus: which new Observables/extensions should be included in the short-term (STIX 2.1) or long-term (STIX 2.2+) Third-Party Patterning Languages Consensus: we should capture some other types of patterns Consensus: Snort and Yara are probably worth capturing No Consensus: Whether any further types of languages (e.g. Sigma) should be supported Consensus: Interoperability should not require that tools support Snort, Yara, or other patterning languages. No Consensus: The exact method of capturing other patterns was touched on but no strong consensus. Options include: A separate object (some support) Separate properties on the indicator SDO (some support) Overloading the pattern property on the indicator SDO (no support) Scope of patterning Consensus: We should not try to capture a superset of all other patterning languages Consensus: We should aim for behavioral analytics Consensus: It is probably worth separating out support for analytic searches fromthe more baseline IOC capabilities, somehow (no real discussion of how). Malware Consensus: We want to have an external malware analysis object, separate from the malware SDO, that both the original producer and third-parties could leverage. Consensus: You need to be able to update malware analysis objects Consensus: You can have a key/value-based approach to capture actions before we have actions Consensus: Option 1' is probably better for this use case No consensus: Do we want a summary object to capture high-level analysis results? No consensus: Do we need to support actions before doing malware? Sessions 5 and 7: SEPs The discussion of SEPs was broken up in order to make sure the right people were available. Overall the discussion focused on the mechanism to implement SEPs and figuring out which use cases were supported and how it would work for each one. SEP Consensus for Internal/External Repos Summary and Consensus Consensus: the proposed approach (picture above) is reasonable No consensus: how SEP properties get included in an object, and how they get named One approach was to leverage an extensions dictionary (from cyber observables), name properties as an extension, and include them that way. No vote, but this had more support but not enough to call it consensus. Another approach was to leverage custom properties and define which custom properties belong to which extension. Session 6: Minor Issue Triage Notes are captured in the github issue tracker for this session:
https://github.com/oasis-tcs/cti-stix2/issues Issues discussed include: 34, 23, 64, 65, 94, 96, 76 (closed), 17 (closed), 12 (closed).