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?


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 <Bernd.Grobauer@siemens.com>:

- 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
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]