[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?
Bernd,
Thank you for your providing your thoughts.
I would agree with some of your thoughts/proposals and believe several align with some of the changes that have been discussed already.
I would disagree with some other of your thoughts/proposals and believe that they would benefit from further clarifications and contextual discussions and the rationale for some of the capabilities you propose removing. I do not at this time have the cycles
to fully provide such exposition as you cover a lot of ground here and I am currently working on getting the STIX 1.2.1 specs wrapped up for SC review and on fleshing out a starting basis for some of our use case discussions.
I did however add a brief comment to each thought/proposal below to either show my concurrence or to flag issues that I believe will require further discussion.
Hopefully, this initial partial reply may be useful.
Comments are inline below
Sean
From: <cti@lists.oasis-open.org> on behalf of Bernd Grobauer <Bernd.Grobauer@siemens.com>
Date: Monday, September 21, 2015 at 10:04 AM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? 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
Let me propose the following simplifications:
- version:
Keep.
[sean] Agree
- 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).
[sean] Disagree. The use case for this is not academic. The use case and requirement came from actual CTI analysts. As stated here, it is part of the capability to define logical compositions of Indicators as discussed below.
- Title:
Make the field mandatory, but it may be empty.
[sean]I would have no objections as long as it could 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.
[sean]Disagree. This is a fundamental property of indicators used for understanding and potentially routing/processing indicators based on their type. It is widely used and is likely to become more so.
- Alternative_ID:
Unsure, probably keep.
[sean]Agree. Various community members have actually argued for such a structure on all id’able constructs.
- 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.
[sean]Disagree. This was just discussed for STIX 1.2. Clear use cases were identified by community members strongly desiring this feature. The community discussed it, agreed on its usefulness, talked through its value not only for the requested use case
but also for other future use cases such as internationalization, it was modeled, approved by the community and pushed in a formal release of the language. I do not believe that any of the use cases or value propositions have changed and do not see a rational
reason/justification for pulling something out that we as a community just added in.
- 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.
[sean]Disagree. Practical reality for the human readable content within STIX is that it is very unlikely that all users would agree on a single format that is acceptable. I would propose that the best option here that meets practicality limitations is
to specify a default/MTI value but not to limit it to only that value.
- 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.
[sean] Agree. I would personally agree with removing the Short_Description field. I believe that Title and Description are still necessary though.
(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?)
[sean]While its structure is designed for m-2-m exchange, its actual content is often very much intended for human consumption. Humans should not be reading the STIX content directly but rather presented the content via some UI but this sort of content
is very important to the real-world CTI use cases.
- 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...
[sean]Agree
- 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.
[sean]Disagree. From the language used here I think there may be confusion or lack of understanding on the rationale for composition and the differences between Observable composition and Indicator composition. They are different and serve different purposes.
Neither of them on their own could support both purposes.
I cannot go into detail on this at this time but this sort of composition is very important to the real-world CTI use cases.
Documentation attempting to provide the relevant context on this issue is available at: http://stixproject.github.io/documentation/concepts/composition/
- Indicated_TTP:
Use yet-to-be-designed relationship mechanism.
[sean]Agree. This should be separable as an independent type of relationship.
- 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.
[sean]Disagree. Real-world practicality is that there is no single use case that will be adequate or acceptable for all cases.
The flexibility to define and reference multiple kill chains is a fundamental capability of STIX to support real-world CTI use cases.
- 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.
[sean]Not sure I understand what you are proposing here.
- Likely_Impact.
Remove: I have never encountered it being used and have
a hard time coming up with a convincing use case.
[sean]I am with you on the that I never like these sorts of potentially ambiguous characterizations (real impact is always context dependent and assertions by the producer are always guesswork) and I argued against
its inclusion in STIX. However, this field was repeatedly demanded by various players within the community and it is my understanding that it is being used.
- Suggested_COAs:
Use yet-to-be-designed relationship mechanism.
[sean]Agree. This should be separable as an independent type of relationship.
- Handling:
Replace with some new mechanism for marking stuff with
handling information.
[sean]I think this is way too open ended to even comment on at this time. ;-)
- Confidence
Keep: we need a simple way to distinguish high-confidence
from low-confidence indicators.
[sean]Agree.
- Sightings:
Find some other way to do sightings (cf. the discussion on
the mailing list)
[sean]Agree. This should be separable as an independent type of relationship.
- Related_*: Use yet-to-be-designed relationship mechanism.
[sean]Agree. This should be separable as an independent type of relationship.
- Producer:
Either simplify drastically or better yet, leave away
and consider for the next but one major release.
[sean]I don’t think that we can drastically change the expressivity capabilities of a “source” construct but one of the potential proposals on the table does involve abstracting Source out to a top-level construct and let all other constructs reference
instances of it rather than embedding it into every other construct. This simplifies all the constructs, improves space efficiency, provides better pivoting ability, and can potentially support additional structures for associating “trust” with particular
sources. Byron Collie has been arguing for this for a while.
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]