Moving beyond Threatbutt or: Threat Landscape 2039

Good afternoon, y’all, and thanks for the opportunity to speak to you
today. As the title suggests, this talk has two components.

I’ll get into technical matters related to threat intelligence
momentarily, but first, please allow me to frame this discussion in a
context you may not have fully considered.

Earlier this year I was at an infosec event where a vendor presented
their view of the threat landscape in 2016. It was a perfectly
acceptable talk but like 95% of the infosec talks I’ve heard: to wit,
everything is vulnerable, the world is going to hell in a handbasket,
and hence you should buy our black box or retain us to pentest your
 network.

In the course of their talk, the speaker happened to make a joke about
the impending end of the unix epoch in 2038 and it started me
imagining what a “2039 threat landscape” talk would look like. And to
be honest, I cannot imagine that it would bear any resemblance to the
typical infosec talk you hear today.

Fear-driven narratives are compelling and it’s easy to get sucked into
them. So, here’s the scary part of my talk.

The internet is rickety. Imagine for a moment that you’re taking a
hike in the forest and come to a stream blocking your path. You step
gingerly from one stone to another, carefully testing each next step
before shifting your full weight to the next stone. As a civilization,
we’ve managed to place our center of gravity on an unsteady rock
called the internet and there’s no way back. (Well, there may be but
it’s somewhat nightmarish to consider.)

The attackers currently have the advantage. We can’t possibly find all
the software bugs faster than the attackers can, much less patch them
in time. We don’t even know how much of a difference patching makes in
the grand scheme of things. Consider
Bruce Schneier’s 2014 Atlantic Monthly article in which he
ponders the problem of zero days and examines the question whether
software vulnerabilities are sparse or plentiful. We lack sufficient
data to say with certainty, but the data we do have suggests that the
number of software bugs we don’t know about is orders of magnitude
greater than the number we do know about.

Even supposing we could clone ten thousand Dan Bernsteins and Meredith
Pattersons to rewrite our software stacks, the installed base problem
would still bite us on the ass. Imagine, if you will, that a study was
published proving beyond a doubt that asphalt causes cancer. It would
still take decades to replace all the world’s roadways. Substitute
vulnerable embedded systems for asphalt and p0wnage for cancer and the
metaphor holds. This is the situation we confront. Metcalfe’s Law
posits that the value of a network is proportional to the square of
the number of connected endpoints. In a world of ubiquitous vulnerable
systems, many embedded and/or effectively unpatchable, the security
challenge appears to scale in rough parallel.

So here we find ourselves, perched precariously on a shaky foundation,
constantly shifting our center of gravity to avoid a perilous fall.

Here’s the good news: the worst case scenario almost never happens!

It’s worth noting that the situation we find ourselves in today is
hardly a novel one. Throughout human history, the rate of
technological change has outpaced our societies’ ability to adapt.
There are plenty of examples. If you’ll permit me to play fast and
loose with history, consider the following.

Gutenberg invents the printing press, then suddenly folks all over
Europe start reading the Bible for themselves, scads of new religious
sects emerge, and we get the Thirty Years’ War.

Flash forward to the fin de siècle, and rapid advances are being made
in science and industry. Ford gives us the assembly line process and
the Model T. Haber gives us the Haber–Bosch process for extracting
nitrogen from the earth’s atmosphere, thereby launching a revolution
in agriculture. The Wright Brothers give us the airplane. But in short
order all this technological advancement leads to the horrors of WWI:
total industrialized warfare, gas clouds looming over the tank-strewn
trenches of Europe.

Curie, Bohr, Fermi, Heisenberg, et al peel back the curtains to unveil
the undiscovered country lurking inside the atom, leading to
earth-shaking advances in medicine and energy production, but also to
horrors of Hiroshima, Nagasaki, and the Cold War.

I could go on, but this purports to be an infosec talk, not a history
lecture. The point is, there’s this pattern of technologically-induced
disruption leading into a period of societal adjustment. Following the
aforementioned convulsions, things more or less settled down. People
still kill and die for the written word. Nation-states still maintain
WMD stocks (nukes, chemical, biological, etc.) But in general, we have
adapted and life goes on.

So what would a “Threat Landscape: 2039” talk look like? Well, I can
see two mutually exclusive alternatives.

