of ATT&CK for ICS, and that's what I'll be talking about today, give you a little introduction,
and also talk about some use cases centered around testbeds, which I think is relevant to
the ICS village. So feel free to use the link here, ATT&CK.Meijer.Org for slash ICS,
if you want to take a look at the knowledge base while I'm talking,
and also feel free to reach out to me on Twitter.
So ATT&CK for ICS was released this year in January, and the real purpose of this knowledge
base is to look at how adversaries have affected critical infrastructure in the past. So really
looking at their behaviors, tactics, techniques, and procedures associated with the attacks, and
what the ultimate impacts of those attacks are. So since its release, we've gotten a lot of
adoption, a lot of attention. Some of the security vendors here have released blog posts and
presentations showing how they use ATT&CK for ICS and how they envision their customers using it.
Also, asset owners and operators are looking at how they can use it to kind of fill gaps and to
understand their environments a little bit better. So for those who aren't familiar with
ATT&CK, what is ATT&CK? Well, it's a knowledge base of adversary behavior, and it's based on
real-world observation. So that's what adversaries are doing in the wild, what credible red teamers
are doing, and things like that. I think good news for everybody is it's free, open, and globally
accessible. So I gave you a link at the beginning, ATT&CK.meyer.org for slash ICS. Any of you can go
and look at the knowledge base at any time. It also provides a common language for how we talk
between defenders, red teamers, to business people. It really allows us to all get on the same page,
and I think that's very important for especially testbed activities when you have red teamers and
blue teamers. And it's community-driven, so we always look forward to contributions from the
community. If you think that there's something missing or if you know of some adversary activity,
you could always submit that and be a contributor to ATT&CK in general.
So this is a common representation of ATT&CK. You'll see this across the multiple technology domains and
knowledge bases. This is a technique matrix. And across the top, you have what are called tactics,
which are the adversary's technical goals. So this ranges here on the ATT&CK for ICS technique
matrix from initial access to discovery to inhibit response function and peer process control
impact. So those are some technical goals of the adversary. And associated with each of these
technical goals are techniques, and this is how the goal is accomplished. So this could be data
historian compromise under initial access. It could also be device restart or shutdown under
inhibit response function. And associated with each of the techniques, if you go to the site
and look at a particular technique page, is some specific technique implementation. And this is how
the adversary accomplished this high level technique. So looking at this all together,
you have the tactics, techniques, and procedures of adversaries, which really represents their
behavior and is the focus of ATT&CK. So on ATT&CK.meyer.org, you'll see a number of
knowledge bases that are associated with technology domains. So you'll see
enterprise, you'll see cloud, you'll see mobile, and now you see ICS up there as well.
Why do we have different knowledge bases? Well, in general, adversary motivations may be different
and they may be tightly coupled to the technology domain that they are targeting. So gaining access,
accomplishing your objective, all depends on the target and what you're actually going for.
So there's going to be some differences between enterprise systems and cyber physical systems.
There's also different phases in the life cycle, which means there's different choices. So that
also influences our decision to create a new knowledge base. And then when we get to the
technologies, there's some real differences there. So how the adversaries interact with particular
systems really depends on that system. So how an adversary moves through an enterprise system
is different than how they may affect an embedded controller or something like that. It's things
that we have to take into consideration. And then when we get to defense, we have to think about
how are we collecting data to get information about what adversaries have done. We can always
use network data, but what about low-level devices? How do we collect data from them?
Are there standard interfaces for collecting that data? What can we expect from them?
Also, in terms of mitigations, we don't want to recommend mitigations that are going to conflict
with safety or availability of the system. So we really have to think hard about that. These are
all just some high-level reasons why we came up with a different knowledge base to really talk
about adversaries in the ICS technology domain. So this is a representation of an industrial
control system. Most of us are familiar with it as a Purdue reference architecture. We think of it
as functional levels of an industrial control system. And some of these levels are associated
with traditional IT, and some of them are more operational technology focused, although they have
IT elements in them. So when we're looking at an incident and we're decomposing it or mapping it
to ATT&CK, what we first do is try to think about what technology domain the adversary affected
first. And sometimes that's the enterprise technology domain. So what we'll do is we'll
use enterprise ATT&CK to go as far as we can in terms of explaining the adversary behavior.
As we get down to the lower levels and we start talking about specialized protocols, specialized
applications, and specialized equipment, we really need ATT&CK for ICS to tell the rest of the story.
So it really fills in the entire picture. So back to the technology technique matrix for ATT&CK for
ICS. Let's break it down really quick. So if we look at the first tactics, a couple of tactics or
it really represents the adversary finding their target, collecting information, and ultimately
staging an attack. So initial access is how we get in. We may try to find our target by using
discovery techniques. And then we may need to get specific information. So we may have to do some
collection to understand the state of the system or state of the process at any point in time.
Then inhibit response function and impair process control is the adversary directly
affecting the control system. So this is us sending unauthorized command messages. Maybe
we do a program download with a malicious program, different things like that, in order to actually
affect the control system. And last, we have our impacts, which is really what the adversary is
seeking to create. Are we trying to create a loss of control? Are we trying to damage property as
an adversary? This tactic really contains those types of techniques. So this is just a quick
breakdown of ATT&CK and ATT&CK for ICS and what's contained in it. It's really based off of what
we've seen in the wild. So that could be kind of limiting for us, especially if we want to have fun
in a testbed environment or learn about what particular techniques look like. So what I'll
be talking about next is a way that we can kind of structure our activities in a testbed environment,
specifically on ICS Village when we're working in it as adversaries. So something that we can use
are failure and ATT&CK scenarios. I'll explain what those are and how they can help structure
our activities. So failure scenarios include malicious and non-malicious cybersecurity
events. And these can range from compromising equipment functionality to data integrity
attacks to communication failures and more. And these have a lot of uses. They can be used for
risk assessment. They can be used for training. Tabletop exercises is something that they're
very popular for. But they can also be used for like security tests and testbed. So examples of
sources of data for failure scenarios, really understanding how these systems fell and where
are the causes of them could come from subject matter experts. So people who operate these
systems. It could also come from researchers. They could come from incident repositories. So how do
real life systems fail and what were the causes and consequences of those failures? So this could
be NTSB databases, FEMSA or pipeline databases, or even more. And then there's also scenario
repositories. These are subject matter experts have gotten together and talked about different
failures that can happen. And they've provided us a repository of failures that we can just work
from, such as the every NEST Core failure scenarios. So let's look at some example failure scenarios.
These come from researchers who are power engineers and they released a research document
through the IEEE that kind of details some failure scenarios that are interesting. So scenario one
is transformer overloading. So in this particular scenario, what the objective of the adversary is,
is to rapidly deteriorate transformer installation. And this really represents one of those low and
attacks that damage long lead time pieces of equipment. So the technique here is basically to
set or modify trip settings so that if there's an overcurrent or thermal condition that the
protective relay doesn't step in to kind of correct the condition. Then we also want to
block communications so that operator doesn't understand what's going on. And then we want to
force all the power through one transformer to bear the load. So this rapidly heats up the
transformer and degrades its installation. Scenario two, we're disrupting switching execution for
circuit breaker and isolators and we're causing dielectric breakdown of that breaker and isolator.
So what we're doing here is we're continuously executing switching actions to take this piece
of equipment out and we're blocking comms to kind of hide our actions. And then scenario three is
kind of that typical Ukraine type attack where we're just opening breakers and we're trying to
cause entire substation outages and whatever contingencies come along with it. So we can start
to structure this failure scenario so that we understand exactly what we're trying to accomplish.
If we take scenario one, the transformer overloading, we can think about what the consequence is. The
consequence is a thermal breakdown of transformer installation. Then we have a couple failure modes.
We don't want the protector relay to trip. So we're going to put improper overcurrent and
thermal settings in it. And then we also want one of the transformers to bear all the load. So we
have to open the breaker to the other transformers that are in the system. So we could do this by
modifying parameters, which is the attack technique, and sending an unauthorized command message. So now
we have a full story of how we're going to cause this thermal breakdown of the transformer. Now
something that we have to consider is how do we can sustain this attack? What do we need to do
to make sure that this attack can continue so we get our ultimate consequence? Well, here what we
want to do is make the operator unable to react to the critical condition. And one of the ways we
can do that is by causing a loss of view into the substation by manipulating communications.
So the attack techniques that we can use here are block reporting message and alarm suppression.
So now we know what we want to accomplish. We're not just fiddling around in a test bed environment
with no ultimate goal. So what's next? So now we can build our attack scenario. We can think about
what's our entry point, how do we find our targets, how do we sustain our attack, and how do we cause
a failure, and even more. So in terms of entry points, maybe it's that we need an engineering
workstation or to accomplish this attack or something that serves that function. And maybe
we look for external remote services like a VPN connection or something that allows us to get
connection to this engineering workstation. And then in terms of finding our target, we have to
probably do some discovery. We could do network sniffing, we could do control device identification,
or we could do network service scanning. And then to sustain our attack, what we want to do
is maybe block reporting messages so that certain voltage or current values don't make their way up
to the operator. Or we may want to do alarm suppression where we're stopping alarm messages
from going up to an operator. And then finally, to cause our failure, we want to use impaired
process control tactic techniques where we modify the overcurrent and thermal parameters,
and we send commands at the wrong time to open breakers. So now we're starting to build a real
story about what we want to do. So this is what a first pass at highlighting the relevant techniques
looks like. As we build on to our story and kind of validate that we can cause the failures that
we want, we may add additional techniques, things that go ahead, or we may have to fill in sort of
gaps in knowledge that we have by using a technique. But this really serves as a basis of
what we're doing in order to induce this failure. And something that we can do is dive really deep
into particular techniques. So for instance, unauthorized command message. We may not just
want to look at the description here. We may want to look at how adversaries have done this in the
past. So we have the Murchishire attack as an example. We have the 2015 Ukrainian power grid
attack. We also have particular implementations that we can look at, such as Indestroy or Stuxnet
to understand how unauthorized command messages were used. And if that's not enough, we also have
references. So you can dig even deeper into incident reports in order to understand exactly
why an adversary used this technique, what they used it for. And this really helps to build the
story around what we're doing within our testbed environment. So another thing we have to consider
is data sources. And data sources are very valuable for defenders, but they should also
be considered from the adversary standpoint as well. So what artifacts am I leaving behind as
the adversary? We need to understand what our activities look like to the defender. This is
very interesting when we're in a testbed environment. Where are we leaving behind?
And most people look at network traffic in terms of defense, but there's also a lot of
other rich data sources that are overlooked often. So host-based logs housed on embedded
OT devices such as controllers are interesting. There's also asset management data associated
with equipment under control that we can look at. So we've done a lot of surveys of devices
to understand what data sources are on them. And we've come up with some high-level categories of
data sources on low-level controllers. And I've kind of highlighted some of the ones that are most
relevant to the scenario that we've already presented. So we may want to look at parameters
on the device. And we could do this in integrity, periodic integrity checks on the parameters to see
if they've remained the same, if they've gone outside of our original threshold. There's alarms
that are generated at these devices and stored at these devices before they're sent. So we can
look at those. There's event logs such as the sequential event recorder that contain a wealth
of information about commands that have been executed or parameter changes or anything else
like that. But we have asset management data. We can look at condition-based monitoring,
understand particular parameters about that transformer such as thermal parameters to
understand if it's overheating. And there's a number of other data sources that we can look
at. But we want to be aware of what our activities look like from the defender's perspective.
So here are some data source considerations that we can have as we're working in these
environments. So is this data source able to be accessed via a standard interface, a documented
interface? That's very important for access to that data source. What's the storage size of that
source? Will it eventually roll over? Is there a lot of noise in the data source? Would it be hard
for a defender to kind of look through it? And then are there standard commands that are available
to just delete that data source? And then another thing we can consider is does the data source get
replicated to other places? So if we're looking at a low-level protection relay, does it go up to
another controller? The particular data sources that we're looking at,
there may be aggregation points somewhere. So these are all things that we have to consider.
So let's take another look at this overall process that I'm proposing to kind of structure your
activities in the testbed. So first, we want to understand failures associated with your target
system. For our target system, we were looking at a transmission substation, for instance.
We want to build an attack scenario around your chosen failure scenario. So how do we induce this
failure via cyber means? We want to build a story around it about what the adversary is actually
trying to accomplish. What's the bigger goal? By researching how and why adversaries have caused
similar failures in the past. We want to conduct the attack, and that includes implementing
certain techniques and see if we can induce the failure in our system. This may take multiple
times. We want to understand which data sources contain indicators of our attack.
And then finally, if we're purple teaming or working together with blue teamers,
we want to talk about our activities using the artifacts from our structured attack plan. So
that may be, we show them what our failure looks like that we're trying to induce. We can show them
a technique matrix with the right techniques highlighted, and we can share with them what
data sources they should look at. And that could kind of help us to work together in order to
figure out new things in the testbed environment and to communicate more efficiently.
So some key takeaways. It can be very helpful to build a full story around your testbed activities
by documenting failure and attack scenarios. So sometimes the reaction is just to hop on the
testbed and to see what's going to happen and just go with it. But structuring our activities
using ATT&CK for ICS can really help communicate what we're doing. And those things are all
reusable in the future. So we also want to make sure we understand what artifacts we're leaving
behind. And we want to work closely with defenders as purple teams. So really quick, because I'm
almost out of time, what's new for ATT&CK for ICS? So on the horizon, we do have technique updates.
So that's new adversary behavior and additional references.
We're adding mitigations to each technique as well. So we have to consider all our stakeholders
here. Device vendors are very important because a lot of the insecure by design
problems that we see with these devices start there. So we want to tell them what they can do
to address some of this adversary behavior, as well as like asset owners, what they can do at
their level. It's going to include many references to standard bodies such as IEC, ISA, NIST. And it's
really focused around adversary use of techniques and then how interfaces are used or what their
functionality is, and then also the impacts. So the last couple of things are we're starting to
integrate more with traditional ATT&CK tools that people are used to using. So
ATT&CK for ICS will have a STIX representation and we're also integrating it
with ATT&CK Navigator. So those are some things that you can look forward to in the future and
hopefully help everybody to use the knowledge base more. So that's all I have. Please feel
free to visit attack.mitre.org forward slash ICS to look at the knowledge base
and reach out to me on Twitter if you have any questions.