STIX Interoperability Allan Thomson – LookingGlass Jason Keirstead – IBM Rev 2

Agenda Charter Review Proposed Plan Radar Items Actions

Group Charter The Interoperability SC will help guide adherence to CTI TC-promulgated standards and interoperability between CTI TC standards-based implementations, while encouraging standards maturity throughout the industry. The SC will develop parameters and processes to allow CTI TC members to test/ validate, and where possible measure the maturity of another organization’s implementation. Testing parameters and processes should be straight-forward and objective to provide clear confirmation that minimum standards' requirements have been achieved. Initially, in regard to maturity measurement efforts, the SC will develop guidelines to support a more qualitative review of an implementation. In addition, the SC will identify opportunities and approaches to promoting interoperability with externally-defined cyber threat intelligence standards and frameworks.

Questions Q1: Do you agree with the charter as defined? Strawpoll: (Yes - 20 ; No - 0 ; Unsure/Abstain - 3 ) Q2: Any changes we should adopt? Change “The SC will develop parameters and processes to allow CTI TC members to test/ validate, and where possible measure the maturity of another organization’s implementation” to “The SC will define parameters and processes to enable testing and validation of an implementation”

Proposed Plan Define per release target framework – THIS MEETING Agree on concrete next steps – THIS MEETING POST MEETING Define use cases Define core test specification Define optional test specifications

Proposed Group Targets – Every STIX Release Baseline Target: SPECIFICATIONS Have defined & community approved test specification for feature/profile-based compliance 1 quarter after every release of STIX 2.x Include Good/bad STIX content and use that content for unit tests to test spec compliance Test specification will be driven based on defined 1 or more use cases for the features in that version of STIX Strawpoll: (Yes - 20; No - 0; Unsure/Abstain - 2) Additional Target: Implementation Guide Help industry define/implement products ‘correctly’ Strawpoll: (Yes - ; No - ; Unsure/Abstain - ) Stretch Target: SCRIPTS & TOOLS Have defined/approved publicly available test scripts and tools to allow organizations to self- certify, coincident or 1 month after with the release of the test specification Strawpoll: (Yes - ; No - 1; Unsure/Abstain - )

Proposed Target 2.0 Test Specification 1) Test specification for core mandatory features that all producers and consumers must support Will be used as the base criteria for all use case driven testing If a STIX 2.0 capability does not pass this base capability then they are not compliant to the core feature set 2) Test specifications for each agreed optional use case May be separate document or sub-section on a single test specification doc Specification content will include STIX Cyber Observables and all relevant content necessary to have a working interoperability between products at a feature level NOT just a JSON parser compatibility

Example Use Cases 1. SHARE INDICATORS VIA FILE Vendor A product has a set of indicators of IP and/or Domains that are malicious and the organization using the product wants to share those indicators (IP/Domain) with other organizations running Vendor B product. The organization running Vendor A product wishes to export the indicators to a file and email the file to their analyst peers who are running Vendor B product who can ingest the file into their product to show the indicators and any specific vendor unique views 2. EXPORTING INDICATORS VIA TAXII INBOX Vendor A product has a set of indicators of IP and/or Domains that are malicious and the organization using the product wants to share those indicators (IP/Domain) with other organizations running Vendor B product.. The organization running Vendor A product wishes to export the indicators to the other product via TAXII. Vendor A product knows the URL/IP for the TAXII server of the other organization and chooses that vendors TAXII server from a selector when exporting the indicators. The analyst peers running the other Vendor B product are able to view those shared indicators received via TAXII in Vendor B’s product UI. 3. INDICATOR SHARING VIA TAXII FEED The organization running Vendor A product allows other products to subscribe to these indicators using TAXII. Vendor B product knows the URL/IP for the TAXII server of Vendor A’s TAXII endpoint. The analyst peers running the other Vendor B product are able to view ingest shared indicators received via TAXII in Vendor B’s product UI. 4. INDICATOR DATA FEED SHARING Vendor A has a threat intelligence data feed supporting STIX based indicators that can be ingested into Vendor B’s product to visualize, analyze….etc. The data feed represents Vendor A’s sensor and collection capabilities across a specific vertical market of threat collection that they sell to customers to utilize in their threat analysis or operational environments. Vendor A supports data feed sharing via proprietary HTTP RESTful interface. NOTE: May need to be TAXII server for the data feed but not sure what feed vendors that are participating support TAXII for their data versus a HTTP proprietary interface.

Radar Items Plugfest schedule and events Very useful way to get high bandwidth engagement on interop issues between products Goal to schedule them every 6-12 months at least based on latest STIX versions Discuss responsibilities of InterOp group on verification of self- certification results and display of approved tools/products on OASIS site

Call to Action Q: Who is willing to participate in creation of use case document? <list of names> Q: Who wants to participate in creation of core test specification? Q: Who wants to participate in creation of optional test specifications?