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: Re: [cti] Open Question to the CTI Community




Sean,


Well said...

"

  • CybOX as the medical domain language (the way doctors talk about medical about medical conditions, examinations, diagnostic symptoms, etc.)
  • STIX as English (can express a lot of different kinds of ideas and information including things like medical information but also other stuff)

"


- this 'analogy' better fits with my understanding and usage to convert non-STIX/CybOX sources to native (standards based) STIX/CybOX.


As well as starting to embrace "test mechanism" to handle native format (to encapsulate other standards) such as SNORT and YARA.



Michael Pepin
Engineer
SOLTRA | An FS-ISAC & DTCC Company
michael@soltra.com

www.soltra.com




From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Barnum, Sean D. <sbarnum@mitre.org>
Sent: Wednesday, August 19, 2015 10:46 AM
To: Jacobsen, Jasen W.; cti@lists.oasis-open.org
Subject: Re: [cti] Open Question to the CTI Community
 
I would very much agree with Jasen here.

Trying to stay as simple as possible, I would characterize it as:
  • CybOX is a language (semantics and structure) for expressing information about cyber observables (instances or patterns)
  • STIX is a language (semantics and structure) for expressing information about cyber threat information (this includes cyber observables as CybOX as well as a lot of other things)
  • Specific binding implementations (XML, JSON, etc), as Adam characterized in this thread, structure the deliverable form of CybOX or STIX content
  • TAXII is a framework supporting CTI content (primarily STIX but necessarily limited to STIX) to be advertised, discovered, and exchanged between different parties, systems and services
  • Differing implementations of CTI-relevant systems and services focused on different objectives and priorities can leverage all of the above for interoperable consistency but may differ on supported capabilities and specific implementation details (there is not any one “right” way to implement a CTI-relevant system/service that meets all needs for all use cases)

To use an analogy, think of:
  • CybOX as the medical domain language (the way doctors talk about medical about medical conditions, examinations, diagnostic symptoms, etc.)
  • STIX as English (can express a lot of different kinds of ideas and information including things like medical information but also other stuff)
  • Specific binding implementations as things like verbal speech, handwritten text, digital text, etc. (they can all be english but the particularly appropriate form is driven by the needs of the use case)
  • TAXII as the logistic framework that lets different parties advertise and discover what information they may have and then exchange as desired whether that be via phone, face-to-face communication, physical media, digital media, etc
  • The details of what phone you use, where you meet face-to-face, whether you use paper stationary or a cassette tape, or whether you use email or SMS, as well as what you do with the information itself are not dictated by TAXII. Those decisions are driven by local context.


I would think (hope) there is less confusion here on STIX/CybOX being languages for expressing the relevant information.
I think there is likely some confusion in some parts of the community on the distinction between the STIX/CybOX languages and any specific binding implementations but we hope to address that confusion soon with the publication of the initial OASIS versions of the STIX language specs along with the initial STIX XML Binding spec as an exemplar.
I think there is more confusion around exactly what TAXII should be and where the scoping boundary lies between being a framework to support exchange of information and constraining or implementing specific exchange use cases. I am glad to see this being discussed and would encourage the entire TC community to engage in the discussion as the effects of such decisions have potential implications beyond just TAXII.

Sean Barnum

From: <cti@lists.oasis-open.org> on behalf of "Jacobsen, Jasen W." <jasenj1@mitre.org>
Date: Wednesday, August 19, 2015 at 9:30 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Open Question to the CTI Community

As one who has been part of implementing the TAXII Java libraries let me throw a few cents on the table.

"(2) All of these combined somehow form an information repository (how things are racked, stacked, and found in the warehouse) and TAXII is the "Amazon"."

To me, TAXII is the interface into the "Amazon". It is the API, not the implementation. 
TAXII tries to solve two use cases:
  1. There needs to be CTI content flowing around between organizations. How do people define the streams that information flows through (publish), and how do they tap into the streams (subscribe)?
  2. There are repositories of CTI content. How do people find and get delivered that content? (query)
So TAXII is both the FedEx store/post office, and the library reference desk. Implementors determine what kind of trucks they want to use, and how to build their library, but TAXII provides a common entry point.

- Jasen.


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