OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[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]