One is that something awful has happened, leading us to decide to
unplug from the networks and go back to something approaching the
paper-driven world we had before. I’m reminded of a scene from the
pilot episode of the Battlestar Galactica reboot. The earth has just
been hit by a devastating surprise attack by the Cylon enemy, just one
Battlestar survives, and the crew are frantically trying to calculate
an FTL jump to safety. At one point a crew member helpfully suggests
to the ship’s captain that if they just interconnected the ship’s
navigational computer with the other onboard computers, they could
make the FTL jump calculations much faster. The Battlestar captain,
having survived the previous Cylon war, barks back in anger, “Many
good men and women lost their lives aboard this ship because someone
wanted a faster computer to make life easier. …I will not allow a
networked computerized system to be placed on this ship while I’m in
command. Is that clear?”

So this is the dark view of a hypothetical “Threat Landscape: 2039”
talk. (Some researchers refer to this possible outcome rather cutely
as “cybermalaise”.)

The other possibility I see (and the one I would optimistically argue
is the more likely scenario) is that by that point we have undergone a
phase transition vis-a-vis cybersecurity. Certainly a huge part of
that will involve advances in technical controls and a shift towards
better IT hygiene, but based on the earlier historical analogies, I
think by far the most significant contributor towards a positive
outcome in 2039 will be societies adapting economically, culturally,
and at the policy level to catch up with technology.

As geeks, we tend to obsess about how cool tech like crypto,
threat-sharing, blockchain-ng, etc is going to save the world, but in
fact it is advances in meatspace that will make the difference. At
some point, the majority of nation-states will come to see that it is
in their mutual interest to co-exist peacefully in cyberspace and
increasingly collaborate to prosecute bad actors. We’ll see treaty
arrangements vis-a-vis cyberspace along the lines of existing
nonproliferation agreements. It may well take a series of unfortunate
events, the likes of which we have not yet seen, to bring about the
necessary shift in thinking, but I believe that if we can just stay
calm and do our best to hold shit together, we will live to see such a
positive sea change.

I am making a leap of optimism. It is absolutely not my intention to
handwave around the challenges we face; striving for intellectual
honesty is one of my core values. To stand here before you today and
offer a message of hope is difficult, especially considering the
events of the past 36 hours. But as a species we are resilient. We
have overcome far more daunting challenges in the past. We can and we
will prevail because we must. We owe that much to future generations.

President-elect Trump has spoken openly of unilaterally withdrawing
the US from long-standing international partnerships. The tide of
cross-border cooperation may well be receding before our eyes. This is
where industry can step in. One of the major catalysts driving the
success of ISACs and ISAOs has been market competitors waking up to
the fact that the strategic value of collaborating for mutual defense
via information-sharing groups outweighs any tactical economic
advantage gained when one of them is breached.

The advent of the NIS Directive (in the EU) and CISA (in the US)
provides liability protection for information-sharing. These are
necessary but insufficient measures. The critical factor remains
economic incentives, as firms come to the realization that active
participation in information-sharing communities can directly effect
their bottom-line by lowering the risk of breaches, both to themselves
and their supply-chain partners.

Now before I shift into the more technical part of my talk, I feel
obliged to note that I’ve been tossing the “cyber” around quite
liberally so far.

Language matters. Narrative matters. Framing matters. People exist in
and live by stories. While we enlightened few may laugh at the term
“cyber”, for those outside our circle it embodies the mysterious,
ethereal world of ones and zeros. We all tend to think about new tech
in terms of “it’s the x of y”, a la, Airbnb is the Uber of hotels.
Policymakers and C-level execs tend to be older. The more we age, the
more we tend to relate new things to the familiar of our youth (a la,
cars as mechanical horses or whatever.) Let me remind you that this is
a thing, so while we should be careful of our metaphors, if senior
decision-makers are more comfortable talking about “cyber-whatever”,
don’t be shy of embracing their language to reframe the conversation
and steer them toward a more technically-correct understanding of the
issues at hand. In that spirit, cyber all the things!

The title of my talk is “Moving Beyond Threatbutt”. In case you’ve
been living under a rock, Threatbutt is a hilarious site that
makes a parody of cyber-intelligence vendors. One of the criticisms
that’s been leveled at the concept of threat intelligence is that it’s
basically Antivirus-NG. And this is a fair criticism. The infosec
industry has a long history of vendors hyping the panacea of the week.
Antivirus wasn’t a panacea, nor was SIEM, nor is CTI. There is no
silver bullet. But these are all tools in our toolbox, we should use
them all as effectively as possible, and strive to constantly improve
the quality of our tools.

Now to the question of CTI, which we’ll examine in two contexts : one,
in terms of the OASIS standards, and two, as a tool fit for addressing
certain problems.

