Re: [cti-stix] TTP proposal

[Jerome Athias <athiasjerome@gmail.com>]

Just a note for VERIS
I found benefits of mapping VERIS ASSET.VARIETY Enumeration
http://veriscommunity.net/enums.html#section-asset
With the NCP Checklists ncp:product-category (+OVAL)
https://nvd.nist.gov/download.cfm#NCP_FEED


2016-05-13 23:18 GMT+03:00 Maxwell, Kyle <kmaxwell@verisign.com>:
> I've written here before about TTPs, but other calls and conversations this
> week have helped crystallize some specific thoughts. Clearly, we've gotten
> stuck a bit on this because of different interpretations of the term, but
> this is causing problems. As Bret has noted, this general topic has become
> the "long pole in the tent" making it difficult for development of other
> TLOs to move ahead.
>
> Motivation
>
> Let's forget about STIX 1.2 "TTP" for a moment and instead just think about
> what we want to capture. When a Threat Actor carries out some sort of
> attack, we want to be able to describe what they're actually doing
> (phishing, DDoS, etc.) at some level of detail (spear phishing, UDP flood,
> etc.) They might use various tools and infrastructure as part of their
> attack, but they can change the tool (recompile to get a different hash) or
> the infrastructure (switch IP addresses) without changing their actual
> methodology.
>
> Now, we can get very granular in how we describe that, but I submit that
> that's not something we can capture in anything like a controlled vocabulary
> right now. We do, however, have a number of existing vocabularies that
> describe those types of attacks at an intermediate level of granularity -
> CAPEC is a good one, but I don't think we need to require it per se. VERIS
> actions are another.
>
> Proposal
>
> Shelve "TTP" as a TLO for now. That term currently seems to create
> misunderstandings based on different interpretations, and in my experience
> as an analyst that is not restricted to our TC by any means. We can consider
> at a later date the possibility of creating this TLO at a fine-grained level
> (e.g. fields for Tactics, Techniques, and Procedures).
>
> Instead, create a TLO called "Action" or "Attack" or similar.  "Action" TLOs
> MUST contain either a "description" or an "attack pattern". They may be
> linked to an Actor, an observable of some sort (CybOX container?), a
> Campaign, etc., as defaults. The fields mentioned above are as follows:
>
> description - string - A free-text field that contains a concise description
> of the specific attack carried out by a Threat Actor.
> attack pattern - tuple (reference-std, reference-id) - A 2-tuple of strings
> that references a specific standard ("CAPEC", "ATT&CK", or "VERIS") and the
> ID within that standard that describes the attack (e.g. "CAPEC-488: HTTP
> Flood"). Implementers MAY choose their own standard to reference here if not
> one of the three defaults.
>
> This likely covers the needs for MVP, though it clearly will require future
> iteration, and allows the development of other TLOs to proceed apace without
> missing key functionality required to adequately describe an attack. By
> allowing existing standards / vocabularies, we enable STIX consumers to take
> some automated action or map to their own internal standards, and this
> deconflicts with other potential but important TLOs such as target
> organizations, malware, and other indicators.
>
> --
> Kyle Maxwell [kmaxwell@verisign.com]
> iDefense Senior Analyst