RE: [cti-users] Re: [cti-stix] [cti-users] MTI Binding

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

"STIX is several thousand terms and may be used for very different use cases that use different viewpoints of the data with different root structures."

This premise is untrue. Or at least, at the release of STIX 2.0, this has to be untrue - otherwise we have fundamentally failed in creating a data interchange standard. And I believe that this incongruency is at the heart of this whole discussion.

The whole point of data interchange standards is to explicitly avoid this premise. It is so that when I create a message such as "<foofarah><name>foo</name><id>bar</id></foofarah>", **I can send that message without any other context to any recipient on the planet** - and the recipient will be able to understand it, because they do not have to guess as to what "name", or "id" mean - because they know that I am following the "Fooferah 1.0" standard, which explicitly defines what is present in those fields.


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Cory Casanave ---2015/10/05 09:04:26 PM---Sean, I very much agree. A lot of the “its simple” view of JSON or even early XML is based on its us

From: Cory Casanave <cory-c@modeldriven.com>
To: "Barnum, Sean D." <sbarnum@mitre.org>, Terry MacDonald <terry.macdonald@gmail.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Date: 2015/10/05 09:04 PM
Subject: RE: [cti-users] Re: [cti-stix] [cti-users] MTI Binding
Sent by: <cti-users@lists.oasis-open.org>

---

Sean,
I very much agree. A lot of the “its simple” view of JSON or even early XML is based on its use for single and highly structured interactions between endpoints controlled by the same authority (My server talking to my android application).
 
STIX is several thousand terms and may be used for very different use cases that use different viewpoints of the data with different root structures. On top of this is the need for extensibility and flexibility. This is simply the reality of the domain and the scope of STIX. The bad news is that regardless of the serialization format, schema language, model, language, etc. It is somewhat complex – that is the real and necessary complexity. So I am concerned that the “Pure JSON will be simple” view will end in some disappointment.  Note that the same concerns of complexity are levied against NIEM, another large XML schema based data sharing standard.
 
The good news is we can make it BETTER and as simple as is practical! When some of these requirements are folded into XML schema, it adds complexity – so perhaps some of these other choices REDUCE complexity even if they require some new learning. Where we can add semantic precision software can handle some of the load. If we have a way to define fine-tuned “profiles”, these may be much simpler for their more limited purpose. We can also make the models easier to understand for us humans with graphical models linked to semantic definitions.
 
I am copying the following list from Shawn Riley to show the variety of information formats and viewpoints that we are trying to fit together under one, many faceted, schema:
 
Below is some of the typical cybersecurity data and information users/analysts/scientists have to organize into some type of body of knowledge so they understand their cybersecurity ecosystem. If the technology can’t understanding the meaning of the data then it’s the humans who have to understand it and “connect the dots”.  
 
Configuration/Anomaly Reporting - Infrastructure Information - Risk Posture - Anomalies
 
Knowledge of Threat Actors - Threat Actor Infrastructure - Threat Actor Personas - Collected Threat Actor Indicators - Threat Actor Attribution - Trend Analysis - Victim Information
 
Incident Awareness - Incident Information - Incident Data - Infrastructure Impact and Effects - Investigations/cases - Alerting Indicators - Victim Information
 
Indications and Warnings - Events and Alerts - Tipping and Cueing - Warnings - Impact assessments - Potential Indicators
 
Vulnerability Knowledge - Vulnerabilities - Exploits - Potential Victim Information
 
Mitigation Strategies - Coordinated Action Plans - Courses of Action - Understanding of Achievable Mitigation Effects
 
Mitigation Actions and Responses - Computer Network Defense Situational Awareness - Action Tasking and Status - Effectiveness Reporting - After Action Reporting and Lessons Learned
 
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Monday, October 05, 2015 9:18 AM
To: Terry MacDonald; Jordan, Bret
Cc: cti-users@lists.oasis-open.org; cti-stix@lists.oasis-open.org; Wunder, John A.
Subject: [cti-stix] Re: [cti-users] Re: [cti-stix] [cti-users] MTI Binding
 
I think that using these simple idioms would be great for folks to see roughly what the different forms look like but I do not think they would be sufficient for comparing size and complexity as a whole.
These are VERY simple example structures. More complex examples would likely differ from these simple ones in how each representation tackle size and complexity.
 
sean
 
From: <cti-users@lists.oasis-open.org> on behalf of Terry MacDonald
Date: Friday, October 2, 2015 at 5:51 PM
To: "Jordan, Bret"
Cc: "cti-users@lists.oasis-open.org", "cti-stix@lists.oasis-open.org", John Wunder
Subject: Re: [cti-users] Re: [cti-stix] [cti-users] MTI Binding

+1. Is a nice idea as we can see a size and complexity comparison. Is there any chance each person can document the process that the generation took? I'm thinking it could be useful to see how complicated the toolchain for developing each type of output is.

Cheers
Terry MacDonald
On 3 Oct 2015 6:33 am, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
I think this is a great idea..

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Oct 2, 2015, at 14:08, Wunder, John A. <jwunder@mitre.org> wrote:

How about we take two of the idioms on the stixproject.github.io site?

- http://stixproject.github.io/documentation/idioms/c2-indicator/
- http://stixproject.github.io/documentation/idioms/simple-incident/

Thanks for helping out. I think it would be nice to see these as:

- Current STIX XML (Done already)
- Simplified XML (TBD, maybe if the JSON one is quick I’ll do this too)
- JSON/JSON-Schema (Wunder)
- JSON-LD (Casanave)
- Any others people are interest (PMML, Thrift, ProtoBuf, etc)

John

On Oct 2, 2015, at 11:50 AM, Cory Casanave <cory-c@modeldriven.com> wrote:

Re: Examples.
Pick your examples, I can help out. Would prefer to baseline off of the same schema subset & example data, current STIX is fine to define the examples. I suggest at least one that is very simple “pure hierarchical data” and at least one with some related entities.
-Cory