2015-09-21 21:12 GMT+03:00 Jason Keirstead <Jason.Keirstead@ca.ibm.com>:
So.. part of the reason it is so complex is that we are trying to re-implement what is essentially a rule language. If we actually *had* a real rule language, instead of all of these XML constructs, then we could simply use this language.
Imagine how much simpler Observables would be if we could do something like this
<observable>
( DestinationPort = 80 AND Protocol = "TCP" AND MD5Hash = 3453927402957 ) FollowedBy ( RegistryKey = "HKEY_CURRENT_USER\blah...." ) FollowedBy (ProcessName = "Foobar.exe" )
</observable>
Taking this and turning it into CybOX would result in likely 2 dozen lines of XML.
IE... what makes the whole thing so complicated is we're trying to disil a rule language into XML tags.
I don't know what an answer is that doesn't involve "reinvent CybOX from the ground up", but that is the problem.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown"Jordan, Bret" ---09/21/2015 01:37:50 PM---So Jason, how do we do those things in a more sane manner and give more expressiveness so you can me
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 09/21/2015 01:37 PM
Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
So Jason, how do we do those things in a more sane manner and give more expressiveness so you can meet your needs. I would like to make sure it is simple to understand and easy to use but also allows for rich expressiveness.
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:29, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
I agree with most parts of this, but not all.
Specifically, Observable Composition and Negate are both absolutely required. In fact, they need to be further enhanced to support Sequences ( see discussion here https://github.com/STIXProject/schemas/issues/329 ).
We already have actual, real world, in the wild, threat use cases that can not be expressed in STIX today due to lack of sequences. Removing expressions and negation, will make it this situation worse, not better.
If it's agreed to move all of this logic into CybOX and do it there... then OK (CybOX will need several enhancements), but we need to retain (and enhance) the capacity of STIX here. If there are classes of cyber-onservables that can't be expressed in STIX due to simple lack of expressiveness, then it will severely limit adoption of it by tools.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<graycol.gif>"Grobauer, Bernd" ---09/21/2015 12:07:15 PM---Hi, stepping back from the choice of binding for a moment, I would like to
From: "Grobauer, Bernd" <Bernd.Grobauer@siemens.com>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 09/21/2015 12:07 PM
Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?
Sent by: <cti@lists.oasis-open.org>
Hi,
stepping back from the choice of binding for a moment, I would like to
explore a bit, how much the next major version of STIX might differ
from what we have today in terms of simplification.
So, as an experiment, below I will go through the 'Indicator'
entity and propose changes. Here I will try to take the side of
"as simple as simple can be", be the "simpleton's" advocate, so
to speak, in the hope of getting some discussion going regarding
what is maybe too simplistic vs what kind of complexity we might
be able to throw over board.
Here is the overview of the indicator entity/concept
taken from page 13 of
https://github.com/STIXProject/specifications/blob/master/documents/pdf%20versions/STIX_Indicator_Draft.pdf
<09226000.jpg>
Let me propose the following simplifications:
- version:
Keep.
- 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).
- Title:
Make the field mandatory, but it may be empty.
- 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.
- Alternative_ID:
Unsure, probably keep.
- 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.
- 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.
- 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?)
- 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...
- 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.
- 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.
- 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.
- Likely_Impact.
Remove: I have never encountered it being used and have
a hard time coming up with a convincing use case.
- 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)
- 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.
Like I said above: this as an experiment of being very simple
indeed (though my mind is probably too convoluted with
all things CTI to come up with the super-simple thing).
I am sure some of it is too simple, but with the current
version of STIX we have already one extreme of complexity --
to map out our design space, we need to get a feeling
for the other extreme as well, I think.
Kind regards,
Bernd
--------
Bernd Grobauer, Siemens CERT