[00:00.000 --> 00:05.700] of ATT&CK for ICS, and that's what I'll be talking about today, give you a little introduction, [00:05.700 --> 00:10.920] and also talk about some use cases centered around testbeds, which I think is relevant to [00:10.920 --> 00:17.220] the ICS village. So feel free to use the link here, ATT&CK.Meijer.Org for slash ICS, [00:17.220 --> 00:21.000] if you want to take a look at the knowledge base while I'm talking, [00:21.000 --> 00:24.400] and also feel free to reach out to me on Twitter. [00:26.400 --> 00:35.940] So ATT&CK for ICS was released this year in January, and the real purpose of this knowledge [00:35.940 --> 00:42.700] base is to look at how adversaries have affected critical infrastructure in the past. So really [00:42.700 --> 00:49.340] looking at their behaviors, tactics, techniques, and procedures associated with the attacks, and [00:49.340 --> 00:57.880] what the ultimate impacts of those attacks are. So since its release, we've gotten a lot of [00:57.880 --> 01:06.600] adoption, a lot of attention. Some of the security vendors here have released blog posts and [01:06.600 --> 01:13.080] presentations showing how they use ATT&CK for ICS and how they envision their customers using it. [01:13.080 --> 01:18.940] Also, asset owners and operators are looking at how they can use it to kind of fill gaps and to [01:18.940 --> 01:25.600] understand their environments a little bit better. So for those who aren't familiar with [01:25.600 --> 01:33.460] ATT&CK, what is ATT&CK? Well, it's a knowledge base of adversary behavior, and it's based on [01:33.460 --> 01:39.620] real-world observation. So that's what adversaries are doing in the wild, what credible red teamers [01:39.620 --> 01:46.340] are doing, and things like that. I think good news for everybody is it's free, open, and globally [01:46.340 --> 01:54.120] accessible. So I gave you a link at the beginning, ATT&CK.meyer.org for slash ICS. Any of you can go [01:54.120 --> 02:02.120] and look at the knowledge base at any time. It also provides a common language for how we talk [02:02.660 --> 02:11.440] between defenders, red teamers, to business people. It really allows us to all get on the same page, [02:11.440 --> 02:17.480] and I think that's very important for especially testbed activities when you have red teamers and [02:17.480 --> 02:25.820] blue teamers. And it's community-driven, so we always look forward to contributions from the [02:25.820 --> 02:32.100] community. If you think that there's something missing or if you know of some adversary activity, [02:32.100 --> 02:37.940] you could always submit that and be a contributor to ATT&CK in general. [02:39.520 --> 02:48.340] So this is a common representation of ATT&CK. You'll see this across the multiple technology domains and [02:49.360 --> 02:57.320] knowledge bases. This is a technique matrix. And across the top, you have what are called tactics, [02:57.320 --> 03:03.560] which are the adversary's technical goals. So this ranges here on the ATT&CK for ICS technique [03:03.560 --> 03:10.920] matrix from initial access to discovery to inhibit response function and peer process control [03:10.920 --> 03:17.360] impact. So those are some technical goals of the adversary. And associated with each of these [03:17.360 --> 03:25.160] technical goals are techniques, and this is how the goal is accomplished. So this could be data [03:25.160 --> 03:31.840] historian compromise under initial access. It could also be device restart or shutdown under [03:31.840 --> 03:38.760] inhibit response function. And associated with each of the techniques, if you go to the site [03:38.760 --> 03:45.320] and look at a particular technique page, is some specific technique implementation. And this is how [03:45.320 --> 03:51.380] the adversary accomplished this high level technique. So looking at this all together, [03:51.380 --> 03:57.260] you have the tactics, techniques, and procedures of adversaries, which really represents their [03:57.260 --> 04:07.660] behavior and is the focus of ATT&CK. So on ATT&CK.meyer.org, you'll see a number of [04:07.660 --> 04:12.360] knowledge bases that are associated with technology domains. So you'll see [04:13.400 --> 04:19.220] enterprise, you'll see cloud, you'll see mobile, and now you see ICS up there as well. [04:19.220 --> 04:26.040] Why do we have different knowledge bases? Well, in general, adversary motivations may be different [04:26.040 --> 04:34.200] and they may be tightly coupled to the technology domain that they are targeting. So gaining access, [04:34.200 --> 04:39.440] accomplishing your objective, all depends on the target and what you're actually going for. [04:39.440 --> 04:44.520] So there's going to be some differences between enterprise systems and cyber physical systems. [04:44.520 --> 04:50.540] There's also different phases in the life cycle, which means there's different choices. So that [04:50.540 --> 04:56.000] also influences our decision to create a new knowledge base. And then when we get to the [04:56.000 --> 05:01.720] technologies, there's some real differences there. So how the adversaries interact with particular [05:01.720 --> 05:07.580] systems really depends on that system. So how an adversary moves through an enterprise system [05:07.580 --> 05:14.960] is different than how they may affect an embedded controller or something like that. It's things [05:14.960 --> 05:21.880] that we have to take into consideration. And then when we get to defense, we have to think about [05:21.880 --> 05:29.860] how are we collecting data to get information about what adversaries have done. We can always [05:29.860 --> 05:35.500] use network data, but what about low-level devices? How do we collect data from them? [05:35.500 --> 05:40.900] Are there standard interfaces for collecting that data? What can we expect from them? [05:40.900 --> 05:46.660] Also, in terms of mitigations, we don't want to recommend mitigations that are going to conflict [05:46.660 --> 05:52.200] with safety or availability of the system. So we really have to think hard about that. These are [05:52.200 --> 05:57.800] all just some high-level reasons why we came up with a different knowledge base to really talk [05:57.800 --> 06:06.220] about adversaries in the ICS technology domain. So this is a representation of an industrial [06:06.220 --> 06:13.000] control system. Most of us are familiar with it as a Purdue reference architecture. We think of it [06:13.000 --> 06:18.380] as functional levels of an industrial control system. And some of these levels are associated [06:18.380 --> 06:24.960] with traditional IT, and some of them are more operational technology focused, although they have [06:24.960 --> 06:31.880] IT elements in them. So when we're looking at an incident and we're decomposing it or mapping it [06:31.880 --> 06:39.200] to ATT&CK, what we first do is try to think about what technology domain the adversary affected [06:39.200 --> 06:45.720] first. And sometimes that's the enterprise technology domain. So what we'll do is we'll [06:45.720 --> 06:51.640] use enterprise ATT&CK to go as far as we can in terms of explaining the adversary behavior. [06:51.640 --> 06:56.440] As we get down to the lower levels and we start talking about specialized protocols, specialized [06:56.440 --> 07:03.560] applications, and specialized equipment, we really need ATT&CK for ICS to tell the rest of the story. [07:03.560 --> 07:12.020] So it really fills in the entire picture. So back to the technology technique matrix for ATT&CK for [07:12.020 --> 07:20.760] ICS. Let's break it down really quick. So if we look at the first tactics, a couple of tactics or [07:21.360 --> 07:27.740] it really represents the adversary finding their target, collecting information, and ultimately [07:27.740 --> 07:34.820] staging an attack. So initial access is how we get in. We may try to find our target by using [07:34.820 --> 07:41.520] discovery techniques. And then we may need to get specific information. So we may have to do some [07:41.520 --> 07:46.420] collection to understand the state of the system or state of the process at any point in time. [07:47.080 --> 07:52.320] Then inhibit response function and impair process control is the adversary directly [07:52.320 --> 07:57.620] affecting the control system. So this is us sending unauthorized command messages. Maybe [07:57.620 --> 08:03.200] we do a program download with a malicious program, different things like that, in order to actually [08:03.700 --> 08:10.620] affect the control system. And last, we have our impacts, which is really what the adversary is [08:10.620 --> 08:15.980] seeking to create. Are we trying to create a loss of control? Are we trying to damage property as [08:15.980 --> 08:22.800] an adversary? This tactic really contains those types of techniques. So this is just a quick [08:22.800 --> 08:31.520] breakdown of ATT&CK and ATT&CK for ICS and what's contained in it. It's really based off of what [08:31.520 --> 08:36.960] we've seen in the wild. So that could be kind of limiting for us, especially if we want to have fun [08:36.960 --> 08:42.740] in a testbed environment or learn about what particular techniques look like. So what I'll [08:42.740 --> 08:48.580] be talking about next is a way that we can kind of structure our activities in a testbed environment, [08:48.580 --> 08:56.100] specifically on ICS Village when we're working in it as adversaries. So something that we can use [08:56.100 --> 09:03.200] are failure and ATT&CK scenarios. I'll explain what those are and how they can help structure [09:03.200 --> 09:10.660] our activities. So failure scenarios include malicious and non-malicious cybersecurity [09:10.660 --> 09:16.640] events. And these can range from compromising equipment functionality to data integrity [09:16.640 --> 09:24.180] attacks to communication failures and more. And these have a lot of uses. They can be used for [09:24.180 --> 09:29.800] risk assessment. They can be used for training. Tabletop exercises is something that they're [09:29.800 --> 09:36.140] very popular for. But they can also be used for like security tests and testbed. So examples of [09:36.140 --> 09:42.520] sources of data for failure scenarios, really understanding how these systems fell and where [09:42.520 --> 09:47.580] are the causes of them could come from subject matter experts. So people who operate these [09:47.580 --> 09:54.280] systems. It could also come from researchers. They could come from incident repositories. So how do [09:54.280 --> 10:01.060] real life systems fail and what were the causes and consequences of those failures? So this could [10:01.060 --> 10:10.020] be NTSB databases, FEMSA or pipeline databases, or even more. And then there's also scenario [10:10.020 --> 10:15.520] repositories. These are subject matter experts have gotten together and talked about different [10:15.520 --> 10:21.440] failures that can happen. And they've provided us a repository of failures that we can just work [10:21.440 --> 10:28.500] from, such as the every NEST Core failure scenarios. So let's look at some example failure scenarios. [10:28.500 --> 10:35.680] These come from researchers who are power engineers and they released a research document [10:35.680 --> 10:42.840] through the IEEE that kind of details some failure scenarios that are interesting. So scenario one [10:42.840 --> 10:50.900] is transformer overloading. So in this particular scenario, what the objective of the adversary is, [10:50.900 --> 10:56.440] is to rapidly deteriorate transformer installation. And this really represents one of those low and [10:56.440 --> 11:02.640] attacks that damage long lead time pieces of equipment. So the technique here is basically to [11:04.500 --> 11:11.260] set or modify trip settings so that if there's an overcurrent or thermal condition that the [11:11.260 --> 11:18.320] protective relay doesn't step in to kind of correct the condition. Then we also want to [11:18.320 --> 11:23.340] block communications so that operator doesn't understand what's going on. And then we want to [11:23.340 --> 11:30.140] force all the power through one transformer to bear the load. So this rapidly heats up the [11:30.140 --> 11:36.400] transformer and degrades its installation. Scenario two, we're disrupting switching execution for [11:36.400 --> 11:43.420] circuit breaker and isolators and we're causing dielectric breakdown of that breaker and isolator. [11:43.420 --> 11:49.600] So what we're doing here is we're continuously executing switching actions to take this piece [11:49.600 --> 11:55.580] of equipment out and we're blocking comms to kind of hide our actions. And then scenario three is [11:55.580 --> 12:02.480] kind of that typical Ukraine type attack where we're just opening breakers and we're trying to [12:02.480 --> 12:10.380] cause entire substation outages and whatever contingencies come along with it. So we can start [12:10.380 --> 12:16.920] to structure this failure scenario so that we understand exactly what we're trying to accomplish. [12:16.920 --> 12:22.500] If we take scenario one, the transformer overloading, we can think about what the consequence is. The [12:22.500 --> 12:27.580] consequence is a thermal breakdown of transformer installation. Then we have a couple failure modes. [12:27.580 --> 12:36.000] We don't want the protector relay to trip. So we're going to put improper overcurrent and [12:36.000 --> 12:40.980] thermal settings in it. And then we also want one of the transformers to bear all the load. So we [12:40.980 --> 12:46.900] have to open the breaker to the other transformers that are in the system. So we could do this by [12:46.920 --> 12:53.420] modifying parameters, which is the attack technique, and sending an unauthorized command message. So now [12:53.420 --> 13:01.480] we have a full story of how we're going to cause this thermal breakdown of the transformer. Now [13:01.480 --> 13:06.380] something that we have to consider is how do we can sustain this attack? What do we need to do [13:06.380 --> 13:13.260] to make sure that this attack can continue so we get our ultimate consequence? Well, here what we [13:13.260 --> 13:18.660] want to do is make the operator unable to react to the critical condition. And one of the ways we [13:18.660 --> 13:23.660] can do that is by causing a loss of view into the substation by manipulating communications. [13:23.820 --> 13:29.420] So the attack techniques that we can use here are block reporting message and alarm suppression. [13:30.760 --> 13:37.620] So now we know what we want to accomplish. We're not just fiddling around in a test bed environment [13:38.400 --> 13:44.580] with no ultimate goal. So what's next? So now we can build our attack scenario. We can think about [13:44.580 --> 13:52.440] what's our entry point, how do we find our targets, how do we sustain our attack, and how do we cause [13:52.600 --> 13:58.020] a failure, and even more. So in terms of entry points, maybe it's that we need an engineering [13:58.020 --> 14:03.340] workstation or to accomplish this attack or something that serves that function. And maybe [14:03.340 --> 14:09.420] we look for external remote services like a VPN connection or something that allows us to get [14:09.420 --> 14:14.680] connection to this engineering workstation. And then in terms of finding our target, we have to [14:14.680 --> 14:21.660] probably do some discovery. We could do network sniffing, we could do control device identification, [14:21.660 --> 14:27.440] or we could do network service scanning. And then to sustain our attack, what we want to do [14:27.440 --> 14:34.820] is maybe block reporting messages so that certain voltage or current values don't make their way up [14:34.820 --> 14:41.300] to the operator. Or we may want to do alarm suppression where we're stopping alarm messages [14:41.300 --> 14:47.680] from going up to an operator. And then finally, to cause our failure, we want to use impaired [14:47.680 --> 14:56.560] process control tactic techniques where we modify the overcurrent and thermal parameters, [14:56.560 --> 15:03.020] and we send commands at the wrong time to open breakers. So now we're starting to build a real [15:03.020 --> 15:10.680] story about what we want to do. So this is what a first pass at highlighting the relevant techniques [15:10.680 --> 15:17.820] looks like. As we build on to our story and kind of validate that we can cause the failures that [15:17.820 --> 15:24.820] we want, we may add additional techniques, things that go ahead, or we may have to fill in sort of [15:24.820 --> 15:29.340] gaps in knowledge that we have by using a technique. But this really serves as a basis of [15:29.340 --> 15:36.760] what we're doing in order to induce this failure. And something that we can do is dive really deep [15:36.760 --> 15:42.320] into particular techniques. So for instance, unauthorized command message. We may not just [15:42.320 --> 15:46.920] want to look at the description here. We may want to look at how adversaries have done this in the [15:46.920 --> 15:52.640] past. So we have the Murchishire attack as an example. We have the 2015 Ukrainian power grid [15:52.640 --> 15:59.560] attack. We also have particular implementations that we can look at, such as Indestroy or Stuxnet [15:59.560 --> 16:05.120] to understand how unauthorized command messages were used. And if that's not enough, we also have [16:05.120 --> 16:11.140] references. So you can dig even deeper into incident reports in order to understand exactly [16:11.840 --> 16:19.920] why an adversary used this technique, what they used it for. And this really helps to build the [16:19.920 --> 16:27.100] story around what we're doing within our testbed environment. So another thing we have to consider [16:27.100 --> 16:33.400] is data sources. And data sources are very valuable for defenders, but they should also [16:33.400 --> 16:40.820] be considered from the adversary standpoint as well. So what artifacts am I leaving behind as [16:40.820 --> 16:47.120] the adversary? We need to understand what our activities look like to the defender. This is [16:47.120 --> 16:52.430] very interesting when we're in a testbed environment. Where are we leaving behind? [16:53.040 --> 16:58.280] And most people look at network traffic in terms of defense, but there's also a lot of [16:58.280 --> 17:05.160] other rich data sources that are overlooked often. So host-based logs housed on embedded [17:05.160 --> 17:11.800] OT devices such as controllers are interesting. There's also asset management data associated [17:11.800 --> 17:18.600] with equipment under control that we can look at. So we've done a lot of surveys of devices [17:18.600 --> 17:25.460] to understand what data sources are on them. And we've come up with some high-level categories of [17:25.460 --> 17:30.740] data sources on low-level controllers. And I've kind of highlighted some of the ones that are most [17:30.740 --> 17:36.100] relevant to the scenario that we've already presented. So we may want to look at parameters [17:36.100 --> 17:42.540] on the device. And we could do this in integrity, periodic integrity checks on the parameters to see [17:42.540 --> 17:48.720] if they've remained the same, if they've gone outside of our original threshold. There's alarms [17:49.600 --> 17:54.320] that are generated at these devices and stored at these devices before they're sent. So we can [17:54.320 --> 17:59.700] look at those. There's event logs such as the sequential event recorder that contain a wealth [17:59.700 --> 18:05.080] of information about commands that have been executed or parameter changes or anything else [18:05.080 --> 18:10.280] like that. But we have asset management data. We can look at condition-based monitoring, [18:10.280 --> 18:16.640] understand particular parameters about that transformer such as thermal parameters to [18:16.640 --> 18:20.520] understand if it's overheating. And there's a number of other data sources that we can look [18:20.520 --> 18:26.940] at. But we want to be aware of what our activities look like from the defender's perspective. [18:28.240 --> 18:34.860] So here are some data source considerations that we can have as we're working in these [18:34.860 --> 18:41.400] environments. So is this data source able to be accessed via a standard interface, a documented [18:41.400 --> 18:48.680] interface? That's very important for access to that data source. What's the storage size of that [18:48.680 --> 18:55.240] source? Will it eventually roll over? Is there a lot of noise in the data source? Would it be hard [18:55.240 --> 19:02.620] for a defender to kind of look through it? And then are there standard commands that are available [19:02.620 --> 19:09.100] to just delete that data source? And then another thing we can consider is does the data source get [19:09.100 --> 19:15.040] replicated to other places? So if we're looking at a low-level protection relay, does it go up to [19:15.040 --> 19:21.060] another controller? The particular data sources that we're looking at, [19:21.060 --> 19:25.940] there may be aggregation points somewhere. So these are all things that we have to consider. [19:26.060 --> 19:31.080] So let's take another look at this overall process that I'm proposing to kind of structure your [19:31.080 --> 19:36.920] activities in the testbed. So first, we want to understand failures associated with your target [19:36.920 --> 19:42.460] system. For our target system, we were looking at a transmission substation, for instance. [19:42.460 --> 19:49.500] We want to build an attack scenario around your chosen failure scenario. So how do we induce this [19:49.500 --> 19:55.340] failure via cyber means? We want to build a story around it about what the adversary is actually [19:55.340 --> 19:59.680] trying to accomplish. What's the bigger goal? By researching how and why adversaries have caused [19:59.680 --> 20:05.120] similar failures in the past. We want to conduct the attack, and that includes implementing [20:05.660 --> 20:10.860] certain techniques and see if we can induce the failure in our system. This may take multiple [20:10.860 --> 20:17.040] times. We want to understand which data sources contain indicators of our attack. [20:17.260 --> 20:21.280] And then finally, if we're purple teaming or working together with blue teamers, [20:21.280 --> 20:25.660] we want to talk about our activities using the artifacts from our structured attack plan. So [20:25.660 --> 20:31.480] that may be, we show them what our failure looks like that we're trying to induce. We can show them [20:33.080 --> 20:37.140] a technique matrix with the right techniques highlighted, and we can share with them what [20:37.140 --> 20:42.080] data sources they should look at. And that could kind of help us to work together in order to [20:42.570 --> 20:47.430] figure out new things in the testbed environment and to communicate more efficiently. [20:48.700 --> 20:57.300] So some key takeaways. It can be very helpful to build a full story around your testbed activities [20:57.300 --> 21:05.340] by documenting failure and attack scenarios. So sometimes the reaction is just to hop on the [21:05.340 --> 21:12.400] testbed and to see what's going to happen and just go with it. But structuring our activities [21:12.400 --> 21:19.740] using ATT&CK for ICS can really help communicate what we're doing. And those things are all [21:19.740 --> 21:25.160] reusable in the future. So we also want to make sure we understand what artifacts we're leaving [21:25.160 --> 21:33.500] behind. And we want to work closely with defenders as purple teams. So really quick, because I'm [21:33.500 --> 21:41.060] almost out of time, what's new for ATT&CK for ICS? So on the horizon, we do have technique updates. [21:41.140 --> 21:44.700] So that's new adversary behavior and additional references. [21:44.880 --> 21:50.260] We're adding mitigations to each technique as well. So we have to consider all our stakeholders [21:50.260 --> 21:56.160] here. Device vendors are very important because a lot of the insecure by design [21:57.960 --> 22:02.740] problems that we see with these devices start there. So we want to tell them what they can do [22:02.740 --> 22:07.440] to address some of this adversary behavior, as well as like asset owners, what they can do at [22:07.440 --> 22:15.040] their level. It's going to include many references to standard bodies such as IEC, ISA, NIST. And it's [22:15.040 --> 22:23.580] really focused around adversary use of techniques and then how interfaces are used or what their [22:23.580 --> 22:31.660] functionality is, and then also the impacts. So the last couple of things are we're starting to [22:32.300 --> 22:38.280] integrate more with traditional ATT&CK tools that people are used to using. So [22:38.280 --> 22:45.700] ATT&CK for ICS will have a STIX representation and we're also integrating it [22:45.700 --> 22:50.680] with ATT&CK Navigator. So those are some things that you can look forward to in the future and [22:50.680 --> 23:01.000] hopefully help everybody to use the knowledge base more. So that's all I have. Please feel [23:01.000 --> 23:05.580] free to visit attack.mitre.org forward slash ICS to look at the knowledge base [23:05.580 --> 23:08.440] and reach out to me on Twitter if you have any questions.