Last June, DHS relinquished control of STIX, CybOX, and TAXII to OASIS
(an international standards body.) Whereas MITRE (under DHS oversight)
previously determined the direction of the standards, since the
transition to OASIS the entire community of interest controls
the standards via an open and democratic process.

How many of you have written code? It’s typical that you spend hours
writing code trying to explain the problem to the computer only to
discover once you have working code that finally you understand the
problem you were trying to solve. But then you’re left with a mess of
spaghetti code begging to be refactored.

We have labored long and hard to untangle our spaghetti.

STIX 1.x, while it solved real-world problems, was a bit of a mess.
The specification pushed the limits of what’s possible in XML. There
was so much optionality, so much extensibility, and so many ways of
expressing the same thing that writing code to parse arbitrary,
schema-valid STIX felt like trying to solve the halting problem. As a
result, there have been serious interoperability issues between
 implementations.

Since the move to OASIS, a core group of folks came together to do a
green-field refactoring of the language. These included threat
analysts, vendors, folks from numerous government agencies, the
open-source community, and CERTs - but all old hands at STIX. Having
learned from the mistakes of the past, we radically simplified the
language. As there was overwhelming disgust with XML, we moved to a
JSON-based serialization format. Rather than including everything and
the kitchen sink, we set as our goal to produce an MVP
(minimally-viable product) release. We collected and examined use
cases, measured the data actually being shared in the wild, and built
the specification around what was well-understood and useful today. We
removed unnecessary optionality, driven by the understanding that
interoperability is greatly helped when there is one clear way of
expressing a thing, reducing the level of idiomatic variance, and
hence making it much easier to rigorously parse any valid input.
(After all, there’s no point in promoting a lingua franca unless
everybody can easily speak and be understood.) We shifted away from a
monolithic, deeply nested data model to a graph-based model, and
promoted object relationships from embedded properties to first-class
objects so as to enable analysts to pivot more effectively in the
course of their investigations.

STIX 2.0-rc3 was released on Tuesday, which will most likely be the
final release of STIX 2.0. Vendors are already writing code for STIX
2.0. It’s here now. We’re already starting work on STIX 2.1. And all
this happened in the course of less than a year, which is remarkably
nimble for a standards body. (We couldn’t have done it without Slack
and Google Docs!)

Remember the nightmarish world of text-encoding schemes before UTF-8
became ubiquitous? We don’t live in that world any more. While there’s
still a lot of iso-8859 floating around out there, for the most part
the world uses UTF-8 and is much the better for it. I’ll draw the
analogy to STIX. I don’t believe for a second that there will ever be
one universal standard for CTI but in the near term STIX will be as
ubiquitous as UTF-8. So please don’t go building your own standard for
threat-intelligence until you’ve taken a hard look at STIX 2.0.

Now a brief word about CybOX. CybOX isn’t sexy, but it’s the
foundation upon which STIX is built. CybOX is a data model that allows
you to express facts about, well, cyber stuff. Things like IP
addresses, file hashes, Windows registry keys, HTTP session data, etc.
STIX Indicators are built on top of CybOX to allow you to assert, “If
you see x followed by y, that’s probably bad.”

The fact that CybOX was even a thing was due to the historical
accident that MITRE developed it before they got round to doing STIX.
But as a TC we realized that it didn’t make sense for a critical
component of STIX to exist as its own separate standard, so we merged
it into STIX 2.0. CybOX is no longer a thing. It’s now called STIX
Cyber Observables. The old CybOX data model was a sprawling mess, as
if somebody threw a bunch of RFCs into a blender and XML Schemas
popped out. My co-chair Ivan Kirillov and I wanted to pare back the
data model (adhering to our MVP philosophy) and focus our refactoring
efforts on the aspects which people actually use today.

But we faced a major challenge: for all the talk of
information-sharing, most of the sharing goes on inside of closed
communities and secret squirrel clubs. So we created a tool called
cti-stats that these closed communities could run against their
CTI repositories to collect counts of STIX and CybOX types. Having
aggregated data from a number of major ISACs, ISAOs, CERTs, and other
CTI providers, some interesting patterns emerged.

Overwhelmingly, we saw people sharing Indicators; based on our
measurements, we’re talking about 96.47% of the STIX objects out there
in the wild. Of the 88 existing CybOX Observable types, we only saw 17
being actively used. Of these, 97.8% are Address, DomainName, File,
and URI. Which begs the question: are these four observable types so
dominant because they address the primary pain points, would people
like to be using other observable types more but don’t because of
issues with how those types are currently defined, or is this
indicative of the general level of maturity within the wider CTI
 ecosystem?

