 Okay, hello everyone. My name is Joe Sloak and I am going to be talking about something I call mission kill focusing on process targeting and ICS attacks. So, getting into that first, who am I so currently I am a adversary hunter. I have a fancy way of saying threat intelligence I suppose working at Dregos focusing on industrial control system threats and threat activities. I also do some cyber threat intelligence training through a site gig called paralysis. If you're hanging around the blue team village you'll see me with a workshop on cyber threat intelligence later today. But in addition to my current time working with Dregos on ICS threats, I formally led the incident response team at Los Alamos National Laboratory and did some cidery things for the US Navy as an officer back in the day. But enough about me, we really want to get to our agenda for today. And along those lines, we're going to start with just a definition of what an attack means. We're going to have confusion around the word and so just get a common conception of what the term means in the context of ICS events, and then review three process targeting incidents from the past few years and what those teachers and the consequences of seeing adversaries to a more refined or a more focused way of trying to impact control system environments and conclude with defensive options and implications for what it is that asset or owners and operators need to do in order to meet this type of or category of threat. So first to define attack. Yeah, principally, I'm looking at attack as being those deny degrade destroy operations so just simply scanning a device, sending a phishing message, don't really constitute attacks these can come into play in terms of certain preparatory actions but trying to determine what is simply a route to economic espionage versus what is a precursor to an attack really depends upon being able to discern or identify adversary intent and short of being able to read minds it's very hard to do that. So really for the purposes of this discussion. We're really only talking about those sorts of incidents where there has been noticeable process disruption degradation or denying control over an industrial process. So we're looking at that, and we can map this and there are several ways of doing this there's the ICS specific kill chain, as well as the various other kill chains that are out there since we can't just have one we need multiple, but really looking at a sequence of events typically breaching a victims it network, identifying points of contact with the industrial environment, enumerating and categorizing that environment in order to determine what sort of capabilities are necessary in order to interact with or make some change or disruptive effect within that environment, and then finally being in a position to deliver effects on objectives. So a sequence of events that are interdependent that if you fail in one, you essentially fail and all that defines what it is is required in order to execute a system that is being disruptive or destructive within an industrial environment. And so with that in mind, looking at a lot of headlines we see things that are mentioned as a tax that really don't meet that bar, whether we have items like the infamous damn New York almost 10 years ago now to items like the Baku Sehan Tbilisi pipeline incident, or even just plain made up items like in the wild ransomware that was a company tech demo and whatnot that we see the word attack thrown about quite frequently but done so in ways that really don't align well with a conception of what an attack really means or where the implications are quite real. We do, however, see general attacks that impact ICS. So whether we're looking at something like the shimoon event or the sequence of shimoon events since the first one in 2012, moving on to items like there was a recent very interesting event that took place in the United States just last year, where there was a denial of service condition on a router that inhibited control over a wind farm for a period of time. But while concerning it seemed very untargeted and then getting into things like various ransomware strains that migrate into and have some impact on industrial operations while all of these are very concerning. They're also somewhat dumb or very untargeted and kind of sloppy in impact, not terribly focused and not really taking into consideration the nature of or the specifics of the targeted industrial environment or the underlying process. Because today what we want to talk about is a more focused type of attack that I refer to as process targeting, where instead of just blindly looking to disrupt whatever is reachable within an environment, attackers instead focus on a specific stage or aspect of the industrial process. And this could be technical, such as looking for specific equipment or software targeting a known vulnerability or something along those lines, or it could be operational to understanding what the sequence of events required for an industrial process, such as a manufacturing line that goes through three distinct states and knowing which is a critical path know that if it's disrupted it results in the entire line being brought down represents a more operational way of looking at things and targeting those sorts of weak points. And so we're really trying to move away from the discussions on indiscriminate wiping ransomware worms etc, which define most of the industrial impacting events that we've seen thus far. One thing is don't just describe all of the industrial events that we've seen to date because there are a subset of industrial impacting events, some in cyber but one that's actually physical that I think presents some very important lessons and so I'm going to bring that into the discussion to represent true process targeting for impacts and industrial control environments. So we'll talk to the 2016 Ukraine event, which involved the crash over Rod malware also referred to as in destroyer the 2017 Saudi Arabia incident that involved the use of the cyber burden or trices malware, and then talk about something that happened in Saudi Arabia in 2019 that wasn't cyber and origin but really emphasizes how attackers are evolving when it comes to operating in industrial spaces. So first the crash override incident. This was something that was briefed at Black Hat a couple of years ago between myself and some Dragos colleagues as well as Anton Cherupinoff and Robert Lopovsky of ESET. An interesting event in that it represented the second cyber event impacting electric operations in Ukraine after the 2015 incident, but the 2016 event was a little bit more interesting, because it represented a technical evolution in that it was just a specific piece of malware with capabilities for manipulating the distribution or transmission operations within a substation in order to cause a disruption of the delivery of power. So the way that this attack worked is first penetrate the industrial environment and place malware on computers that can communicate to the field devices that actually control the breakers and schedule that malware in order to open the market transmission site to do a sort of coordinated effort. And then there was some after effect, limited system wipe and some disabling events on infected machines that induced the loss of at least logical or state of control in the specific environment. So there was this thing that at least at the time and I've since analyzed this quite extensively in my presentation of the ICS Village last year actually as well as in a subsequent white paper on a protective relay denial of service that took place post attack which actually starts become more significant when you look at this attack in terms of process dependencies. Because when we start looking back at 2015, the attackers used a wiper, a sensibly to delay recovery in 2015 that we will disable all of the scale workstations all the engineering workstations in order to inhibit the ability to restore operations and in an efficient way. But from the 2015 attack it was proved that the operators in question were quite happy and willing to rapidly shift into manual operations in order to restore electric service as quickly as possible. And we can assume that the attackers weren't stupid. And there are significant pieces of evidence that have been reported publicly as well as a lot of things I've written privately that the attackers in these incidents if not are the same or at least are very much tightly linked that they took note and that the wiper functionality in 2016 really seems kind of superfluous if you know that the operators are going to go out to the transmission yard and start closing breakers manually. So other than just being an asshole and wiping computers and making restoration, just more painful in the long term. Why would you do this. Well, it seems that instead the wiper was intended for other purposes that rather than to inhibit restoration because you know that the operators are going to get into manual operations instead the wiper seems more aligned with eliminating logical view and control of the scattered environment. And that brings us to protective relays, because that denial of service condition on protective relays becomes fairly significant when you realize what a protective relay does in the context of electric utility operations. So, especially a digital protective relay is a smart device that works to ensure the process, maybe not necessarily safety but certainly process control and certain degrees of process protection to make sure that fluctuations and electric distribution and transmission operations don't propagate beyond the relay operations in order to induce potential physical damage to electric distribution transmission or even generation gear. So looking at this is that we see protective relays as being a significant aspect of electric operations at multiple stages of the electric utility landscape, and while you can operate without them. It induces a certain level of risk in that fluctuations in normal fluctuations is the part of electric operations let alone the introduction of potential disasters natural or engineered means that with the absence of relay protection. Anomalous events would propagate beyond that protective layer to start impacting equipment directly, thus creating the preconditions for physical equipment damage. So looking at the event in Ukraine. The Siemens to protect denial of service is pretty interesting in that it doesn't take the device offline but rather the denial of service wipes all the protective logic from it. It's one of those this is a feature as opposed to a bug in that it's used to free up memory to allow for a firmware upgrade or reprogramming of the device. So the device is still network accessible it looks powered on. So if you're running through the yard trying to figure out what's going on or through the control room that might look like the device is still up and running. But all the actual protection logic is removed so it's not doing its job. And it's a trivial attack to execute just by sending a single UDP packet within the environment. It's worth noting that there was an ending this mistake in the malware. Not sure if they were counting on this being translated in some fashion although working in a lab environment, not quite sure how this was supposed to have worked but doesn't look like the payload would have been delivered properly at least in the actual attack. And this was one of a number of mistakes that were made as part of the crash override event. But even though it didn't work quite as to the extent or in the fashion that the attackers wanted to. The limitations and the capabilities deployed in the 2016, you create incidents show a much more ambitious event than what we saw in 2015, and that the attackers induced a widespread outage, and a loss of view condition through that wiping aspect, and then removed line protection that were moving line protection on a de-energized line makes no sense when you think about it, but if you're anticipating that operators will rush to restore operations irrespective of their ability to ascertain the process safety and protection of the environment, now you're setting up a staged attack where there's potential physically destructive consequences when you restore power to those de-energized lines in the absence of process protection. So while it didn't work as intended, crash override appears as though it was designed to try to achieve physical process destruction within the context of electric transmission operations that would have had disruptive effects lasting potentially months in order to try to restore, recover, and ultimately likely replace damage gear. And a lot of this comes from knowing both the combination of how the operators in question worked within their environment as well as the importance of protective relays for electric operations. Living under 2017, we had the Triton Trisys incident at a petrochemical facility in Saudi Arabia, and there was much discussion at the time about Triton Trisys as being malware that can kill and who was behind it, is it Iran, is it Russia, or is it some other entity, but a lot of the discussion really masked some of the subtleties and really quite interesting technical details around what Trisys was capable of and how it would work as part of a overall attack sequence. Because again, similar to what we saw in 2016, Triton Trisys was not a bolt from the blue, but rather the end result, well not even the end result as we'll see shortly, in a sequence of events to achieve physical process disruption or destruction within the victim environment. So we have a combination of items of repeated credential harvesting and reuse to pivot around the environment and to replay access through legitimate VPNs in order to get remote access into the ICS environment, continuing to pivot through credential capture until the attacker is able to get direct communication to a safety instrumented system on which Trisys could be deployed. And that's an interesting part and requires us to understand what a safety instrumented system is within the context of industrial operations generally in petrochemical facilities specifically. Because safety systems, while they don't ensure that nothing bad ever does happen, a safety instrumented system typically acts as sort of an emergency control system in parallel to the basic or operator controlled environment, such that in the event of a hazardous or dangerous set of conditions than the plant environment that automated controls are put into place to ensure a easier or less physically disruptive recovery of the plant environment to minimize damage disruption and facilitate recovery. Now, there are certainly additional safeguards within plant environments from blowout valves and pressure release valves and other sorts of items that act as engineering layers of safety control but these start getting into more difficult circumstances for recovery and may have potentially hazardous conditions of themselves like if you're venting product or even high pressure or high temperature steam in order to reduce pressure in an environment that could lead to physically hazardous conditions. So while just because you remove the safety layer doesn't mean that you're setting up a plant for absolute tremendous levels of destruction, it still makes for a very hazardous environment where potentially nasty things can take place. And if we start looking at triton trices it becomes important to note that the intrusion itself wasn't just focused in the safety layer but in talking with the incident responders who worked on the event. The compromise took place through both the safety layer as well as within the plant distributed control system environment. Using those compromises in parallel a modified modification of safety settings means that you can have a manipulation on the DCS side that could cause a hazardous condition and then allow it to propagate through the safety layer in order to produce a hazardous effect within the environment in question. And this combined intrusion and the interdependency between the two requires some understanding and knowledge of how these different items interact with each other and what sort of changes or what sort of actions you can take that would allow for a cyber action to propagate into actual physical disruption as opposed to merely a plant denial of service. Because what's interesting about this is that triton trices kind of like the 2016 event didn't work at least not as the attackers intended. So whereas it looks like the intended attack was to modify the cyst to eliminate the safety layer, then leverage compromise in order to produce a dangerous state that would then propagate beyond the safety layer to cause physical process disruption. Instead of the time of installation of the trices malware, which happened not just once but twice at least twice within the environment that a error or something else within how the malware was put together caused the safety system to trip, and as a result the plant shut down, which is still very disruptive and not a nice thing and cost a lot of money, but doesn't result in the sort of damage that would have happened. But had this attack actually worked as it looked like it was designed or intended to be carried out. So again attackers are getting smarter in terms of knowing what sort of things to look for within industrial environments to sort of maximize damage, but still showing that they have a ways to go before being able to do so successfully or at least on a consistent basis, which brings us to something very interesting and a little bit more blunt than some of the cyber operations we've been talking about so far. Now in September of 2019 there was a very interesting event that took place in Saudi Arabia, again Saudi Arabia, where there was a drone and missile strike on two facilities in the in Saudi Arabia, the petrochemical facility at upcake and the oil production facilities at the Korea's field within the country. So certainly very alarming very concerning but how the hell does this have to do with cyber and why are you bringing this up Joe. And this is that, for one, this represents the continuation of a series of events both cyber and physical against Saudi oil infrastructure from the Shamut events to multiple physical disruptive and similar drone strikes both on cross country pipeline operations as well as oil and gas production facilities. But what makes the September 2019 incident especially interesting is that it was very focused on a specific aspect of Saudi oil and gas operations that show a level of understanding of how the Saudi oil and gas sector works, and going back to the idea of process specific understanding and targeting, because when we look at upcake, it is the world's largest oil processing includes stabilization facility, essentially upcake serves as a production for the entire Saudi from well for the majority of Saudi oil production in sweetening otherwise sour crude, so that it is easier to sell and more acceptable to world markets. Essentially, if you take out the upcake facility or its ability to operate the ability for Saudi Arabia to produce oil that the market desires becomes severely degraded and thus producing significant economic disruption as a result of physical because looking at the sweetening operations or the desulfurization of rumor removal of sulfur from crude oil. It's a very complex chemical operation that requires a significant investment in equipment, fairly large physical footprint for plant and as a result, something that represents a fairly big target and it's been one that's been targeted at least in the context of ab cake, several times previously but through rather blunt measures such as car bombs and other operations as the 2019 strike showed a very specific targeting because if we look at after after action reports of the damage we see that a lot of the primary focus of the attack wasn't on things like oil storage facilities, or pumping and transportation infrastructure but rather on the vessels and cracking facilities that are required to perform the hydro desulfurization of crude oil to make it acceptable and for the market are able to export it. So again a very focused attack on a very specific aspect of the Saudi oil industry that shows an understanding of a critical process note or path dependency within Saudi oil operations that could allow for a significantly magnified impact as a result of just attacking one physical component of Saudi oil and gas infrastructure. So targeting hydro desulfurization facilities would significantly limit Saudi ability to export oil to market, and it did for a while and there was a significant effort placed into trying to restore these operations as rapidly as possible to try and recover. But as a result, the attacker was able to maximize a fairly limited strike by making sure they targeted just the right facilities in order to cause a magnified impact far out of scope or at least seemingly out of scope or at least beyond the immediate impacts of just physical process disruption. So understanding how these things tie together enables for a much more powerful much more impactful attack than just simply lobbing bombs into the outcake facility and hoping for the best. So where does that take us? Well it shows that attackers are starting to get a little bit smarter in what they're shooting for when it comes to trying to disrupt industrial environments, whether that comes through cyber operations like we saw in the 2016 Ukraine event and the 2017 Saudi event, as well as through physical operations such as the ab cake drone and missile strike. Because what we're seeing is that adversaries are learning about how these operations work, and that increased knowledge yields and understanding of functional dependencies within these environments that allows for adversaries to engage in focused targeting, so that they can increase the effectiveness and the disruptive capability of strikes. No matter how they happen to be executed within plant environments. And we're looking at these focus points on the three items that we covered in the examples today on process protection, the ability to make sure that industrial environments remain in a fashion that avoids physical damage and disruption to the equipment in question, process safety to make sure that equipment is not able to or at least has sufficient safeguards in place, so as not to risk the safety or effectiveness of equipment or potentially causing harm to personnel within the plant environment, as well as process dependencies, looking at how critical a single facility like upcake would be to the overall export of petroleum products for the kingdom of Saudi Arabia. And the risks of this and the implications are that attackers by being able to focus on specific aspects of industrial operations, open up very interesting avenues for what kind of damage they can cause. Everything from making sure they could cause more focused and potentially longer lasting process disruption, thus increasing downtime towards in scarier items like a potential loss of life scenario which may have manifested had crisis actually worked out as it was intended, or physical damage like was the, which was the likely intention in the 2016 Ukraine event. So looking at this we're seeing adversaries evolve over time from rather blunt and somewhat simplistic attacks like it based wipers, such as the shaman events and some other incidents where just deploy something that worms to the network and it causes as much disruption as you can in a fairly untargeted and widespread fashion. Then getting into more untargeted disruption, just trying to disconnect processes and inhibit control, something like we saw with the 2015 Ukraine event, and then getting into more advanced and more specific targeting such as the focus on protective relays in 2016, the focus on safety systems in 2017, or the focus on hydro disulfidization operations in the 2019 kinetic strike. What we do about this is an open question though because when we look at defense in a classical sense, we usually think of throwing up walls and try to keep adversaries out. And while this is not necessarily a bad thing and we certainly want to keep adversaries out. This is a very limited view and not necessarily helpful in trying to really adapt with how adversaries are shifting when it comes to trying to impact industrial environments. Because looking at industrial environments, we have the combination of not just it based or it like equipment which is amenable to it like controls, but also combined with that the physical process environment both in terms of what the environment is designed to do as well as the implications of undesired or unintentional modifications to that environment that can cause disruption and potential even damage. So instead, we need to have process aware defense as part of ICS operations where traditional IT-centric defense certainly forms a major plank of what we're trying to do because we have lots of information systems that now reside within industrial environments. But we want to combine this with process specific monitoring and analysis so that we can marry a logical view of the environment along with a physics-centric or process-centric view of just what's going on within the plant environment so that we can ascertain things such as the status of process protection, process safety, or how different items of the overall process environment are interacting and what our IT visibility may indicate certain entities are trying to do within that environment. But also, we want to make sure that we're investing in resilience and recovery. This is always an uncomfortable topic because it implies that bad things have already happened. But if we look at events like the 2016 and 2017 events, we need to make sure as ICS defenders and ICS operators that we have the capability of not only identifying what changes have taken place within the operating environment, such as the removal of process protection and process safety, but also have a way of ascertaining what those changes were and how to restore or recover from those changes so that we're not just restoring availability in the sense of bringing processes back online, but also making sure that we're maintaining process integrity and that operations are restored to a known good and known safe state in order to make sure that we're not endangering operations or the personnel within that plant environment. And a key to doing this is making sure that we're improving visibility into industrial environments. So while we already see process data captured for operations purposes, we have data historians that do this job already, but we need to combine that with improved host and network visibility, much like what we've seen over the past five years in enterprise IT environments to combine data sets to develop a full scope ICS aware visibility of both the IT and ICS specific aspects of an operating environment to truly understand and track what is going on within the control system environment both for a defensive perspective as well as to just understand purely what's going on should we have a malicious insider or other entity begin making changes to the environment that could have significant or harmful repercussions. And then finally, we need to make sure that we're including planning for response and resilience. That means adapting or modifying the existing contingency planning that exists from an engineering perspective to incorporate cyber, not just in the, you know, the ability to restore operations but also, you know, do you have the tools and the capability to perform root cause analysis to see that a modification or an attempted modification was made to a safety system, or the denial of service condition on the super tech protective relay. And this also involves a focus of effort on those critical path nodes that allows us to better allocate or smartly allocate resources on those sort of dual processes around which the entire operation revolves around so that we make sure that we're taking care of the most important assets in our environment. And as a result of all this we should be able to allocate resources in such a fashion to facilitate rapid critical resource restoration and an incident to not just minimize downtime but to make sure we're again restoring to a known good known safe state instead of just blindly bring operations back up and hoping for the best. Ultimately, we're really looking to try and build out a robust defense in depth where we're covering things certainly at the it layer but also bringing things into a multi layered understanding visualization and visibility into control system environments to track not just items like opportunistic ransomware or it wipers but also getting into process specific targeting and modifications that could lead to far more serious effects and building that all into an industrial focused and industrial aware security program. So with that I'm right at time. I believe these slides will be posted somewhere. There's just a selection of resources both things that I've written as well as from peers from ESET and FireEye and some of the events that we talked about today. But if we have some time, I can answer questions. I don't know if we how big of a cushion we were leaving between talks. Well, I hope this was interesting. Certainly feel free to reach out to me email Twitter, whatever works for you as I'm always happy to discuss this and related items is I think it's quite fascinating, especially as we start looking at to into the more strategic and operations focused aspects of cyber events within industrial environments certainly is a lot more interesting than some of the things we see an IT environments I think, but I'm a little biased there. But yeah, I don't know Bryson if you've got anything for me or anyone else. Nothing you're good. Thank you. Stop the share and I will let the program move on I'll be hanging around within the discord and elsewhere if anyone has thoughts that came up after the fact but otherwise I hope everyone enjoys the ICS villages I know I always do. Thank you.