[+1]
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jerome Athias
Sent: Saturday, 24 October 2015 5:02 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>
Cc: Patrick Maroney <Pmaroney@specere.org>; Sean D. Barnum <sbarnum@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: [cti-stix] Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
To fix an issue like this it's better to identify the root cause. And yes, even if it's adding some 'relative complexity', I think a parent/childs approach a la CWE/CAPEC would help
On Friday, 23 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
We just need a way to guide developers so that when they write implementations, those implementations do not go POOF when they get something they did not expect. We can not assume or rely on the fact that a schema exists somewhere in the
wild and that some how software will be able to download it and automatically write code to support it.
When I talk about simplicity, as I have said many times before, it does not mean reducing expressiveness.
<throwing spaghetti at the wall to see what sticks>
Perhaps this issue could be solved by a layered approach.....
Step 1: Greatly increase the default vocabulary, removing weirdness and things that are duplicate in nature. Try and get the default vocabulary to a 60/40 or 70/30 rule. It would also be really nice if the terms were backed by a numerical
element. String matching in code in notoriously inefficient.
Step 2: Provide a secondary entry point for an additional vocabulary for those groups that want or need to define their own. We would obviously need an entry point in to the controlled vocabulary that can be a "fall back", something that
is a lot higher up the food chain.
By doing something like this, software that can only work with the default vocabulary can skip or throw away things it does not understand and have a fall back to something that is "close enough" for what they need. In the second example
below, the "sub_type" would be options and parsers could easily throw it away or skip it. In fact most JSON parsers today naturally just skip things that do not map to a struct.
"type": "X-RAT-Downloader"
</spaghetti runs down the wall and pools in a gob of mess on the floor>
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."
re: "The only way I can see that STIX could try to overcome this issue is providing structures enabling the producer to transmit their full vocab definition as part of the
content itself. "
|