Re: [cti] Playing the "simpleton's advocate": how much complexity can we

VERSION 1.2

STARTTLS

1.2 READY TO STARTTLS

We keep hearing profiles, profiles, profiles as the way to solve all the things that are broken. But I am not sure the bandaid of profiles will hold. And in fact, profiles will probably need to end up being YACS (yet-another-cit-standard) with its own markup. I just do not see how profiles are going to really work in code. I get how they "should" work in theory and the idea behind them is a great concept. But they are not a good practical solution, at least not yet.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Sep 21, 2015, at 09:41, Patrick Maroney <Pmaroney@Specere.org> wrote:

I will (again) argue for:

(1) STIX Profiles

(1.1) human and machine readable

(1.2) Adding declaritive 'simple' form: enumeration of

(1.2.1) these are the 'things' I can consume/produce

(1.2.3) these are the conventions for "types of things": e.g. Kill Chain

(2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases)

Note that this is not an arguement against things like elimination multiple description options, etc. It is an argument however for avoiding endless debates on which "things" are important as I posit we will never reach consensus given the diverse set of world views and use cases CTI needs to embrace.

Editorial Note: Although we do indeed argue for M2M inter-exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

On Mon, Sep 21, 2015 at 8:08 AM -0700, "Jerome Athias" <athiasjerome@gmail.com> wrote:

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

cti message