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?


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




> -----Original Message-----
> From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
> Sent: Montag, 21. September 2015 18:16
> To: Patrick Maroney
> Cc: Grobauer, Bernd; Jerome Athias; cti@lists.oasis-open.org
> Subject: Re: [cti] Playing the "simpleton's advocate": how much
> complexity can we throw overboard?
>
> STIX needs to become actionable in a M2M context.  Yes, at some point
> in the life cycle the CTI will be bubbled up to a Human, and each
> organization WILL have a different appetite for when that will take
> place.  Think of all the APPs I want written on the various APP
> stores... They will all interact with the data at some point.  However,
> each of the applications will need to "do" things with the data before
> it gets on the UI.
>
> In regards to Profiles, I can agree in the most general and high level
> concept.  However, the way profiles are done today, they are
> effectively un-useable and do not scale. To quote Aharon out of context
> as he was talking about discovery in TAXII land, it would be nice if
> profiles in a STIX state machine worked as simply as:
>
> EHLO taxii.example.com
> VERSION 1.2
> STARTTLS
> 1.2 READY TO STARTTLS
>
>
> 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.
>
>
>
> 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."
>
>
>       On Sep 21, 2015, at 09:41, Patrick Maroney <Pmaroney@Specere.org>
> wrote:
>
>       I will (again) argue for:
>
>       (1) STIX Profiles
>
>         (1.1) human and machine readable
>
>         (1.2) Adding declaritive 'simple' form: enumeration of
>
>            (1.2.1) these are the 'things' I can consume/produce
>
>            (1.2.3) these are the conventions for "types of things":
> e.g. Kill Chain
>
>       (2) Community consensus on a core set of standard STIX Profiles
> (e.g: top 10 use cases)
>
>       Note that this is not an arguement against things like
> elimination multiple description options, etc.   It is an argument
> however for avoiding endless debates on which "things" are important as
> I posit we will never reach consensus given the diverse set of world
> views and use cases CTI needs to embrace.
>
>       Editorial Note: Although we do indeed argue for M2M inter-
> exchange as the core functional requirement, eventually the data is
> likely presented to a human where things like Description
> provide/context value in the end state models/databases/ticketing
> systems/etc.
>
>       Patrick Maroney
>       President
>       Integrated Networking Technologies, Inc.
>       Desk: (856)983-0001
>       Cell: (609)841-5104
>       Email: pmaroney@specere.org
>
>
>
>
>       On Mon, Sep 21, 2015 at 8:08 AM -0700, "Jerome Athias"
> <athiasjerome@gmail.com> wrote:
>
>
>       Hi,
>
>       first for initiating this discussion.
>       While I will comment inline below, (because everything was added,
> at some point, for a reason or another) without wanting to be the
> devil's advocate vs KISS; I wonder if we should consider an approach at
> an higher level.
>       Putting some food on the table:
>
>       - Should we provide guidance documents (e.g. The preferred
> Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain,
> etc.)?
>       or/and
>       - Should we define what is mandatory or optional (in order to
> reach compliance/compatibility level A, B, C)?
>       or/and
>       - Should we have "2 versions": Minimum required fields (for
> compliance level A/STIX-basic), Additional advanced fields (for
> compliance level B/STIX-Gold) (with full support, level C/STIX-
> Platinum)?
>
>
>       2015-09-21 17:04 GMT+03:00 Grobauer, Bernd
> <Bernd.Grobauer@siemens.com>:
>
>
>
>
>               - negate:
>                 Remove -- the use case is mostly academic, but if the
>                 flag is there, it completely changes the semantics of how
>                 the indicator is to be handled and is a real pain for
> implementation,
>                 even though it is hardly ever used
>
>                 (Note: as shall be explained below, the 'negate' will not
> be needed anymore
>                  for building logical expressions of indicators, because
> we shall throw those
>                  out, too).
>
>       JA>  I would agree
>
>
>
>               - Title:
>                 Make the field mandatory, but it may be empty.
>
>       JA>  +1
>
>
>
>               - Type:
>                 Remove, if there isn't someone who can come up with a
>                 convincing case in which the field is really useful and
> where
>                 the intended semantics could not be communicated with
>                 a reference to a COA.
>
>       JA>  Disagree for now (until we review the Controlled
> Vocabularies)
>
>
>
>
>               - Alternative_ID:
>                 Unsure, probably keep.
>
>       JA>  keep (advanced) for mapping with internal/proprietary IDs
> (same as CVE - MS-KB link for VM)
>
>
>
>
>               - Description:
>                 - There should be exactly 1 description field (which may
> be empty).
>
>                   Yes, this precludes fancy schemes of having different
> descriptions
>                   for different audiences/access levels, but those should
> amount
>                   to less than 0.1% of all indicator objects ever to be
>                   produced and thus do not warrant substantial
> complication of
>                   the standard.
>
>       JA>  Sensitive regarding internationalization (meantime now it's
> a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field
> for 0..n)
>
>
>
>
>                 - There should be exactly one text representation, and
> that should *NOT*
>                   be html on account of security issues with rendering
> HTML in the
>                   browser. Chose Markdown, RestructuredText or whatever.
>
>       JA>  not sure for now for the format, need to investigate further
>
>
>
>
>
>               - Short_Description:
>
>                 Remove: I am tired of receiving indicator objects in
> which
>                 two or three out of three of the fields "title",
>                 "description", "short_description"
>                 are empty -- one description field should be plenty.
>
>                 (Besides: everybody keeps telling me that STIX is for
>                 machine-2-machine rather than *-2-human communication, so
>                 why the big fuss about description fields?)
>
>       JA>  Not for remove, but Potentially could be replaced by
> Description (as 1..1) + DescriptionOthers as 0..n
>
>
>
>
>
>               - Valid_Time_Proposition:
>
>                 Timing info for indicators is badly needed, but I have
> yet to encounter usage
>                 of it. Can we come up with sensible guidelines of how to
> use the field?
>                 It should only be kept if we can...
>
>       JA>  Guidance documents... :-) Some could argue we just need that
> for an Exercise/Test, or/and I personally hate CTI feeds with tons of
> old/useless IOCs
>       JA>  But could be just an Advanced Field
>
>
>
>
>
>               - IndicatorExpression
>
>                 In the present specification, this field can either
>                 contain what is essentially a logical formula (codified
> as a tree)
>                 of indicators or an observable composition.
>
>                 - Remove logical operations: allow only to reference a
> list
>                   of indicators that constitute the present indicator.
>
>                 - If you want to do complicated and/or/not-reasoning
> about
>                   observable stuff: that is essentially a signature,
>                   so find a signature-language of your choice (including
>                   and/or/not-combinations of CybOX observables, if that
>                   is what works best) and formulate the signature
>                   as a test mechanism.
>
>                 - For everything else: find a way to encode observable
>                   patterns as simple key-value pairs and
> include/reference a list
>                   of them here. Should work fine for the majority of
>                   current use-cases. At most, allow a structured list
> that
>                   groups basic observable patterns (key-value) pairs with
>                   respect to a cybox observable to which they belong.
>
>       JA>  Investigate further
>
>
>
>
>               - Indicated_TTP:
>
>                 Use yet-to-be-designed relationship mechanism.
>
>               - Kill_Chain_Phases:
>
>                 Define *ONE* standard STIX kill chain and work with that.
>                 Being able to include alternative models is nice, but
>                 complicates tooling quite a bit ... and, remember, this
>                 is an exchange format, so one common kill-chain model
>                 understood in the same way by everybody will work best.
>
>       JA>  Guidance (preferred one), Optional/Advanced
>
>
>
>
>               - Test Mechanisms
>
>                 Make this a stand-alone entity/object rather than part
>                 of the Indicator object. As mentioned above: use this
> also
>                 to communicate more complicate observable patterns
> expressed in CybOX.
>
>       JA>  potentially ok
>
>
>
>
>               - Likely_Impact.
>
>                 Remove: I have never encountered it being used and have
>                 a hard time coming up with a convincing use case.
>
>       JA>  I see interest there for high level/strategy/business point
> of view (Risk Management: Impact * Likelihood)
>
>
>
>
>               - Suggested_COAs:
>
>                 Use yet-to-be-designed relationship mechanism.
>
>               - Handling:
>
>                 Replace with some new mechanism for marking stuff with
>                 handling information.
>
>               - Confidence
>
>                 Keep: we need a simple way to distinguish high-confidence
>                 from low-confidence indicators.
>
>               - Sightings:
>
>                 Find some other way to do sightings (cf. the discussion
> on
>                 the mailing list)
>
>       JA>  Still unresolved I agree
>
>
>
>
>               - Related_*: Use yet-to-be-designed relationship mechanism.
>
>               - Producer:
>
>                 Either simplify drastically or better yet, leave away
>                 and consider for the next but one major release.
>
>       JA>  not sure for the moment
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]