[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?
- negate:Remove -- the use case is mostly academic, but if theflag is there, it completely changes the semantics of howthe 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 anymorefor building logical expressions of indicators, because we shall throw thoseout, too).
- Title:Make the field mandatory, but it may be empty.
- Type:Remove, if there isn't someone who can come up with aconvincing case in which the field is really useful and wherethe intended semantics could not be communicated witha 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 descriptionsfor different audiences/access levels, but those should amountto less than 0.1% of all indicator objects ever to beproduced and thus do not warrant substantial complication ofthe standard.
- There should be exactly one text representation, and that should *NOT*be html on account of security issues with rendering HTML in thebrowser. Chose Markdown, RestructuredText or whatever.
- Short_Description:Remove: I am tired of receiving indicator objects in whichtwo 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 formachine-2-machine rather than *-2-human communication, sowhy the big fuss about description fields?)
- Valid_Time_Proposition:Timing info for indicators is badly needed, but I have yet to encounter usageof it. Can we come up with sensible guidelines of how to use the field?It should only be kept if we can...
- IndicatorExpressionIn the present specification, this field can eithercontain what is essentially a logical formula (codified as a tree)of indicators or an observable composition.- Remove logical operations: allow only to reference a listof indicators that constitute the present indicator.- If you want to do complicated and/or/not-reasoning aboutobservable stuff: that is essentially a signature,so find a signature-language of your choice (includingand/or/not-combinations of CybOX observables, if thatis what works best) and formulate the signatureas a test mechanism.- For everything else: find a way to encode observablepatterns as simple key-value pairs and include/reference a listof them here. Should work fine for the majority ofcurrent use-cases. At most, allow a structured list thatgroups basic observable patterns (key-value) pairs withrespect 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, butcomplicates tooling quite a bit ... and, remember, thisis an exchange format, so one common kill-chain modelunderstood in the same way by everybody will work best.
- Test MechanismsMake this a stand-alone entity/object rather than partof the Indicator object. As mentioned above: use this alsoto communicate more complicate observable patterns expressed in CybOX.
- Likely_Impact.Remove: I have never encountered it being used and havea 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 withhandling information.- ConfidenceKeep: we need a simple way to distinguish high-confidencefrom low-confidence indicators.- Sightings:Find some other way to do sightings (cf. the discussion onthe mailing list)
- Related_*: Use yet-to-be-designed relationship mechanism.- Producer:Either simplify drastically or better yet, leave awayand consider for the next but one major release.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]