 of Attack for ICS, and that's what I'll be talking about today. I'll give you a little introduction, and also talk about some use cases centered around test beds, which I think is relevant to the ICS Village. So feel free to use the link here, attack.myre.org or slash ICS if you wanna take a look at the Knowledge Base while I'm talking, and also feel free to reach out to me on Twitter. So Attack 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 Attack 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 Attack, what is Attack? Well, it's a Knowledge Base of Adversary Behavior, and it's based on real world observations. 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, attack.mire.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 Attack in general. So this is a common representation of Attack. 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 Attack 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 altogether and you have the tactics, techniques and procedures of adversaries which really represents their behavior and is the focus of Attack. So on Attack.mire.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 gonna be some differences between enterprise systems and cyber physical systems. There's also different phases in the lifecycle which mean there's different choices. So that also influences our decision to create a new Knowledge Bases. 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 the 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 wanna recommend mitigations that are gonna 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 Bases 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 attack, 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 attack 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 protocol, specialized applications and specialized equipment, we really need attack 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 attack for ICS. Let's break it down really quick. So if we look at the first tactics, a couple of tactics or more, 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 peer process control is the adversary directly affecting the control system. So this is a sending on authorized command messages. Maybe we do a program download with the 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 attack and attack 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 test bed 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 test bed environment specifically on ICS Village when we're working in it as adversaries. So something that we can use are failure and attack scenarios. And 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 that can be used for risk assessment. They can be used for training, table top exercises is something that they're very popular for. But they can also be used for like security testing in a test bed. So examples of sources of data for failure scenarios, really understanding how these systems fell and where the causes of them could come from subject matter experts. So people who operate these systems, they could also come from researchers. They could come from incident repositories. So how do real life systems fell and what were the causes and consequences of those failures? So this could be NTSB databases, films that are 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 repository of failures that we could just work from such as the every Nest Corp 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 slow attacks that damage normally 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 protector 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 wanna 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 isolators. 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 the cellular scenario so that we understand exactly what we're trying to accomplish. So if we take scenario one, the transformer overloading, we could think about what the consequence is. The consequence is a thermal breakdown of transformer installation. And then we have a couple of filter modes. We don't want the protector related trip. So we're gonna 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 gonna 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 wanna 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 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 may have to fill in certain 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 Murcheshire attack as an example. We have the 2015 Ukrainian power grid attack. We also have particular implementations that we can look at such as indestructory or Stuxnet to understand how unauthorized command message were used. And if that's not enough, we also have references. So you can be 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 can 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 an adversary? We need to understand what our activities look like to the defender. This is very interesting when we're in the 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 go 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 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 data 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 test bed. 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 seeing 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 mean 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 test bed environment and to communicate more efficiently. So, some key takeaways. It can be very helpful to build a full story around your test bed activities by documenting failure and attack scenarios. So sometimes the reaction is just to hop on the test bed and to see what's gonna happen and just go with it. But structuring our activities using attack for ICS can really help communicate what we're doing and those things are all reusable in the future. So we also wanna make sure we understand what artifacts we're leaving behind and we want to work closely with the vendors as purple teams. So really quick, cause I'm almost out of time, what's new for attack 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 wanna 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 gonna 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 that are, we're starting to integrate more with traditional attack tools that people are used to using. So attack for ICS, we'll have a sticks representation and we're also integrating it with attack 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.minor.org slash ICS to look at the knowledge base and reach out to me on Twitter if you have any questions.