[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?
> The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. I am very much in favor of shedding complexity everywhere we can (though not at the expense of necessary features). I'll use STIX versioning [1] as an example - I think we need versioning, and I think we can probably simplify the current design. That said, I find myself wondering if there are some higher level topics to work through before we get down into the design of specific concepts and fields. Do we all agree on what the top level objects for STIX and the relationships between them should be moving forward? Is that the best question for us to be asking ourselves? Thank you. -Mark [1] http://stixproject.github.io/documentation/concepts/versioning/ -----Original Message----- From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Grobauer, Bernd Sent: Tuesday, September 22, 2015 9:13 AM To: bret.jordan@bluecoat.com; Pmaroney@Specere.org Cc: athiasjerome@gmail.com; cti@lists.oasis-open.org Subject: RE: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? Hi, thanks to everybody who responded to my summation as "simpleton's advocate". The reactions have shown, I think, that STIX 2.0 is unlikely to shed much in terms of complexity in comparison to STIX 1.x. The reason is that STIX is made to cover every desirable use case: if an analyst X in an organization Y needs to describe an observable pattern consisting of temporal dependencies in conjunction with logical reasoning, must offer three different descriptions in various mark-up languages and add kill-chain information in his organization's own kill-chain model ... well, he should be able to do so with STIX. I understand that this is desirable, but we must be aware of the fact that it comes at a substantial cost for tooling: creating a tool that can sensibly ingest the *full* standard (an aside: will we actually be able to say what the *full* standard is, since it can be extended with custom vocabularies, embedding of various other standards such as CIQ, OpenIOC, ...) will be beyond any organization that is not in the business of carrying out professional software development. And even for such organizations, it will be a mouthful: after, all, we are creating the mother of all signature/pattern languages (encompassing the capabilities of OpenIOC, Yara, Snort, Arsight Rules, temporal reasoning, etc.) combined with contextual information that can be supplied in an astonishing level of variety. Now, let us take a look at the current level of exchange that is going on. It is likely that I am not privy to the most advanced exchange schemes that are currently operating, but it seems to me that what most organizations are currently after is to be able to associate a handful of indicator types (just lists, no logical let alone temporal reasoning) with useful context in a structured way. They are likely to embrace a technology that allows them to exchange information about relatively simple indicators with useful contextual information that comes always in the same form: one and the same kill-chain (because then they know exactly what to expect and can base automation upon the info), and a single description field rather than possibly several description fields, ...: only with this level of simplicity, they will be able to write tools that understand and interpret all information rather than ignoring or misinterpreting half of it. The argument that lists of indicators are not really CTI is beside the point: you have to support consumers at their current level of operations/capabilities and then extend, rather than present them with a language that is excellent at covering the most complicated use case but extremely cumbersome at doing what they (at least at the time being) really want/need to do. So our answer to this problem may be "profiles" ... we could specify a profile for a simplified STIX that realizes many of the simplifications I had written about in my mail from yesterday (and similar simplifications for the other STIX entities -- I fear the 'indicator' was a rather easy target for simplification) without preventing "full STIX" to support more sophisticated use-cases. Bret writes on the subject of profiles: > We keep hearing profiles, profiles, profiles as the way to solve all > the things that are broken. But I am not sure the bandaid of profiles > will hold. And in fact, profiles will probably need to end up being > YACS (yet-another-cit-standard) with its own markup. I just do not > see how profiles are going to really work in code. I get how they > "should" work in theory and the idea behind them is a great concept. > But they are not a good practical solution, at least not yet. I tend to agree ... I think profiles will only work if the profile can be specified such that it translates into a restricted binding definition, which can then be used as basis for implementations. Or, if such a translation cannot be found, the profile will have to be supported with a binding definition created by hand by modifying the definition of the full binding. Note that a profile will leave a certain level of verbosity: Even if I only allow a single definition in a certain profile, I still would have to say <Definitions> <Definition>foo</Definition> </Definitions> The alternative would be to turn the profile into a simplified binding ... and we are back to multiple bindings. To sum up: I fully understand that CTI is complicated and that a standard that wants to support all relevant use cases and ways of specifying CTI must necessarily also be complicated. At the same time, many organizations would be happy, I think, to receive a possibility to add a limited but very useful amount of contextual information to the rather limited set of indicators they are currently exchanging with other organizations. If all we are going to offer to them is STIX/CybOX of the current complexity with simplifications described in informal profile definitions, then there is a danger that STIX/CybOX will be overtaken and superseded by a standard that will be absolutely primitive in comparison to STIX/CybOX ... but will have met current demand. So, my conclusion, I think, is: since there will be no majority for drastically simplifying STIX/CybOX by throwing away lot's of what has been added over the time for the support of valid use cases: we have to start taking profiles in earnest and work towards the creation of a "simple STIX" profile. The ability to define profiles in a sensible way must therefore be considered when choosing the MTI binding. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]