OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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

Subject: TTP proposal

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.


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.


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

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