There is a common theme running in our important discourse. It is important for Vendors and those focusing on narrow Use Cases to understand the complexity of APT Intrusions. We understand and *completely* support many of the arguments made for simplicity
and easily addressing narrowly focused use cases. If I just need to send a list of IP Address, Domains, etc. to security appliance, then an efficient/consistent/simplified mechanism is absolutely a key CTI requirement.
Those of us who have been dealing with the full scope of APT Targeting, Compromise, Lateral Movement, Entrenchment, repeated Mapping/Exploitation of Victim Organizations and Infrastructure, etc. for many many years (pre Titan Rain) are also key stakeholders
in "Our Thing".
We are not pushing for "Complexity" just for complexities sake: we are pushing these higher dimensional representation concepts because this complexity is part of the reality we operate in on a daily basis. If we can't model all of the key elements of
Adversary, TTP, and Target Domains, we can't change the Cyber Battle Space dynamics. Doing so globally, across sectors, in real-time, is the "Holy Grail" we seek. No one said this would be easy, but it is a much much better use of our collective energies
in comparison to another decade of playing APT Whack-A-Mole and counting Body Bags.
Hopefully I'm not triggering a new wave of "Less Filling" <==> " Tastes Great" 😁
On to specifics (great discussion by the way)
(1) IncidentType is critical to some of the highest value CTI Use Cases, including mandatory Incident Reporting (in some cases, required under law in 72 hours after detection!). Automating, standardizing/normalizing, and aligning Incident Reporting across
Stakeholder
(2) C2 is one of the highest value CTI Elements one can convey.
"One of the most common forms of indicator seen describes a pattern for TCP traffic beaconing to a specific command and control (C2, C&C) server. This idiom describes creating such an indicator in STIX."
The presence of attempted or active C2 is one of the strongest indicators of "Wildfire": Active compromise of an asset/network. If you see it you are pwned, only question is the degree.
C2 can be a component of all Kill Chain Phases (Lockheed Martin™) , from "Recon" to "Actions on Intent".
We could consider the "one way to do things" principle, but given the importance of semantically and temporally characterizing C2 in the Operation Domain, we would need to ensure we can clearly convey in all required contexts.
(3) Similar comments to C2 on "Exfil". Although we have a running joke in certain Domains ( "...but no evidence of Exfiltration"). "Exfil" is the "Game Over" state in CTI Operational Domains.
(4) "Malicious.CybOXObject"
It would be great to start focusing on a number of long standing enumerated type issues in CTI. In some cases they are non-sequitur with current realities, incomplete, bloated, etc. We should also be mindful of related standards and use these and/or
map to their taxonomies. Some of the enumerations in other standards have similar issues with currency/relevance, but we should adopt these wherever possible and engage with those communities to fix them "in one place" (Jerome Athias has one of the best perspectives
on these standards, where they intersect, conflict, etc.: Jerome would be a great resource to lead this effort)
_____________________________
From: Grobauer, Bernd <
bernd.grobauer@siemens.com>
Sent: Friday, October 23, 2015 6:50 AM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
To: <
jwunder@mitre.org>, <
jason.keirstead@ca.ibm.com>,
<
cliff.palmer@gd-ms.com>
Cc: <
cti-users@lists.oasis-open.org>
Hi,
> I heard a recent proposal to remove it entirely. What would be the
> impact of that?
I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.
Why had I suggested to remove it?
The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:
- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
into the Indicator Type? I could understand "Watchlist", which tells you
to watch for whatever Observable Patterns are indicated in the indicator.
- Another type is 'C2' -- at the same time I have the ability to reference
in the indicator a kill chain phase ... and if the referenced kill chain
is of any use, it will have something corresponding to 'C2'.
Now I have (again) two ways of expressing the same thing ... we have
just stumbled over this issue a few days ago in a sharing group we
are part of: we use the reference to the killchain phase to indicate
C2-activity, others use the indicator type.
Similarly, "Exfiltration" -- should that not be described with a reference
from the indicator to an TTP "Exfiltration"?
Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)
My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.
Kind regards,
Bernd
----------------
Bernd Grobauer, Siemens CERT