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?


Well said.  What some have asked for is a STIX-Lite.  And there is a few projects that are attempting to do that and one could argue that Facebook's ThreatExchange is an attempt at that.  Google is your friend to find the STIX-Lite projects.  The only way I really see profiles working is if their is a simple negotiation protocol, and maybe it is done in TAXII where you say.

1) I support STIX-Lite

or 

2) I support STIX-Medium

or 

3) I support STIX-Full

If we did this we would need to make sure the APIs for STIX-Lite are robust enough that if someone sends them more than they can deal with, they can silently just throw it away.  This would also shift the cost or burden to the STIX-Full people to figure out what they can send and not send.  So the people that are most interested in sharing advanced CTI will have the most work to do in code.  

The other problem I see with profiles is if there is an infinite number of possibilities.  Then the problem is now even harder to solve.

In conclusion we have to be careful that we do not make STIX and CybOX so complex that it only works for the small minority of groups that want to share the most advanced forms of CTI.  




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 22, 2015, at 07:13, Grobauer, Bernd <Bernd.Grobauer@siemens.com> wrote:

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




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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