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  <  > :
- 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