Feel free to review the numbers yourself. They’re
freely available in aggregate form and you can draw your own
 conclusions.

Reviewing this dataset, I was frankly shocked to see little to no
evidence of people sharing higher level constructs associated with
incidents (ie, Incident or Exploit Target) or attribution (ie,
Campaign or Threat Actor). After all, the ability to put such
higher-level context around IOCs is one of the main selling points for
STIX itself.

But you can’t measure what you can’t see. Based on a number of private
conversations I’ve had, I know that people are sharing this sort of
higher-level context but doing so through bilateral trust
relationships rather than broadcasting to their wider sharing
 communities.

Which raises some larger questions: what are the obstacles to scaling
up trust and what are the problems we seek to solve with CTI. I see
three basic problem spaces:

• detecting active compromise and doing incident response;
• proactively preventing compromise through indicator-based blacklisting;
• gaining insight into who is targeting us and what motivates them.

There’s clearly a spectrum of maturity across different organizations.
It’s been frequently said that in order to leverage CTI, you have to
already be doing security fundamentals well, you must be this tall to
 ride:

• know everything on your network
• have a clear baseline of what normal activity looks like
• have solid telemetry from your network and endpoints
• know what your most critical assets are and focus controls around
   them
• have a SIEM-like system for correlating the aforementioned telemetry
  and searching that for IOCs

That’s easy to say but it’s not easy to do. I hope that the majority
of companies and institutions are now sufficiently aware of the need
to improve their security posture but based on my own observations I
posit that most struggle to achieve the basics I just enumerated.

Earlier this year I spent a day whiteboarding with the SOC team at a
major bank you’ve all heard of. At one point, I asked them, “What do
you have for endpoint telemetry? Bit9+Carbon Black? Tanium? GRR?” And
they were like, “We have nothing. We can’t afford it.” And I was like,
“Seriously, guys, you literally have a license to print money and you
can’t afford endpoint telemetry?” So it’s not only the little guys.

The 2015 DBIR included a fascinating analysis of the useful
lifespan of indicators, which suggested that in terms of proactively
blacklisting C2 associated with active campaigns, the vast majority of
indicators are useful for a day or less. Assuming that the DBIR
analysis is correct, an obvious corollary is that the majority of IOCs
out there are only useful for detecting and responding to fait
accompli compromise. But if you’re been following the DBIR over the
last few years, it’s clear from the data that most organizations take
a very long time to detect breaches.

That supports my assertion that the vast majority of companies and
institutions have a low level of security maturity. Now, given that,
if I’m a high-maturity organization and I have some really hot intel
about an active campaign, how likely am I to broadcast that widely
within my sharing community, knowing that most recipients lack the
capability to utilize it in a timely fashion? Moreover, once the
threat actors become aware of this hot intel, they’re going to shift
their C2, and suddenly this high-value data is only good for detecting
compromise. If I perceive that most participants in my sharing
community are low-maturity, why would I think that they would even be
capable of protecting the confidentiality of my hot data from threat
 actors?

It’s not enough to just share IOCs. Within these trusted sharing
communities, higher-maturity organizations need to help the others
(including those falling below the security poverty line) grow up. One
thing that would help would be sharing data around the
cost-effectiveness of security controls (both in terms of purchase
price and staffing requirements to manage them.) Purchasing
decisions are frequently made on the basis of somebody reading a
random article in CSO magazine or (at best) based on a Gartner report.
But all too often, infosec vendors sell tools that don’t do what they
claim to. For a smaller organization, once that money is spent,
they’re committed, shitty tool or no.

I am bloody sick of hearing the phrase, “You’re doing it wrong.” To
paraphrase the inimitable Chris Nickerson, “The first time you point
your finger at another person and say they’re the problem, that’s the
point when you should go educate them. Every subsequent time you point
your finger at them and call them the problem you’re just highlighting
your continuing failure to educate them.” Let’s cut it out with all
the “you’re doing it wrong” talk and start showing people the right
way. This is also information-sharing.

At the 2015 FIRST conference in Berlin, the Cisco CSIRT team launched
an O’Reilly book they co-wrote entitled “Crafting the InfoSec
Playbook”. If you haven’t already read it, I highly recommend you
order a copy today. Several years ago I had the privilege of
spending a few days onsite with the Cisco team and witnessed firsthand
how they drive their security operation around hard metrics. It was
truly impressive! They’re constantly measuring the effectiveness of
their tools, but moreover how those tools are used (ie, COAs).

