WEBVTT 00:00.000 --> 00:12.420 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. 00:12.520 --> 00:24.400 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. 00:26.400 --> 00:42.440 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. 00:42.440 --> 00:53.980 So really looking at their behaviors, tactics, techniques, and procedures associated with the attacks, and what the ultimate impacts of those attacks are. 00:54.420 --> 01:00.340 So since its release, we've gotten a lot of adoption, a lot of attention. 01:00.800 --> 01:13.080 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. 01:13.080 --> 01:22.620 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. 01:23.000 --> 01:27.560 So for those who aren't familiar with ATT&CK, what is ATT&CK? 01:27.580 --> 01:35.080 Well, it's a knowledge base of adversary behavior, and it's based on real-world observation. 01:35.080 --> 01:41.780 So that's what adversaries are doing in the wild, what credible red teamers are doing, and things like that. 01:41.920 --> 01:47.260 I think good news for everybody is it's free, open, and globally accessible. 01:47.400 --> 01:52.220 So I gave you a link at the beginning, ATT&CK.meyer.org for slash ICS. 01:52.220 --> 01:56.720 Any of you can go and look at the knowledge base at any time. 01:57.060 --> 02:08.700 It also provides a common language for how we talk between defenders, red teamers, to business people. 02:08.740 --> 02:18.920 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. 02:19.080 --> 02:26.220 And it's community-driven, so we always look forward to contributions from the community. 02:26.260 --> 02:37.940 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. 02:39.520 --> 02:43.660 So this is a common representation of ATT&CK. 02:43.660 --> 02:50.900 You'll see this across the multiple technology domains and knowledge bases. 02:50.900 --> 02:53.280 This is a technique matrix. 02:53.340 --> 03:00.360 And across the top, you have what are called tactics, which are the adversary's technical goals. 03:00.360 --> 03:11.640 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. 03:11.640 --> 03:15.260 So those are some technical goals of the adversary. 03:15.580 --> 03:23.400 And associated with each of these technical goals are techniques, and this is how the goal is accomplished. 03:23.500 --> 03:28.040 So this could be data historian compromise under initial access. 03:28.040 --> 03:34.380 It could also be device restart or shutdown under inhibit response function. 03:34.920 --> 03:44.520 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. 03:44.520 --> 03:49.780 And this is how the adversary accomplished this high level technique. 03:49.780 --> 04:01.500 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. 04:02.060 --> 04:11.660 So on ATT&CK.meyer.org, you'll see a number of knowledge bases that are associated with technology domains. 04:11.660 --> 04:19.220 So you'll see enterprise, you'll see cloud, you'll see mobile, and now you see ICS up there as well. 04:19.220 --> 04:21.660 Why do we have different knowledge bases? 04:21.880 --> 04:32.660 Well, in general, adversary motivations may be different and they may be tightly coupled to the technology domain that they are targeting. 04:32.660 --> 04:39.440 So gaining access, 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:49.800 There's also different phases in the life cycle, which means there's different choices. 04:49.800 --> 04:54.960 So that also influences our decision to create a new knowledge base. 04:55.220 --> 04:58.880 And then when we get to the technologies, there's some real differences there. 04:59.000 --> 05:04.620 So how the adversaries interact with particular systems really depends on that system. 05:04.620 --> 05:13.800 So how an adversary moves through an enterprise system is different than how they may affect an embedded controller or something like that. 05:13.800 --> 05:17.360 It's things that we have to take into consideration. 05:17.860 --> 05:28.620 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. 05:28.680 --> 05:33.460 We can always use network data, but what about low-level devices? 05:33.460 --> 05:35.500 How do we collect data from them? 05:35.500 --> 05:38.780 Are there standard interfaces for collecting that data? 05:38.780 --> 05:40.900 What can we expect from them? 05:40.900 --> 05:49.580 Also, in terms of mitigations, we don't want to recommend mitigations that are going to conflict with safety or availability of the system. 05:49.580 --> 05:51.820 So we really have to think hard about that. 05:51.820 --> 06:01.120 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. 06:02.140 --> 06:07.440 So this is a representation of an industrial control system. 06:07.440 --> 06:11.920 Most of us are familiar with it as a Purdue reference architecture. 06:12.200 --> 06:16.720 We think of it as functional levels of an industrial control system. 06:16.720 --> 06:27.280 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. 06:27.420 --> 06:40.000 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. 06:40.000 --> 06:44.120 And sometimes that's the enterprise technology domain. 06:44.140 --> 06:51.640 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. 06:51.640 --> 07:03.560 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. 07:03.560 --> 07:06.780 So it really fills in the entire picture. 07:08.020 --> 07:12.640 So back to the technology technique matrix for ATT&CK for ICS. 07:12.640 --> 07:14.660 Let's break it down really quick. 07:14.780 --> 07:29.180 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. 07:29.180 --> 07:31.540 So initial access is how we get in. 07:31.540 --> 07:37.680 We may try to find our target by using discovery techniques. 07:37.720 --> 07:40.500 And then we may need to get specific information. 07:40.500 --> 07:46.420 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. 07:47.080 --> 07:53.860 Then inhibit response function and impair process control is the adversary directly affecting the control system. 07:53.860 --> 07:57.120 So this is us sending unauthorized command messages. 07:57.120 --> 08:05.720 Maybe we do a program download with a malicious program, different things like that, in order to actually affect the control system. 08:05.740 --> 08:11.600 And last, we have our impacts, which is really what the adversary is seeking to create. 08:11.600 --> 08:14.000 Are we trying to create a loss of control? 08:14.000 --> 08:17.040 Are we trying to damage property as an adversary? 08:17.060 --> 08:21.480 This tactic really contains those types of techniques. 08:21.740 --> 08:28.860 So this is just a quick breakdown of ATT&CK and ATT&CK for ICS and what's contained in it. 08:28.980 --> 08:33.160 It's really based off of what we've seen in the wild. 08:33.160 --> 08:42.200 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. 08:42.200 --> 08:53.820 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. 08:54.220 --> 08:59.080 So something that we can use are failure and ATT&CK scenarios. 08:59.080 --> 09:04.720 I'll explain what those are and how they can help structure our activities. 09:05.220 --> 09:11.440 So failure scenarios include malicious and non-malicious cybersecurity events. 09:11.440 --> 09:20.140 And these can range from compromising equipment functionality to data integrity attacks to communication failures and more. 09:20.300 --> 09:22.840 And these have a lot of uses. 09:22.840 --> 09:25.380 They can be used for risk assessment. 09:25.380 --> 09:27.420 They can be used for training. 09:27.420 --> 09:31.220 Tabletop exercises is something that they're very popular for. 09:31.220 --> 09:34.600 But they can also be used for like security tests and testbed. 09:34.840 --> 09:45.880 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. 09:45.880 --> 09:48.400 So people who operate these systems. 09:48.400 --> 09:50.380 It could also come from researchers. 09:50.900 --> 09:53.640 They could come from incident repositories. 09:53.640 --> 10:00.700 So how do real life systems fail and what were the causes and consequences of those failures? 10:00.700 --> 10:08.300 So this could be NTSB databases, FEMSA or pipeline databases, or even more. 10:08.780 --> 10:11.180 And then there's also scenario repositories. 10:11.180 --> 10:16.600 These are subject matter experts have gotten together and talked about different failures that can happen. 10:16.600 --> 10:25.240 And they've provided us a repository of failures that we can just work from, such as the every NEST Core failure scenarios. 10:25.620 --> 10:28.500 So let's look at some example failure scenarios. 10:28.500 --> 10:41.660 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. 10:41.700 --> 10:45.400 So scenario one is transformer overloading. 10:45.400 --> 10:54.380 So in this particular scenario, what the objective of the adversary is, is to rapidly deteriorate transformer installation. 10:54.380 --> 11:00.160 And this really represents one of those low and attacks that damage long lead time pieces of equipment. 11:00.420 --> 11:16.940 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. 11:16.940 --> 11:22.740 Then we also want to block communications so that operator doesn't understand what's going on. 11:22.740 --> 11:26.860 And then we want to force all the power through one transformer to bear the load. 11:26.860 --> 11:32.740 So this rapidly heats up the transformer and degrades its installation. 11:32.940 --> 11:43.420 Scenario two, we're disrupting switching execution for circuit breaker and isolators and we're causing dielectric breakdown of that breaker and isolator. 11:43.420 --> 11:54.560 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. 11:54.560 --> 12:08.160 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. 12:08.740 --> 12:16.920 So we can start to structure this failure scenario so that we understand exactly what we're trying to accomplish. 12:16.920 --> 12:22.360 If we take scenario one, the transformer overloading, we can think about what the consequence is. 12:22.360 --> 12:26.000 The consequence is a thermal breakdown of transformer installation. 12:26.000 --> 12:27.580 Then we have a couple failure modes. 12:27.580 --> 12:30.860 We don't want the protector relay to trip. 12:31.480 --> 12:37.500 So we're going to put improper overcurrent and thermal settings in it. 12:37.680 --> 12:40.740 And then we also want one of the transformers to bear all the load. 12:40.740 --> 12:45.740 So we have to open the breaker to the other transformers that are in the system. 12:45.760 --> 12:53.160 So we could do this by modifying parameters, which is the attack technique, and sending an unauthorized command message. 12:53.160 --> 13:01.040 So now we have a full story of how we're going to cause this thermal breakdown of the transformer. 13:01.140 --> 13:05.420 Now something that we have to consider is how do we can sustain this attack? 13:05.420 --> 13:11.980 What do we need to do to make sure that this attack can continue so we get our ultimate consequence? 13:12.600 --> 13:17.420 Well, here what we want to do is make the operator unable to react to the critical condition. 13:17.780 --> 13:23.660 And one of the ways we 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:34.520 So now we know what we want to accomplish. 13:34.520 --> 13:40.340 We're not just fiddling around in a test bed environment with no ultimate goal. 13:40.340 --> 13:41.740 So what's next? 13:41.740 --> 13:43.840 So now we can build our attack scenario. 13:43.840 --> 13:54.180 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. 13:54.180 --> 14:02.980 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. 14:02.980 --> 14:12.220 And maybe we look for external remote services like a VPN connection or something that allows us to get connection to this engineering workstation. 14:12.640 --> 14:16.640 And then in terms of finding our target, we have to probably do some discovery. 14:16.640 --> 14:24.360 We could do network sniffing, we could do control device identification, or we could do network service scanning. 14:24.600 --> 14:36.240 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. 14:36.480 --> 14:43.760 Or we may want to do alarm suppression where we're stopping alarm messages from going up to an operator. 14:43.980 --> 15:00.480 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. 15:00.480 --> 15:05.320 So now we're starting to build a real story about what we want to do. 15:05.520 --> 15:11.980 So this is what a first pass at highlighting the relevant techniques looks like. 15:11.980 --> 15:27.520 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. 15:27.520 --> 15:32.640 But this really serves as a basis of what we're doing in order to induce this failure. 15:33.360 --> 15:38.460 And something that we can do is dive really deep into particular techniques. 15:38.460 --> 15:41.180 So for instance, unauthorized command message. 15:41.240 --> 15:43.660 We may not just want to look at the description here. 15:43.660 --> 15:47.340 We may want to look at how adversaries have done this in the past. 15:47.340 --> 15:50.380 So we have the Murchishire attack as an example. 15:50.380 --> 15:53.700 We have the 2015 Ukrainian power grid attack. 15:53.700 --> 16:03.500 We also have particular implementations that we can look at, such as Indestroy or Stuxnet to understand how unauthorized command messages were used. 16:03.500 --> 16:05.740 And if that's not enough, we also have references. 16:05.740 --> 16:17.560 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. 16:17.560 --> 16:24.700 And this really helps to build the story around what we're doing within our testbed environment. 16:25.120 --> 16:29.020 So another thing we have to consider is data sources. 16:29.160 --> 16:36.800 And data sources are very valuable for defenders, but they should also be considered from the adversary standpoint as well. 16:37.220 --> 16:42.000 So what artifacts am I leaving behind as the adversary? 16:42.080 --> 16:46.660 We need to understand what our activities look like to the defender. 16:46.660 --> 16:51.140 This is very interesting when we're in a testbed environment. 16:51.140 --> 16:52.430 Where are we leaving behind? 16:53.040 --> 17:03.060 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. 17:03.160 --> 17:08.240 So host-based logs housed on embedded OT devices such as controllers are interesting. 17:08.240 --> 17:14.700 There's also asset management data associated with equipment under control that we can look at. 17:14.700 --> 17:22.000 So we've done a lot of surveys of devices to understand what data sources are on them. 17:22.000 --> 17:28.520 And we've come up with some high-level categories of data sources on low-level controllers. 17:28.600 --> 17:33.320 And I've kind of highlighted some of the ones that are most relevant to the scenario that we've already presented. 17:33.320 --> 17:37.040 So we may want to look at parameters on the device. 17:37.040 --> 17:47.740 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. 17:47.880 --> 17:53.880 There's alarms that are generated at these devices and stored at these devices before they're sent. 17:53.880 --> 17:55.220 So we can look at those. 17:55.220 --> 18:06.120 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. 18:06.120 --> 18:08.240 But we have asset management data. 18:08.240 --> 18:18.260 We can look at condition-based monitoring, understand particular parameters about that transformer such as thermal parameters to understand if it's overheating. 18:18.260 --> 18:20.760 And there's a number of other data sources that we can look at. 18:20.760 --> 18:26.940 But we want to be aware of what our activities look like from the defender's perspective. 18:28.240 --> 18:35.720 So here are some data source considerations that we can have as we're working in these environments. 18:35.720 --> 18:42.600 So is this data source able to be accessed via a standard interface, a documented interface? 18:42.640 --> 18:46.880 That's very important for access to that data source. 18:47.000 --> 18:49.460 What's the storage size of that source? 18:49.460 --> 18:51.660 Will it eventually roll over? 18:51.840 --> 18:54.320 Is there a lot of noise in the data source? 18:54.320 --> 18:58.920 Would it be hard for a defender to kind of look through it? 18:59.440 --> 19:05.460 And then are there standard commands that are available to just delete that data source? 19:05.900 --> 19:10.600 And then another thing we can consider is does the data source get replicated to other places? 19:10.600 --> 19:16.780 So if we're looking at a low-level protection relay, does it go up to another controller? 19:17.040 --> 19:23.760 The particular data sources that we're looking at, there may be aggregation points somewhere. 19:23.760 --> 19:25.940 So these are all things that we have to consider. 19:26.060 --> 19:33.100 So let's take another look at this overall process that I'm proposing to kind of structure your activities in the testbed. 19:33.220 --> 19:37.920 So first, we want to understand failures associated with your target system. 19:37.920 --> 19:42.460 For our target system, we were looking at a transmission substation, for instance. 19:42.460 --> 19:46.940 We want to build an attack scenario around your chosen failure scenario. 19:46.940 --> 19:51.780 So how do we induce this failure via cyber means? 19:52.000 --> 19:56.240 We want to build a story around it about what the adversary is actually trying to accomplish. 19:56.240 --> 19:57.240 What's the bigger goal? 19:57.240 --> 20:01.700 By researching how and why adversaries have caused similar failures in the past. 20:01.840 --> 20:09.960 We want to conduct the attack, and that includes implementing certain techniques and see if we can induce the failure in our system. 20:09.960 --> 20:11.820 This may take multiple times. 20:12.660 --> 20:17.040 We want to understand which data sources contain indicators of our attack. 20:17.260 --> 20:25.520 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. 20:25.520 --> 20:30.600 So that may be, we show them what our failure looks like that we're trying to induce. 20:30.600 --> 20:39.080 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. 20:39.080 --> 20:47.430 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. 20:48.700 --> 20:51.400 So some key takeaways. 20:52.300 --> 21:00.880 It can be very helpful to build a full story around your testbed activities by documenting failure and attack scenarios. 21:00.880 --> 21:09.940 So sometimes the reaction is just to hop on the testbed and to see what's going to happen and just go with it. 21:09.940 --> 21:18.740 But structuring our activities using ATT&CK for ICS can really help communicate what we're doing. 21:18.740 --> 21:21.680 And those things are all reusable in the future. 21:21.680 --> 21:25.980 So we also want to make sure we understand what artifacts we're leaving behind. 21:26.020 --> 21:30.640 And we want to work closely with defenders as purple teams. 21:30.700 --> 21:37.000 So really quick, because I'm almost out of time, what's new for ATT&CK for ICS? 21:37.000 --> 21:41.060 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:48.100 We're adding mitigations to each technique as well. 21:48.100 --> 21:51.340 So we have to consider all our stakeholders here. 21:51.360 --> 22:00.880 Device vendors are very important because a lot of the insecure by design problems that we see with these devices start there. 22:00.880 --> 22:08.660 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. 22:08.800 --> 22:14.460 It's going to include many references to standard bodies such as IEC, ISA, NIST. 22:14.460 --> 22:27.460 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. 22:27.820 --> 22:38.140 So the last couple of things are we're starting to integrate more with traditional ATT&CK tools that people are used to using. 22:38.140 --> 22:47.040 So ATT&CK for ICS will have a STIX representation and we're also integrating it with ATT&CK Navigator. 22:47.040 --> 22:57.540 So those are some things that you can look forward to in the future and hopefully help everybody to use the knowledge base more. 22:57.660 --> 22:59.700 So that's all I have. 22:59.880 --> 23:08.440 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.