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.
+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..
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
How about we take two of the idioms on the
stixproject.github.io site?
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)
- Any others people are interest (PMML, Thrift, ProtoBuf, etc)
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.