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: Notes from September 2018 CTI TC Face-To-Face



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,





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


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