[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?
Definitely agree on the fundamental needs for the composition capabilities based on input from CTI analysts.
sean
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, September 21, 2015 at 11:29 AM To: Bernd Grobauer <Bernd.Grobauer@siemens.com> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? I agree with most parts of this, but not all. 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 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]