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?


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]