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

2. Agenda
Charter Review
Proposed Plan
Radar Items
Actions

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

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

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

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

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

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

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

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