[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
|
Comments inline
From: <cti-users@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, October 22, 2015 at 2:15 PM To: Aharon Chernin <achernin@soltra.com> Cc: John Wunder <jwunder@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Palmer, Cliff A. (NE)" <Cliff.Palmer@gd-ms.com>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org> Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Extensibility and the whole xsi-type concept only works if you can guarantee that every implementer of every product and device will "fully" implement it.
If not, then you have things breaking all over the place.
[sean]I would argue that this is fundamentally not true. The entire extensibility approach built into the language is designed such that every implementer can decide which profile of the language they wish to support.
This may mean that they support particular extensions or that they support no extensions at all other than the default ones. Each extension is defined explicitly such that there is no ambiguity on what it is and implementers have a clear specification of what
structure they need to support if they choose to support that extension. If an implementer chooses not to implement certain (or any) extensions
they need to understand that by doing so they limit their ability to interoperate with other implementers who do implement them. Is it possible for every implementation to be fully interoperable for all information with every other implementation? No. I would
argue that this will never be possible because different implementations (CTI platform, analytic workbench, SIEM, malware analysis tool, digital forensic analysis tool, etc.) are focused at doing different things with different information. The key is that
they all deal with “cyber threat information” and effective cyber security involves use and integration/orchestration across them and their information. This is why it is important that STIX serve the purpose of an ontology/data-model across the domain serving
both localized tactical use cases as well as bridging strategic ones.
And our efforts of making sure we can accommodate every possible use-case, means, that in practical terms no one can actually communicate unless they are using the same software package (which is not realistic).
[sean]First, I would assert that we are certainly NOT "making sure we can accommodate every possible use-case”. Not even close. We are targeting the most common use cases for cyber threat information. That does not
mean only the most common use cases from a particular individuals perspective or usage scenarios but across the cyber security landscape. The terms esoteric and niche are often thrown around (not in this message but in others with the same tone and intent)
by some who wish to discount the validity or importance of use cases other then theirs. I would request that we avoid derogatory use of terms like these going forward and would further assert that none of the broad set of use cases currently listed on the
STIX use-cases wiki are esoteric or niche. They are ALL common use cases occurring as we speak and every day across a broad set of users in the cyber security domain. Ironically, I would say that the use cases on that list that are least common today are ones
that are more difficult without something like STIX (e.g. Indicator Sighting Reporting) and are often asserted as the most common ones we need to focus on at the expense of others discounted as esoteric
or niche.
And again, the conclusionary statement here is fundamentally untrue. Addressing the set of relevant use cases does not require that everyone use the same product.
They simply need to agree on elements of the profiles they will support (based on their use cases) and use products that support those profile elements. Assertions that flexibility is impossible and everyone would have to be using the same product are demonstrably
untrue in current use.
Simplicity will gain us adoption, and from adoption we can iterate over time and add features.
I am in strong favor of "one-way-of-doing-things". I am also in strong favor of getting rid of and simplifying the extensibility so that we can guarantee interoperability.
[sean]I would like to request that we stop using the buzzwords “simplicity” and “one-way-of-doing-things” in an ambiguous manner. They are at best distracting and disruptive if used without specifics of what particular issue is being discussed, what
specific structure is being deemed too complex, what specific structure is being proposed as “simple” or the "one-way-of-doing-things” and details of how it supports the capabilities of the “complex” structure in a better way
or explicitly argues that those capabilities are not relevant. Using them ambiguously is like a politician saying “its for the children”. Of course, we can all agree on the benefit of that, right? Well, unfortunately it typically means we are not all necessarily
agreeing on the same thing. What I think is “simple” or the “one-way-of-doing things” is likely different from your thinking on the same terms. Specifics are absolutely necessary. I am very much interested in discussing such issues if we can do so in a manner
that is specific.
It looks like it is being used here to imply that the “simplicity” of removing core capability like extensibility is an obviously good thing and gains us adoption. I would argue that this is a naïve presumption. May it gain us adoption for the absolute
lowest common denominator? Perhaps. Would it kill adoption for a wide range of uses beyond the lowest common denominator and force those players to seek alternative (and likely competing) solutions? Very likely.
Simplifying and normalizing/standardizing are good things but only as they still fit within what is necessary to actually serve purpose.
Remember, Einstein’s quote is “Everything should be made as simple as possible, but not simpler”. The second half of the quote is absolutely crucial to the principle. Simple alone is not necessarily good but as simple as possible to still serve purpose
is.
Where we can identify opportunities to simplify structure and still serve the purposes necessary I will be 100% supportive and always have been (remember, we have done this several times over the last few releases). Where arguments are made that
“simplicity” should be pursued at the expense of serving the purposes necessary you will find me skeptical and requiring clear and unassailable justification. I view such defense of the community’s work to date as a key responsibility as an expert and as a
co-chair.
To Jason's points, I would suggest we add an option for "other" and we also try to be more diligent about updating the controlled vocabulary. Maybe go so far as to say that
every January we will rev the controlled vocabularies.
[sean]Looks like we have found common ground on a need to be more diligent about updating the default controlled vocabularies.
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."
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]