[00:04.170 --> 00:10.050] Okay, hello everyone. My name is Joe Slowik, and I'm going to be talking about something I call [00:10.050 --> 00:18.850] mission kill, focusing on process targeting in ICS attacks. So getting into that first, [00:18.850 --> 00:26.590] who am I? So currently I am a adversary hunter, a fancy way of saying threat intelligence I suppose, [00:26.590 --> 00:32.870] working at Dragos, focusing on industrial control system threats and threat activities. [00:32.870 --> 00:39.390] I also do some cyber threat intelligence training through a side gig called Paralys. [00:39.390 --> 00:43.270] If you're hanging around the Blue Team Village, you'll see me with a workshop on cyber threat [00:43.270 --> 00:50.070] intelligence later today. But in addition to my current time working with Dragos on ICS threats, [00:50.070 --> 00:55.290] I formerly led the incident response team at Los Alamos National Laboratory and did some [00:55.290 --> 01:01.150] sidery things for the U.S. Navy as an officer back in the day. But enough about me, we really [01:01.150 --> 01:08.010] want to get to our agenda for today. And along those lines, we're going to start with just a [01:08.970 --> 01:18.070] definition of what an attack means. There's a lot of confusion around the word, and so just get a [01:18.070 --> 01:24.650] common conception of what the term means in the context of ICS events. And then review three [01:24.650 --> 01:29.130] process targeting incidents from the past few years and what those teach us and the consequences [01:29.130 --> 01:36.230] of seeing adversaries migrate into a more refined or a more focused way of trying to [01:36.230 --> 01:41.710] impact control system environments. And conclude with defensive options and implications for [01:41.710 --> 01:48.430] what it is that asset owners and operators need to do in order to meet this type of or category [01:48.430 --> 01:55.960] of threat. So first to define attack, principally I'm looking at attack as being those deny, [01:55.960 --> 02:02.440] destroy operations. So just simply scanning a device, sending a phishing message, don't really [02:02.440 --> 02:08.500] constitute attacks. These can come into play in terms of certain preparatory actions, but trying [02:08.500 --> 02:17.220] to determine what is simply a route to economic espionage versus what is a precursor to an attack [02:17.220 --> 02:23.520] really depends upon being able to discern or identify adversary intent. And short of being [02:23.520 --> 02:28.240] able to read minds, it's very hard to do that. So really for the purposes of this discussion, [02:28.240 --> 02:34.860] we're really only talking about those sorts of incidents where there has been noticeable process [02:34.860 --> 02:43.000] disruption, degradation, or denying control over an industrial process. So looking at that, [02:43.000 --> 02:47.600] we can map this and there are several ways of doing this. There's the ICS specific kill chain, [02:47.600 --> 02:52.100] as well as the various other kill chains that are out there. Since we can't just have one, [02:52.100 --> 02:58.340] we need multiple. But really looking at a sequence of events going from typically breaching [02:58.740 --> 03:04.640] a victim's IT network, identifying points of contact with the industrial environment, [03:04.640 --> 03:09.400] enumerating and categorizing that environment in order to determine what sort of capabilities [03:09.400 --> 03:18.000] are necessary in order to interact with or make some change or disruptive effect within that [03:18.000 --> 03:22.660] environment, and then finally being in a position to deliver effects on objectives. [03:22.660 --> 03:28.380] So a sequence of events that are interdependent, that if you fail in one, you essentially fail in [03:28.380 --> 03:35.860] all, that defines what it is required in order to execute something disruptive or destructive [03:35.860 --> 03:41.840] within an industrial environment. And so with that in mind, looking at a lot of headlines, [03:41.840 --> 03:46.900] we see things that are mentioned as attacks that really don't meet that bar. Whether we have items [03:46.900 --> 03:54.500] like the infamous dam, New York dam incident from almost 10 years ago now, to items like the [03:54.500 --> 04:00.900] Baku-Sehan-Tbilisi pipeline incident, or even just plain made up items like in the wild ransomware [04:00.900 --> 04:07.400] that was a company tech demo and whatnot, that we see the word attack thrown about quite frequently [04:07.400 --> 04:13.800] but done so in ways that really don't align well with a conception of what an attack really means [04:13.800 --> 04:21.820] or where the implications are quite real. We do, however, see general attacks that impact ICS. [04:21.820 --> 04:26.000] So whether we're looking at something like the Shamoon event or the sequence of Shamoon events [04:26.000 --> 04:33.800] since the first one in 2012, moving on to items like there was a recent very interesting event [04:33.800 --> 04:37.960] that took place in the United States just last year, where there was a denial of service condition [04:37.960 --> 04:44.000] on a router that inhibited control over a wind farm for a period of time. But while concerning, [04:44.000 --> 04:49.480] it seemed very untargeted. And then getting into things like various ransomware strains that migrate [04:49.480 --> 04:55.140] into and have some impact on industrial operations. While all of these are very concerning, [04:55.140 --> 05:03.080] they're also somewhat dumb or very untargeted and kind of sloppy in impact. They're not terribly [05:03.080 --> 05:10.620] focused and not really taking into consideration the nature of or the specifics of the targeted [05:10.620 --> 05:15.880] industrial environment or the underlying process. Because today, what we want to talk about is a [05:15.880 --> 05:21.400] more focused type of attack that I refer to as process targeting, where instead of just blindly [05:21.400 --> 05:26.560] looking to disrupt whatever is reachable within an environment, attackers instead focus on a [05:26.560 --> 05:31.960] specific stage or aspect of an industrial process. And this can be technical, such as looking for [05:31.960 --> 05:37.480] specific equipment or software, targeting a known vulnerability or something along those lines, [05:37.480 --> 05:43.060] or it could be operational. So understanding what the sequence of events required for an industrial [05:43.060 --> 05:49.740] process, such as a manufacturing line that goes through three distinct states, and knowing which [05:49.740 --> 05:55.580] is a critical path node that if it's disrupted, it results in the entire line being brought down, [05:55.580 --> 06:00.520] represents a more operational way of looking at things and targeting those sorts of weak points. [06:00.520 --> 06:05.760] So we're really trying to move away from the discussions on indiscriminate wiping, ransomware, [06:05.760 --> 06:11.800] worms, etc., which define most of the industrial impacting events that we've seen thus far. [06:11.940 --> 06:15.800] But the thing is, don't just describe all of the industrial events that we've seen to date, [06:15.800 --> 06:22.100] because there are a subset of industrial impacting events, some in cyber, but one that's actually [06:22.100 --> 06:25.840] physical that I think presents some very important lessons. And so I'm going to bring that into the [06:25.840 --> 06:31.540] discussion today, that represent true process targeting for impacts and industrial control [06:32.280 --> 06:38.420] environments. So we'll talk to the 2016 Ukraine event, which involved the crash-over-rod malware, [06:38.420 --> 06:45.020] also referred to as Indestroyer, the 2017 Saudi Arabia incident that involved the use of the [06:45.020 --> 06:49.800] Triton or Trisys malware, and then talk about something that happened in Saudi Arabia in 2019 [06:49.800 --> 06:55.560] that wasn't cyber in origin, but really emphasizes how attackers are evolving when it comes to [06:55.560 --> 07:02.140] operating in industrial spaces. So first, the crash-over-ride incident. This was something that [07:02.140 --> 07:07.400] was briefed at Black Hat a couple of years ago between Mike, myself, and some Draco's colleagues, [07:07.400 --> 07:13.380] as well as Anton Cherpenov and Robert Lepofsky of ESET. An interesting event in that it represented [07:13.380 --> 07:21.280] the second cyber event impacting electric operations in Ukraine after the 2015 incident, [07:21.280 --> 07:27.160] but the 2016 event was a little bit more interesting because it represented a technical [07:27.160 --> 07:33.640] evolution in that it introduced a specific piece of malware with capabilities for manipulating [07:33.640 --> 07:42.980] the distribution, well, transmission operations within a substation in order to cause a [07:42.980 --> 07:47.960] disruption of the delivery of power. So the way that this attack worked is first, penetrate the [07:47.960 --> 07:53.120] environment and place malware on computers that can communicate to the field devices that actually [07:53.120 --> 07:57.740] control the breakers, and schedule that malware in order to open breakers at the target transmission [07:57.740 --> 08:06.600] site to do a sort of coordinated effort. And then there was some after-effect limited system wipe [08:06.600 --> 08:11.800] and some disabling events on infected machines that induced the loss of at least logical or [08:11.800 --> 08:17.240] state of control in the specific environment. And then there was this thing that at least at the [08:17.240 --> 08:21.940] time, and I've since analyzed this quite extensively in my presentation at the ICS Village [08:21.940 --> 08:26.680] last year actually, as well as in a subsequent white paper, on a protective relay denial of [08:26.680 --> 08:30.640] service that took place post-attack, which actually starts to become more significant [08:30.640 --> 08:36.400] when you look at this attack in terms of process dependencies. Because when we start looking back [08:36.400 --> 08:43.440] at 2015, the attackers used a wiper ostensibly to delay recovery in 2015, that we will disable all [08:43.440 --> 08:48.060] the SCADA workstations, all the engineering workstations, in order to inhibit the ability [08:48.060 --> 08:54.280] to restore operations in an effective and efficient way. But from the 2015 attack, it was proved that [08:54.280 --> 09:00.340] the operators in question were quite happy and willing to rapidly shift into manual operations [09:00.340 --> 09:05.640] in order to restore electric service as quickly as possible. And we can assume that the attackers [09:05.640 --> 09:10.660] weren't stupid, and there are significant pieces of evidence that have been reported publicly, [09:10.660 --> 09:14.860] as well as a lot of things I've written privately, that the attackers in these incidents, if not, [09:14.860 --> 09:19.220] are the same, or at least are very much tightly linked, that they took note and that the wiper [09:19.220 --> 09:23.880] functionality in 2016 really seems kind of superfluous if you know that the operators [09:23.880 --> 09:29.720] are going to go out to the transmission yard and start closing breakers manually. So other [09:29.720 --> 09:34.020] than just being an asshole and wiping computers and making restoration just more painful in the [09:34.020 --> 09:38.980] long term, why would you do this? Well, it seems that instead the wiper was intended for other [09:38.980 --> 09:44.420] purposes, that rather than to inhibit restoration, because you know that the operators are going to [09:44.420 --> 09:49.920] get into manual operations, instead the wiper seems more aligned with eliminating logical view [09:49.920 --> 09:55.300] and control of the SCADA environment. And that brings us to protective relays, because that [09:55.300 --> 10:00.220] denial of service condition on protective relays becomes fairly significant when you realize what [10:00.360 --> 10:05.720] a protective relay does in the context of electric utility operations. So especially a digital [10:05.720 --> 10:12.880] protective relay is a smart device that works to ensure the process, maybe not necessarily safety, [10:12.880 --> 10:19.620] but certainly process control and certain degrees of process protection to make sure that [10:19.620 --> 10:24.620] fluctuations in electric distribution and transmission operations don't propagate beyond [10:25.220 --> 10:30.640] the relay operations in order to induce potential physical damage to electric [10:30.640 --> 10:35.560] distribution, transmission, or even generation gear. So looking at this is that we see protective [10:35.560 --> 10:41.720] relays as being a significant aspect of electric operations at multiple stages of the electric [10:41.720 --> 10:47.760] utility landscape. And while you can operate without them, it induces a certain level of [10:47.760 --> 10:53.040] risk in that fluctuations in normal fluctuations is the part of electric operations, let alone [10:53.040 --> 11:00.180] the introduction of potential disasters, natural or engineered, means that with the absence of relay [11:00.180 --> 11:05.700] protection, anomalous events would propagate beyond that protective layer to start impacting [11:05.700 --> 11:12.140] equipment directly, thus creating the preconditions for physical equipment damage. So looking at the [11:12.140 --> 11:17.400] event in Ukraine, the Siemens SuperTech denial of service is pretty interesting in that [11:17.400 --> 11:22.280] it doesn't take the device offline, but rather the denial of service wipes all the protective logic [11:22.280 --> 11:28.100] from it. It's one of those, this is a feature as opposed to a bug, in that it's used to free up [11:28.100 --> 11:33.880] memory to allow for a firmware upgrade or reprogramming of the device. So the device is [11:33.880 --> 11:39.500] still network accessible, it looks powered on, so if you're running through the yard trying to [11:39.500 --> 11:43.520] figure out what's going on or through the control room, it might look like the device is still up [11:43.520 --> 11:49.980] and running, but all the actual protection logic is removed, so it's not doing its job. And it's a [11:50.760 --> 11:55.340] trivial attack to execute just by setting a single UDP packet within the environment. It is worth [11:55.340 --> 11:59.360] noting that there was an endingness mistake in the malware. Not sure if they were counting on [11:59.360 --> 12:04.100] this being translated in some fashion, although working in a lab environment, not quite sure how [12:04.100 --> 12:08.080] this was supposed to have worked, but it doesn't look like the payload would have been delivered [12:08.080 --> 12:12.240] properly, at least in the actual attack. And this is one of a number of mistakes that were made as [12:12.240 --> 12:18.440] part of the crash override event. But even though it didn't work quite as to the extent or in the [12:18.440 --> 12:24.680] fashion that the attackers wanted to, the intentions and the capabilities deployed in the 2016 Ukraine [12:24.680 --> 12:29.860] incident show a much more ambitious event than what we saw in 2015, in that the attackers [12:29.860 --> 12:36.720] induced a widespread outage and a loss of view condition through that wiping aspect, and then [12:36.720 --> 12:41.420] removed line protection from transmission operations. Now, removing line protection on a [12:41.420 --> 12:47.880] de-energized line makes no sense when you think about it, but if you're anticipating that operators [12:47.880 --> 12:51.540] will rush to restore operations irrespective of their ability to ascertain the process safety and [12:51.540 --> 12:56.220] protection of the environment, now you're setting up a staged attack where there's potential [12:56.220 --> 13:01.860] physically destructive consequences when you restore power to those de-energized lines in the [13:01.860 --> 13:08.400] absence of process protection. So while it didn't work as intended, crash override was appears as [13:08.400 --> 13:13.660] though it was designed to try to achieve physical process destruction within the context of electric [13:13.660 --> 13:18.980] transmission operations that would have had disruptive effects lasting potentially months [13:19.690 --> 13:27.920] in order to try to restore, recover, and ultimately likely replace damaged gear. And a lot of this [13:27.920 --> 13:32.280] comes from knowing both the combination of how the operators in question worked within their [13:32.280 --> 13:37.230] environment as well as the importance of protective relays for electric operations. [13:38.180 --> 13:44.020] Moving on to 2017, we had the Triton Trisis incident at a petrochemical facility in Saudi [13:44.020 --> 13:50.180] Arabia. And there was much discussion at the time about Triton Trisis as being malware that can kill [13:50.180 --> 13:55.700] and who was behind it. Is it Iran? Is it Russia? Or is it some other entity? But a lot of the [13:55.700 --> 14:00.760] discussion really masked some of the subtleties and really quite interesting technical details [14:00.760 --> 14:07.540] around what Trisis was capable of and how it would work as part of a overall attack sequence. [14:07.540 --> 14:12.680] Because again, similar to what we saw in 2016, Triton Trisis was not a bolt from the blue but [14:12.680 --> 14:19.000] rather the end result, well not even the end result as we'll see shortly, in a sequence of [14:19.000 --> 14:24.040] events to achieve physical process disruption or destruction within the victim environment. [14:24.040 --> 14:29.640] So we have a combination of items of repeated credential harvesting and reuse to pivot around [14:29.640 --> 14:35.000] the environment and to replay access through legitimate VPNs in order to get remote access [14:35.000 --> 14:39.880] into the ICS environment, continuing to pivot through credential capture until the attacker [14:39.880 --> 14:45.140] is able to get direct communication to a safety instrumented system on which Trisis could be [14:45.140 --> 14:49.240] deployed. And that's an interesting part and requires us to understand what a safety instrumented [14:49.240 --> 14:54.540] system is within the context of industrial operations generally and petrochemical facilities [14:54.540 --> 15:01.440] specifically. Because safety systems, while they don't ensure that nothing bad ever does happen, [15:01.700 --> 15:07.040] a safety instrumented system typically acts as sort of an emergency control system in parallel [15:07.040 --> 15:14.200] to the basic or operator controlled environment, such that in the event of a hazardous or dangerous [15:14.200 --> 15:19.860] set of conditions within the plant environment, that automated controls are put into place to [15:19.860 --> 15:25.960] ensure an easier or less physically disruptive recovery of the plant environment to minimize [15:25.960 --> 15:32.560] damage, disruption, and facilitate recovery. Now there are certainly additional safeguards within [15:32.560 --> 15:37.540] plant environments from blowout valves and pressure release valves and other sorts of items [15:37.540 --> 15:41.680] that act as engineering layers of safety control, but these start getting into [15:41.680 --> 15:47.480] more difficult circumstances for recovery and may have potentially hazardous conditions of [15:47.480 --> 15:51.920] themselves, like if you're venting product or even high pressure or high temperature steam, [15:51.920 --> 15:56.220] in order to reduce pressure in an environment that could lead to physically hazardous conditions. [15:56.300 --> 16:00.460] So while just because you remove the safety layer doesn't mean that you're setting up a plant for [16:00.460 --> 16:05.640] absolute tremendous levels of destruction, it still makes for a very hazardous environment [16:05.640 --> 16:11.040] where potentially nasty things can take place. If we start looking at trite and trisis, it becomes [16:11.040 --> 16:16.380] important to note that the intrusion itself wasn't just focused on the safety layer, but in talking [16:16.380 --> 16:21.480] with the incident responders who worked on the event, the compromise took place through both [16:21.480 --> 16:26.560] the safety layer as well as within the plant distributed control system environment. Using [16:26.560 --> 16:33.920] those compromises in parallel, a modification of safety settings means that you can have a [16:33.920 --> 16:38.760] manipulation on the DCS side that could cause a hazardous condition and then allow it to propagate [16:38.760 --> 16:43.200] through the safety layer in order to produce a hazardous effect within the environment in [16:43.200 --> 16:49.720] question. And this combined intrusion and the interdependency between the two requires some [16:49.720 --> 16:53.620] understanding and knowledge of how these different items interact with each other and what sort of [16:53.620 --> 16:59.720] changes or what sort of actions you can take that would allow for a cyber action to propagate into [16:59.720 --> 17:05.300] actual physical disruption as opposed to merely a plant denial of service. Because what's interesting [17:05.300 --> 17:10.220] about this is that trite and trisis, kind of like the 2016 event, didn't work, at least not as the [17:10.220 --> 17:15.340] attackers intended. So whereas it looks like the intended attack was to modify the sys to eliminate [17:15.340 --> 17:21.120] the safety layer, then leverage compromise of the DCS in order to produce a dangerous state that [17:21.120 --> 17:25.880] would then propagate beyond the safety layer to cause physical process disruption, instead of the [17:25.880 --> 17:32.000] time of installation of the trisis malware, which happened not just once but twice, at least twice, [17:32.000 --> 17:37.020] within the environment, that a error or something else within how the malware was put together [17:37.020 --> 17:43.040] caused the safety system to trip. And as a result, the plant shut down, which is still very disruptive [17:43.040 --> 17:47.140] and not a nice thing and cost a lot of money, but doesn't result in the sort of damage that would [17:47.140 --> 17:51.480] have happened had this attack actually worked as it looked like it was designed or intended to [17:51.480 --> 17:56.260] be carried out. So again, attackers are getting smarter in terms of knowing what sort of things to [17:56.260 --> 18:00.640] look for within industrial environments to sort of maximize damage, but still showing that they [18:00.640 --> 18:05.580] have a ways to go before being able to do so successfully or at least on a consistent basis. [18:05.860 --> 18:09.040] Which brings us to something very interesting and a little bit more blunt than some of the [18:09.040 --> 18:14.760] cyber operations we've been talking about so far. Now in September of 2019, there was a very [18:14.760 --> 18:20.340] interesting event that took place in Saudi Arabia, again Saudi Arabia, where there was a drone and [18:20.340 --> 18:29.380] missile strike on two facilities in Saudi Arabia, the petrochemical facility at Abqaiq and the oil [18:29.380 --> 18:35.400] production facilities at the Kurias field within the country. So certainly very alarming, very [18:35.400 --> 18:39.540] concerning, but what the hell does this have to do with cyber and why are you bringing this up, Joe? [18:39.540 --> 18:45.240] Well, the reason is that, for one, this represents the continuation of a series of events, both [18:45.240 --> 18:51.160] cyber and physical, against Saudi oil infrastructure from the Shamoud events to multiple physical [18:51.160 --> 18:57.220] disruptive and similar drone strikes both on cross-country pipeline operations as well as oil [18:57.220 --> 19:02.360] and gas production facilities. But what makes the September 2019 incident especially interesting [19:02.360 --> 19:08.260] is that it was very focused on a specific aspect of Saudi oil and gas operations that show a level [19:08.260 --> 19:13.380] of knowledge about how the Saudi oil and gas sector works and going back to the idea of process [19:13.380 --> 19:19.520] specific understanding and targeting. Because when we look at Abqaiq, it is the world's largest oil [19:19.520 --> 19:24.620] processing and crude stabilization facility. Essentially, Abqaiq serves as the linchpin for the [19:24.620 --> 19:30.600] entire Saudi... well, for the majority of Saudi oil production in sweetening otherwise sour crude [19:30.600 --> 19:37.340] so that it is easier to sell and more acceptable to world markets. Essentially, if you take out [19:37.340 --> 19:43.780] the Abqaiq facility or its ability to operate, the ability for Saudi Arabia to produce oil that [19:43.780 --> 19:49.340] the market desires becomes severely degraded and thus producing significant economic disruption [19:49.340 --> 19:55.220] as a result of physical disruption. Because looking at the sweetening operations or the [19:58.120 --> 20:05.220] desulfurization of removal of sulfur from crude oil, it's a very complex chemical operation that [20:05.220 --> 20:10.380] requires a significant investment in equipment, fairly large physical footprint for plant [20:10.380 --> 20:16.100] operations, and as a result, something that represents a fairly big target. And it's been [20:16.100 --> 20:20.120] the one that's been targeted at least in the context of Abqaiq several times previously but [20:20.120 --> 20:25.540] through rather blunt measures such as car bombs and other operations. Whereas the 2019 strike [20:25.540 --> 20:31.700] showed a very specific targeting because if we look at after action reports of the damage, we see [20:31.700 --> 20:37.140] that a lot of the primary focus of the attack wasn't on things like oil storage facilities [20:38.140 --> 20:44.060] or pumping and transportation infrastructure, but rather on the vessels and cracking facilities [20:44.060 --> 20:51.660] required to perform the hydro desulfurization of crude oil to make it acceptable and for the market [20:51.660 --> 20:56.880] or able to export it. So again, a very focused attack on a very specific aspect of the Saudi [20:56.880 --> 21:01.920] industry that shows an understanding of a critical process node or path dependency [21:01.920 --> 21:05.880] within Saudi oil operations that could allow for a significantly [21:08.040 --> 21:13.680] magnified impact as a result of just attacking one physical component of Saudi oil and gas [21:13.680 --> 21:19.680] infrastructure. So targeting hydro desulfurization facilities would significantly limit Saudi ability [21:19.680 --> 21:24.420] to export oil to market, and it did for a while, and there was significant effort placed into trying [21:24.420 --> 21:29.640] to restore these operations as rapidly as possible to try and recover. But as a result, the attacker [21:29.640 --> 21:35.420] was able to maximize a fairly limited strike by making sure they targeted just the right facilities [21:35.420 --> 21:40.120] in order to cause a magnified impact far out of scope, or at least seemingly [21:42.260 --> 21:47.760] out of scope, or at least beyond the immediate impacts of just physical process disruption. So [21:47.760 --> 21:52.420] understanding how these things tie together enables for a much more powerful, much more [21:52.420 --> 21:58.160] impactful attack than just simply lobbing bombs into the Abqaiq facility and hoping for the best. [21:58.360 --> 22:02.380] So where does that take us? Well, it shows that attackers are starting to get a little bit smarter [22:02.380 --> 22:06.620] in what they're shooting for when it comes to trying to disrupt industrial environments, whether [22:06.620 --> 22:12.640] that comes through cyber operations like we saw in the 2016 Ukraine event and the 2017 Saudi event, [22:12.640 --> 22:19.240] as well as through physical operations such as the Abqaiq drone and missile strike. Because what we're [22:19.240 --> 22:24.920] seeing is that adversaries are learning about how these operations work, and that increased knowledge [22:24.920 --> 22:29.440] yields an understanding of functional dependencies within these environments that allow us for [22:29.440 --> 22:34.460] adversaries to engage in focused targeting so that they can increase the effectiveness and [22:34.460 --> 22:39.600] the disruptive capability of strikes, no matter how they happen to be executed within plant [22:39.600 --> 22:44.200] environments. And we're looking at these focus points on the three items that we covered in the [22:44.200 --> 22:49.580] examples today. Process protection, the ability to make sure that industrial environments remain [22:49.580 --> 22:55.680] in a fashion that avoids physical damage and disruption to the equipment in question. [22:55.680 --> 23:01.600] Process safety, to make sure that equipment is not able to or at least has sufficient safeguards [23:01.600 --> 23:06.320] in place so as not to risk the safety or effectiveness of equipment or potentially [23:06.320 --> 23:10.940] causing harm to personnel within the plant environment. As well as process dependencies, [23:10.940 --> 23:16.760] looking at how critical a single facility like Abqaiq would be to the overall export of petroleum [23:16.760 --> 23:22.060] products for the Kingdom of Saudi Arabia. And the risks of this and the implications are that [23:22.060 --> 23:27.620] attackers, by being able to focus on specific aspects of industrial operations, open up very [23:27.620 --> 23:33.320] interesting avenues for what kind of damage they can cause. Everything from making sure they could [23:33.320 --> 23:39.300] cause more focused and potentially longer lasting process disruption, thus increasing downtime, [23:39.300 --> 23:44.220] towards in scarier items like a potential loss of life scenario, which may have manifested had [23:44.220 --> 23:49.500] crisis actually worked out as it was intended, or physical damage like was the which was the [23:49.500 --> 23:54.760] likely intention in the 2016 Ukraine event. So looking at this, we're seeing adversaries [23:54.760 --> 24:00.720] evolve over time from rather blunt and somewhat simplistic attacks like IT-based wipers, [24:00.720 --> 24:05.560] such as the Shamoon events and some other incidents where just deploy something that [24:05.560 --> 24:13.640] network and cause as much disruption as you can in a fairly untargeted and widespread fashion, [24:13.640 --> 24:20.320] then getting into more untargeted disruption, just trying to disconnect processes and inhibit control, [24:20.320 --> 24:25.020] something like we saw with the 2015 Ukraine event, and then getting into more advanced and [24:25.020 --> 24:30.520] more specific targeting, such as the focus on protective relays in 2016, the focus on safety [24:30.520 --> 24:37.600] systems in 2017, or the focus on hydro desulphurization operations in the 2019 kinetic [24:37.600 --> 24:44.280] strike. What we do about this is an open question, though, because when we look at defense in a [24:44.280 --> 24:48.880] classical sense, we usually think of throwing up walls and trying to keep adversaries out. [24:48.880 --> 24:53.660] And while this is not necessarily a bad thing, and we certainly want to keep adversaries out, [24:53.660 --> 24:59.360] this is a very limited view and not necessarily helpful in trying to really adapt with how [24:59.360 --> 25:03.780] adversaries are shifting when it comes to trying to impact industrial environments. [25:03.900 --> 25:07.840] Because looking at industrial environments, we have the combination of not just [25:07.840 --> 25:14.440] IT-based or IT-like equipment, which is amenable to IT-like controls, but also combined with that, [25:14.440 --> 25:18.820] the physical process environment, both in terms of what the environment is designed to do, [25:18.820 --> 25:24.840] as well as the implications of undesired or unintentional modifications to that environment [25:24.840 --> 25:30.320] that can cause disruption and potentially even damage. So instead, we need to have process-aware [25:30.320 --> 25:35.580] defense as part of ICS operations, where traditional IT-centric defense certainly [25:35.580 --> 25:39.940] forms a major plank of what we're trying to do, because we have lots of information systems [25:39.940 --> 25:45.400] that now reside within industrial environments. But we want to combine this with process-specific [25:45.400 --> 25:52.120] monitoring and analysis so that we can marry a logical view of the environment along with a [25:52.120 --> 25:56.980] physics-centric or process-centric view of just what's going on within the plant environment, [25:56.980 --> 26:01.340] so that we can ascertain things such as the status of process protection, process safety, [26:01.340 --> 26:06.380] or how different items of the overall process environment are interacting and what our IT [26:06.380 --> 26:11.280] visibility may indicate certain entities are trying to do within that environment. But also, [26:11.280 --> 26:14.960] we want to make sure that we're investing in resilience and recovery. This is always an [26:14.960 --> 26:18.760] uncomfortable topic, because it implies that bad things have already happened. But if we look at [26:18.760 --> 26:25.680] events like the 2016 and 2017 events, we need to make sure as ICS defenders and ICS operators [26:25.680 --> 26:29.840] that we have the capability of not only identifying what changes have taken place within [26:29.840 --> 26:34.660] the operating environment, such as the removal of process protection and process safety, but also [26:34.660 --> 26:40.120] have a way of ascertaining what those changes were and how to restore or recover from those changes, [26:40.120 --> 26:45.880] so that we're not just restoring availability in the sense of bringing processes back online, [26:45.880 --> 26:51.120] but also making sure that we're maintaining process integrity and that operations are [26:51.120 --> 26:55.820] restored to a known good and known safe state in order to make sure that we're not endangering [26:55.820 --> 27:01.100] operations or the personnel within that plant environment. And a key to doing this is making [27:01.100 --> 27:05.140] sure that we're improving visibility into industrial environments. So while we already [27:05.140 --> 27:10.660] see process data captured for operations purposes, we have data historians that do this job already, [27:10.660 --> 27:15.460] but we need to combine that with improved host and network visibility, much like what we've seen [27:15.460 --> 27:20.420] over the past five years in enterprise IT environments, to combine data sets to develop [27:20.620 --> 27:29.340] a full scope ICS aware visibility of both the IT and ICS specific aspects of an operating environment [27:29.340 --> 27:35.220] to truly understand and track what is going on within the control system environment, both for [27:35.380 --> 27:40.440] a defensive perspective, as well as to just understand purely what's going on, should we have [27:40.560 --> 27:45.220] a malicious insider or other entity begin making changes to the environment that could have [27:45.220 --> 27:52.360] significant or harmful repercussions. And then finally, we need to make sure that we're including [27:52.360 --> 27:57.480] planning for response and resilience. That means adapting or modifying the existing contingency [27:57.480 --> 28:02.320] planning that exists from an engineering perspective to incorporate cyber, not just in the [28:03.040 --> 28:07.200] ability to restore operations, but also do you have the tools and the capability [28:07.200 --> 28:11.780] to perform root cause analysis to see that a modification or an attempted modification [28:11.780 --> 28:16.160] was made to a safety system or the denial of service condition on the super tech [28:16.160 --> 28:21.400] protective relay. And this also involves a focus of effort on those critical path nodes [28:21.400 --> 28:26.620] that allows us to better allocate or smartly allocate resources on those sort of crown jewel [28:26.620 --> 28:33.240] processes around which the entire operation revolves around so that we make sure that we're [28:33.240 --> 28:37.360] taking care of the most important assets in our environment. And as a result of all of this, [28:37.360 --> 28:41.820] we should be able to allocate resources in such a fashion to facilitate rapid critical [28:41.820 --> 28:46.420] resource restoration in an incident to not just minimize downtime, but to make sure we're again [28:46.420 --> 28:52.140] restoring to a known good, known safe state instead of just blindly bringing operations back [28:52.140 --> 28:57.280] up and hoping for the best. Ultimately, we're really looking to try and build out a robust [28:57.280 --> 29:01.340] defense in depth where we're covering things certainly at the IT layer, but also bringing [29:01.340 --> 29:08.000] things into a multi-layered understanding visualization and visibility into control [29:08.000 --> 29:13.660] system environments to track not just items like opportunistic ransomware or IT wipers, [29:13.660 --> 29:19.080] but also getting into process specific targeting and modifications that could lead to far more [29:19.080 --> 29:23.520] serious effects and building that all into an industrial focused and industrial aware [29:23.520 --> 29:29.220] security program. So with that, I'm right at time. I believe these slides will be posted [29:29.220 --> 29:35.200] somewhere. There's just a selection of resources, both things that I've written as well as from [29:35.980 --> 29:39.960] peers from ESET and FireEye and some of the events that we talked about today. [29:39.960 --> 29:44.460] But if we have some time, I can answer questions. I don't know how big of a [29:44.460 --> 30:26.310] cushion we're leaving between talks. Well, I hope this was interesting. [30:26.310 --> 30:31.270] Certainly feel free to reach out to me, email, Twitter, whatever works for you, [30:31.270 --> 30:35.270] as I'm always happy to discuss this and related items. I think it's quite fascinating, [30:35.270 --> 30:41.570] especially as we start looking into the more strategic and operations focused aspects of [30:41.570 --> 30:45.450] cyber events within industrial environments. It certainly is a lot more interesting than [30:45.450 --> 30:49.570] some of the things we see in IT environments, I think, but I'm a little biased there. [30:50.550 --> 30:54.650] But yeah, I don't know, Bryson, if you've got anything for me or anyone else? [30:58.640 --> 31:00.840] No, I think you're good. Thank you. [31:04.610 --> 31:09.770] Stop the share and I will let the program move on. I'll be hanging around within the [31:09.770 --> 31:13.950] Discord and elsewhere if anyone has thoughts that came up after the fact. But otherwise, [31:13.950 --> 31:17.150] I hope everyone enjoys the ICS Village, as I know I always do. Thank you.