cti — archive

Playing the "simpleton's advocate": how much complexity can we throw overboard?

From: Jerome Athias <[email protected]>
To: [email protected]
Date: Mon, 21 Sep 2015 15:09:00 -0000

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 < [email protected] > : - 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