Earlier I argued that we just need to “hold shit together” a few more
years while our cultural institutions catch up with our tech. An
integral part of that is for more higher-maturity organizations to
collect and share the sort of security metrics exemplified by the
work of the Cisco CSIRT team within their respective sharing
communities. If BigCompany bought SIEMx, wasted 18 months trying to
get it tuned, ripped it out, and replaced it with SIEMy, that war
story might be vitally helpful to smaller firms facing a purchasing
decision. I’m sure there’s plenty of this sort of information-sharing
already going on. We need more of it.

A word about SIEMs. Commercial SIEMs are not cheap. There are halfway
decent open-source alternatives. Surely I don’t have to say it, but
what a SIEM gives you is the ability to correlate whatever network and
endpoint telemetry you have and search it. The Cisco “Security
Playbook” I mentioned a second ago clearly shows how their entire
security operation hinges around their SIEM. They’ve written it in as
vendor-neutral a manner as possible but you can tell from the
screenshots that (at least at the time of writing) they were running
 Splunk.

Back when I first started looking at STIX it immediately jumped out at
me that here was a nascent abstraction layer for interchanging SIEM
correlation rules in a vendor-neutral manner. On the STIX side, you
have this taxonomy of things to look for and a patterning language for
saying “If you see x and you see y, that’s bad. If you also see z,
that’s a false positive.” How is that essentially different from a
SIEM correlation rule?

STIX 2.0 encompasses a greenfield refactoring of the old STIX data
model as well as the Cyber Observable data model, but it also includes
something altogether new: the STIX Patterning Language. My vision of
an abstraction layer for SIEM correlation rules was shared by others
within the CTI TC. Accordingly, we spun up a working group. Not
wanting to reinvent the wheel, we looked for an open standard that
encompassed both writing patterns around network and host-based
artifacts. Not finding any, we looked at whether we could extend
either Snort or Yara. For various reasons that proved unfeasible.
Forthwith, we labored long and hard to create the STIX Patterning
language. Like the rest of STIX 2.0, it’s an MVP release, but
nonetheless powerful. As we iterate through point releases, we’re
excited about enabling distributed, collaborative development of SIEM
correlation rules in a vendor-neutral abstraction layer.

A critical part of SIEM vendors’ sales pitch is how many correlation
rules they ship with, out of the box. But what they don’t tell you is
that most of these are pretty useless to your organization without a
good deal of tuning. So then you wind up paying big bucks for a SIEM
and then you pay big bucks for the SIEM vendor’s professional services
people to come spend a few days or weeks tuning the correlation rules
to your particular systems and needs.

Now one of the really cool things that the Cisco CSIRT do is to
constantly tweak the correlation rules driving their operation and
simultaneously collect performance metrics on those edits. Now
imagine, if you will, a world in which SIEM vendors supported
importing and exporting correlation rules via STIX. This would enable
higher-maturity organizations to collaboratively improve the ability
of those correlation rules to find the evil needle in the haystack. It
would also allow lower-maturity organizations to dramatically improve
their ability to detect badness in a timely fashion. This, in turn,
should drive down the average time to breach detection. As the
lower-maturity organizations are able to respond more quickly to
breaches, the average impact should also decrease (ie, if the
attackers are detected earlier, they have less time to pivot across an
organization.) This in turn frees up resources, allowing these
lower-maturity organizations to up their game and start doing more of
the proactive blocking and tackling. As the overall security maturity
level increases within a sharing community, this should improve the
level of trust, facilitating more widespread sharing of higher-value
intel. A rising tide of structured threat data lifts all boats.

But enough about SIEM, back to the world of OASIS. Like I mentioned,
we’re starting to work on STIX 2.1. What’s on the docket?

• i18n
• malware characterization
• incorporating OpenC2 into the STIX COA model
• fleshing out the Observable data model
• adding additional capabilities to the Patterning language

Our goal for STIX 2.0 was to produce a solid MVP release quickly
(which we have done) and then to iterate rapidly through a series of
point-releases, adding capabilities while maintaining backward
 compatibility.

How can you help? Two things:

1) If you’re making a purchasing decision, consider adding STIX 2.0
support to your RFP. If you’re building, consider adding support for
STIX 2.0 to your tools.

2) My co-chair Ivan and I don’t know everything. If you have SMEs
within your organization who can help us to flesh out the STIX
Observable data model and corresponding Patterning language for
topical areas mobile malware, SDN, virtualized/cloud-based metadata,
network and endpoint forensics, ICS, IOT, etc, please reach out. We
can’t possibly be experts at everything but we’re rapidly becoming
experts at cat-herding SMEs to assemble a coherent standard.