start	end	text
0	5700	of ATT&CK for ICS, and that's what I'll be talking about today, give you a little introduction,
5700	10920	and also talk about some use cases centered around testbeds, which I think is relevant to
10920	17220	the ICS village. So feel free to use the link here, ATT&CK.Meijer.Org for slash ICS,
17220	21000	if you want to take a look at the knowledge base while I'm talking,
21000	24400	and also feel free to reach out to me on Twitter.
26400	35940	So ATT&CK for ICS was released this year in January, and the real purpose of this knowledge
35940	42700	base is to look at how adversaries have affected critical infrastructure in the past. So really
42700	49340	looking at their behaviors, tactics, techniques, and procedures associated with the attacks, and
49340	57880	what the ultimate impacts of those attacks are. So since its release, we've gotten a lot of
57880	66600	adoption, a lot of attention. Some of the security vendors here have released blog posts and
66600	73080	presentations showing how they use ATT&CK for ICS and how they envision their customers using it.
73080	78940	Also, asset owners and operators are looking at how they can use it to kind of fill gaps and to
78940	85600	understand their environments a little bit better. So for those who aren't familiar with
85600	93460	ATT&CK, what is ATT&CK? Well, it's a knowledge base of adversary behavior, and it's based on
93460	99620	real-world observation. So that's what adversaries are doing in the wild, what credible red teamers
99620	106340	are doing, and things like that. I think good news for everybody is it's free, open, and globally
106340	114120	accessible. So I gave you a link at the beginning, ATT&CK.meyer.org for slash ICS. Any of you can go
114120	122120	and look at the knowledge base at any time. It also provides a common language for how we talk
122660	131440	between defenders, red teamers, to business people. It really allows us to all get on the same page,
131440	137480	and I think that's very important for especially testbed activities when you have red teamers and
137480	145820	blue teamers. And it's community-driven, so we always look forward to contributions from the
145820	152100	community. If you think that there's something missing or if you know of some adversary activity,
152100	157940	you could always submit that and be a contributor to ATT&CK in general.
159520	168340	So this is a common representation of ATT&CK. You'll see this across the multiple technology domains and
169360	177320	knowledge bases. This is a technique matrix. And across the top, you have what are called tactics,
177320	183560	which are the adversary's technical goals. So this ranges here on the ATT&CK for ICS technique
183560	190920	matrix from initial access to discovery to inhibit response function and peer process control
190920	197360	impact. So those are some technical goals of the adversary. And associated with each of these
197360	205160	technical goals are techniques, and this is how the goal is accomplished. So this could be data
205160	211840	historian compromise under initial access. It could also be device restart or shutdown under
211840	218760	inhibit response function. And associated with each of the techniques, if you go to the site
218760	225320	and look at a particular technique page, is some specific technique implementation. And this is how
225320	231380	the adversary accomplished this high level technique. So looking at this all together,
231380	237260	you have the tactics, techniques, and procedures of adversaries, which really represents their
237260	247660	behavior and is the focus of ATT&CK. So on ATT&CK.meyer.org, you'll see a number of
247660	252360	knowledge bases that are associated with technology domains. So you'll see
253400	259220	enterprise, you'll see cloud, you'll see mobile, and now you see ICS up there as well.
259220	266040	Why do we have different knowledge bases? Well, in general, adversary motivations may be different
266040	274200	and they may be tightly coupled to the technology domain that they are targeting. So gaining access,
274200	279440	accomplishing your objective, all depends on the target and what you're actually going for.
279440	284520	So there's going to be some differences between enterprise systems and cyber physical systems.
284520	290540	There's also different phases in the life cycle, which means there's different choices. So that
290540	296000	also influences our decision to create a new knowledge base. And then when we get to the
296000	301720	technologies, there's some real differences there. So how the adversaries interact with particular
301720	307580	systems really depends on that system. So how an adversary moves through an enterprise system
307580	314960	is different than how they may affect an embedded controller or something like that. It's things
314960	321880	that we have to take into consideration. And then when we get to defense, we have to think about
321880	329860	how are we collecting data to get information about what adversaries have done. We can always
329860	335500	use network data, but what about low-level devices? How do we collect data from them?
335500	340900	Are there standard interfaces for collecting that data? What can we expect from them?
340900	346660	Also, in terms of mitigations, we don't want to recommend mitigations that are going to conflict
346660	352200	with safety or availability of the system. So we really have to think hard about that. These are
352200	357800	all just some high-level reasons why we came up with a different knowledge base to really talk
357800	366220	about adversaries in the ICS technology domain. So this is a representation of an industrial
366220	373000	control system. Most of us are familiar with it as a Purdue reference architecture. We think of it
373000	378380	as functional levels of an industrial control system. And some of these levels are associated
378380	384960	with traditional IT, and some of them are more operational technology focused, although they have
384960	391880	IT elements in them. So when we're looking at an incident and we're decomposing it or mapping it
391880	399200	to ATT&CK, what we first do is try to think about what technology domain the adversary affected
399200	405720	first. And sometimes that's the enterprise technology domain. So what we'll do is we'll
405720	411640	use enterprise ATT&CK to go as far as we can in terms of explaining the adversary behavior.
411640	416440	As we get down to the lower levels and we start talking about specialized protocols, specialized
416440	423560	applications, and specialized equipment, we really need ATT&CK for ICS to tell the rest of the story.
423560	432020	So it really fills in the entire picture. So back to the technology technique matrix for ATT&CK for
432020	440760	ICS. Let's break it down really quick. So if we look at the first tactics, a couple of tactics or
441360	447740	it really represents the adversary finding their target, collecting information, and ultimately
447740	454820	staging an attack. So initial access is how we get in. We may try to find our target by using
454820	461520	discovery techniques. And then we may need to get specific information. So we may have to do some
461520	466420	collection to understand the state of the system or state of the process at any point in time.
467080	472320	Then inhibit response function and impair process control is the adversary directly
472320	477620	affecting the control system. So this is us sending unauthorized command messages. Maybe
477620	483200	we do a program download with a malicious program, different things like that, in order to actually
483700	490620	affect the control system. And last, we have our impacts, which is really what the adversary is
490620	495980	seeking to create. Are we trying to create a loss of control? Are we trying to damage property as
495980	502800	an adversary? This tactic really contains those types of techniques. So this is just a quick
502800	511520	breakdown of ATT&CK and ATT&CK for ICS and what's contained in it. It's really based off of what
511520	516960	we've seen in the wild. So that could be kind of limiting for us, especially if we want to have fun
516960	522740	in a testbed environment or learn about what particular techniques look like. So what I'll
522740	528580	be talking about next is a way that we can kind of structure our activities in a testbed environment,
528580	536100	specifically on ICS Village when we're working in it as adversaries. So something that we can use
536100	543200	are failure and ATT&CK scenarios. I'll explain what those are and how they can help structure
543200	550660	our activities. So failure scenarios include malicious and non-malicious cybersecurity
550660	556640	events. And these can range from compromising equipment functionality to data integrity
556640	564180	attacks to communication failures and more. And these have a lot of uses. They can be used for
564180	569800	risk assessment. They can be used for training. Tabletop exercises is something that they're
569800	576140	very popular for. But they can also be used for like security tests and testbed. So examples of
576140	582520	sources of data for failure scenarios, really understanding how these systems fell and where
582520	587580	are the causes of them could come from subject matter experts. So people who operate these
587580	594280	systems. It could also come from researchers. They could come from incident repositories. So how do
594280	601060	real life systems fail and what were the causes and consequences of those failures? So this could
601060	610020	be NTSB databases, FEMSA or pipeline databases, or even more. And then there's also scenario
610020	615520	repositories. These are subject matter experts have gotten together and talked about different
615520	621440	failures that can happen. And they've provided us a repository of failures that we can just work
621440	628500	from, such as the every NEST Core failure scenarios. So let's look at some example failure scenarios.
628500	635680	These come from researchers who are power engineers and they released a research document
635680	642840	through the IEEE that kind of details some failure scenarios that are interesting. So scenario one
642840	650900	is transformer overloading. So in this particular scenario, what the objective of the adversary is,
650900	656440	is to rapidly deteriorate transformer installation. And this really represents one of those low and
656440	662640	attacks that damage long lead time pieces of equipment. So the technique here is basically to
664500	671260	set or modify trip settings so that if there's an overcurrent or thermal condition that the
671260	678320	protective relay doesn't step in to kind of correct the condition. Then we also want to
678320	683340	block communications so that operator doesn't understand what's going on. And then we want to
683340	690140	force all the power through one transformer to bear the load. So this rapidly heats up the
690140	696400	transformer and degrades its installation. Scenario two, we're disrupting switching execution for
696400	703420	circuit breaker and isolators and we're causing dielectric breakdown of that breaker and isolator.
703420	709600	So what we're doing here is we're continuously executing switching actions to take this piece
709600	715580	of equipment out and we're blocking comms to kind of hide our actions. And then scenario three is
715580	722480	kind of that typical Ukraine type attack where we're just opening breakers and we're trying to
722480	730380	cause entire substation outages and whatever contingencies come along with it. So we can start
730380	736920	to structure this failure scenario so that we understand exactly what we're trying to accomplish.
736920	742500	If we take scenario one, the transformer overloading, we can think about what the consequence is. The
742500	747580	consequence is a thermal breakdown of transformer installation. Then we have a couple failure modes.
747580	756000	We don't want the protector relay to trip. So we're going to put improper overcurrent and
756000	760980	thermal settings in it. And then we also want one of the transformers to bear all the load. So we
760980	766900	have to open the breaker to the other transformers that are in the system. So we could do this by
766920	773420	modifying parameters, which is the attack technique, and sending an unauthorized command message. So now
773420	781480	we have a full story of how we're going to cause this thermal breakdown of the transformer. Now
781480	786380	something that we have to consider is how do we can sustain this attack? What do we need to do
786380	793260	to make sure that this attack can continue so we get our ultimate consequence? Well, here what we
793260	798660	want to do is make the operator unable to react to the critical condition. And one of the ways we
798660	803660	can do that is by causing a loss of view into the substation by manipulating communications.
803820	809420	So the attack techniques that we can use here are block reporting message and alarm suppression.
810760	817620	So now we know what we want to accomplish. We're not just fiddling around in a test bed environment
818400	824580	with no ultimate goal. So what's next? So now we can build our attack scenario. We can think about
824580	832440	what's our entry point, how do we find our targets, how do we sustain our attack, and how do we cause
832600	838020	a failure, and even more. So in terms of entry points, maybe it's that we need an engineering
838020	843340	workstation or to accomplish this attack or something that serves that function. And maybe
843340	849420	we look for external remote services like a VPN connection or something that allows us to get
849420	854680	connection to this engineering workstation. And then in terms of finding our target, we have to
854680	861660	probably do some discovery. We could do network sniffing, we could do control device identification,
861660	867440	or we could do network service scanning. And then to sustain our attack, what we want to do
867440	874820	is maybe block reporting messages so that certain voltage or current values don't make their way up
874820	881300	to the operator. Or we may want to do alarm suppression where we're stopping alarm messages
881300	887680	from going up to an operator. And then finally, to cause our failure, we want to use impaired
887680	896560	process control tactic techniques where we modify the overcurrent and thermal parameters,
896560	903020	and we send commands at the wrong time to open breakers. So now we're starting to build a real
903020	910680	story about what we want to do. So this is what a first pass at highlighting the relevant techniques
910680	917820	looks like. As we build on to our story and kind of validate that we can cause the failures that
917820	924820	we want, we may add additional techniques, things that go ahead, or we may have to fill in sort of
924820	929340	gaps in knowledge that we have by using a technique. But this really serves as a basis of
929340	936760	what we're doing in order to induce this failure. And something that we can do is dive really deep
936760	942320	into particular techniques. So for instance, unauthorized command message. We may not just
942320	946920	want to look at the description here. We may want to look at how adversaries have done this in the
946920	952640	past. So we have the Murchishire attack as an example. We have the 2015 Ukrainian power grid
952640	959560	attack. We also have particular implementations that we can look at, such as Indestroy or Stuxnet
959560	965120	to understand how unauthorized command messages were used. And if that's not enough, we also have
965120	971140	references. So you can dig even deeper into incident reports in order to understand exactly
971840	979920	why an adversary used this technique, what they used it for. And this really helps to build the
979920	987100	story around what we're doing within our testbed environment. So another thing we have to consider
987100	993400	is data sources. And data sources are very valuable for defenders, but they should also
993400	1000820	be considered from the adversary standpoint as well. So what artifacts am I leaving behind as
1000820	1007120	the adversary? We need to understand what our activities look like to the defender. This is
1007120	1012430	very interesting when we're in a testbed environment. Where are we leaving behind?
1013040	1018280	And most people look at network traffic in terms of defense, but there's also a lot of
1018280	1025160	other rich data sources that are overlooked often. So host-based logs housed on embedded
1025160	1031800	OT devices such as controllers are interesting. There's also asset management data associated
1031800	1038600	with equipment under control that we can look at. So we've done a lot of surveys of devices
1038600	1045460	to understand what data sources are on them. And we've come up with some high-level categories of
1045460	1050740	data sources on low-level controllers. And I've kind of highlighted some of the ones that are most
1050740	1056100	relevant to the scenario that we've already presented. So we may want to look at parameters
1056100	1062540	on the device. And we could do this in integrity, periodic integrity checks on the parameters to see
1062540	1068720	if they've remained the same, if they've gone outside of our original threshold. There's alarms
1069600	1074320	that are generated at these devices and stored at these devices before they're sent. So we can
1074320	1079700	look at those. There's event logs such as the sequential event recorder that contain a wealth
1079700	1085080	of information about commands that have been executed or parameter changes or anything else
1085080	1090280	like that. But we have asset management data. We can look at condition-based monitoring,
1090280	1096640	understand particular parameters about that transformer such as thermal parameters to
1096640	1100520	understand if it's overheating. And there's a number of other data sources that we can look
1100520	1106940	at. But we want to be aware of what our activities look like from the defender's perspective.
1108240	1114860	So here are some data source considerations that we can have as we're working in these
1114860	1121400	environments. So is this data source able to be accessed via a standard interface, a documented
1121400	1128680	interface? That's very important for access to that data source. What's the storage size of that
1128680	1135240	source? Will it eventually roll over? Is there a lot of noise in the data source? Would it be hard
1135240	1142620	for a defender to kind of look through it? And then are there standard commands that are available
1142620	1149100	to just delete that data source? And then another thing we can consider is does the data source get
1149100	1155040	replicated to other places? So if we're looking at a low-level protection relay, does it go up to
1155040	1161060	another controller? The particular data sources that we're looking at,
1161060	1165940	there may be aggregation points somewhere. So these are all things that we have to consider.
1166060	1171080	So let's take another look at this overall process that I'm proposing to kind of structure your
1171080	1176920	activities in the testbed. So first, we want to understand failures associated with your target
1176920	1182460	system. For our target system, we were looking at a transmission substation, for instance.
1182460	1189500	We want to build an attack scenario around your chosen failure scenario. So how do we induce this
1189500	1195340	failure via cyber means? We want to build a story around it about what the adversary is actually
1195340	1199680	trying to accomplish. What's the bigger goal? By researching how and why adversaries have caused
1199680	1205120	similar failures in the past. We want to conduct the attack, and that includes implementing
1205660	1210860	certain techniques and see if we can induce the failure in our system. This may take multiple
1210860	1217040	times. We want to understand which data sources contain indicators of our attack.
1217260	1221280	And then finally, if we're purple teaming or working together with blue teamers,
1221280	1225660	we want to talk about our activities using the artifacts from our structured attack plan. So
1225660	1231480	that may be, we show them what our failure looks like that we're trying to induce. We can show them
1233080	1237140	a technique matrix with the right techniques highlighted, and we can share with them what
1237140	1242080	data sources they should look at. And that could kind of help us to work together in order to
1242570	1247430	figure out new things in the testbed environment and to communicate more efficiently.
1248700	1257300	So some key takeaways. It can be very helpful to build a full story around your testbed activities
1257300	1265340	by documenting failure and attack scenarios. So sometimes the reaction is just to hop on the
1265340	1272400	testbed and to see what's going to happen and just go with it. But structuring our activities
1272400	1279740	using ATT&CK for ICS can really help communicate what we're doing. And those things are all
1279740	1285160	reusable in the future. So we also want to make sure we understand what artifacts we're leaving
1285160	1293500	behind. And we want to work closely with defenders as purple teams. So really quick, because I'm
1293500	1301060	almost out of time, what's new for ATT&CK for ICS? So on the horizon, we do have technique updates.
1301140	1304700	So that's new adversary behavior and additional references.
1304880	1310260	We're adding mitigations to each technique as well. So we have to consider all our stakeholders
1310260	1316160	here. Device vendors are very important because a lot of the insecure by design
1317960	1322740	problems that we see with these devices start there. So we want to tell them what they can do
1322740	1327440	to address some of this adversary behavior, as well as like asset owners, what they can do at
1327440	1335040	their level. It's going to include many references to standard bodies such as IEC, ISA, NIST. And it's
1335040	1343580	really focused around adversary use of techniques and then how interfaces are used or what their
1343580	1351660	functionality is, and then also the impacts. So the last couple of things are we're starting to
1352300	1358280	integrate more with traditional ATT&CK tools that people are used to using. So
1358280	1365700	ATT&CK for ICS will have a STIX representation and we're also integrating it
1365700	1370680	with ATT&CK Navigator. So those are some things that you can look forward to in the future and
1370680	1381000	hopefully help everybody to use the knowledge base more. So that's all I have. Please feel
1381000	1385580	free to visit attack.mitre.org forward slash ICS to look at the knowledge base
1385580	1388440	and reach out to me on Twitter if you have any questions.