Agreed with Bret. I thought we proposed that on the previous call for such a TLO.
I also agree with Kyle that we should focus on the core need for the use cases we have in mind and not keep any baggage from the past if its not required.
Gary was going to take a stab at proposing something that we can review soon hopefully that might help in this regard.
"firstname.lastname@example.org" <email@example.com> on behalf of "Jordan, Bret" <firstname.lastname@example.org>
Date: Friday, May 13, 2016 at 2:01 PM
To: "Maxwell, Kyle" <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [cti-stix] TTP proposal
So we have a TLO called "Action" or "Attack" or "Foo" or "TP" or "Something". And this TLO contains the "knowledge" gained by an analyst about the collection of tools, infrastructure, and processes that a Threat Actor may use against a
Victim or in a Campaign????
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
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
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 [firstname.lastname@example.org]
iDefense Senior Analyst