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: On TTPs and specifications

Let's talk TTPs: Tactics, Techniques, and Procedures. Relevant background reading and other links are at the end, including to the playground space that Bret Jordan set up. 

What is a TTP anyway?

Basically, how an actor carries out their intent. It's not a tool. It's a set of methods, effectively, specified to varying levels of detail. In general, when an actor deploys a capability against a target to accomplish some goal, the way the actor does so can be represented as a set of TTPs. For a non-cyber example, and because it's May 4th when I write this:

Goal: Destroy the Death Star
TTP: X-wing fighter-bombers provide close space support to Y-wing bombers against TIE fighters until equatorial trench is reached, at which point all craft proceed linearly until ordnance is successfully delivered to the reactor.
Tools: Proton Torpedoes

This can further be broken down between the specific tactics, techniques, and procedures, but for illustrative purposes this suffices. Additionally, given the lack of consensus among practitioners, it might not be useful to go to a level of detail where we differentiate between the three. Whether STIX should support those distinctions is an open question.

STIX Representations

I envision four different ways that STIX could represent TTPs, listed here in order of desirability (according to my personal estimation, of course):

  1. Use the Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework from MITRE. This is not desirable right now because the framework currently limits itself to Windows post-exploitation activity.
  2. Maintain the existing TTP definition from STIX v1.2. This might provide a good starting point, but lacks clarity because it includes other information and suffers from the general over-engineering common in v1.2.
  3. Simply adopt the VERIS framework, in particular the Actions section. While useful, this does not contain enough information.
  4. Allow users to specify TTPs in their own way, possibly including a field to note which existing standard they choose to use.

As an example, we could include the following fields within TTP:
  1. Goal (string)
  2. Action sequence (list of strings)
  3. Reference framework ("ATT&CK", "CAPEC", "VERIS", or other user-supplied)
We should strip out mentions of targeting as listed in v1.2 because those should be listed as separate objects and a relationship created. There are other metadata fields that will be important, of course, like IDs and whatnot, but here I have been focusing on the TTP-specific things.

Next steps

In my mind, we need to first figure out a general approach: do we marry ourselves to a particular framework? Do we try to maintain some level of connection to the previous format?

Kyle Maxwell [kmaxwell@verisign.com]
iDefense Senior Analyst

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