Port disruption and a discussion of maritime and OT.

Dave Bittner: It's November 13, 2023, and you're listening to Control Loop. In today's OT Cybersecurity briefing, a look at Sandworm attacks against Ukraine's power grid in 2022. The Department of Energy hosts simulated cyberattack competitions. CISA, FEMA, and Shields Ready. Cyber and electronic threats to Space Systems. The four cyber phases of a hybrid war. We welcome guest Austin Reid to the show. He's a senior consultant at ABS Group. Austin and I discuss cyber risk and threats to maritime transportation systems, MTS. The Learning Lab has an encore of the discussion between Dragos CEO Robert M. Lee and Mark Urban about the five critical controls for ICS. Australia's National Cybersecurity Coordinator announced Saturday that the government was investigating a cyberattack that disrupted several Australian ports. The coordinator tweeted, DP World Australia has advised it has restricted access to its Australian port operations in Sydney, Melbourne, Brisbane, and Fremantle while it investigates the incident. This interruption is likely to continue for a number of days and will impact the movement of goods into and out of the country. DP World Australia is working with its stakeholders to consider the impacts on its operations at specific ports. DP World began restoring operations at the affected ports Monday, according to the BBC. The coordinator called the event a nationally significant cyber incident. The shutdown was preventative, according to The Guardian. All that was publicly known Sunday was that unauthorized activity had been detected in DP World Australia's systems. The ABC reports that land operations were affected by the incident, which remains under investigation. DP World Australia has said, according to Bloomberg, that it has not received a ransom demand. The conversation recounts informed speculation to the effect that the incident represents sabotage by a foreign state actor. There has so far been no public disclosure of the precise nature of the incident, and no known criminal group appears to have claimed responsibility. DP World did issue a statement to its various stakeholders in which it said a key line of inquiry in this ongoing investigation is the nature of data access and data theft. BleepingComputer points out that data theft is typically a concern in extortion attacks, but there's been no public acknowledgement that the incident involved ransomware. Mandiant last week released a study of Sandworm's cyberattacks against Ukraine's electrical power grid last year. Sandworm, also known as Voodoo Bear, is a threat actor operated by the GRU's unit 74455. Mandiant wrote, While we were unable to identify the initial access vector into the IT environment, Sandworm gained access to the OT environment through a hypervisor that hosted a supervisory control and data acquisition management instance for the victim's substation environment. Based on evidence of lateral movement, the attacker potentially had access to the SCADA system for up to three months. Those three months of preparation culminated in the exploitation on October 10, 2022, of End-of-Life Hitachi Energy MicroSCADA control systems that brought the affected systems under Sandworm control and which enabled the attackers to issue commands that tripped breakers in electrical power distribution substations. Two days later, Sandworm deployed a new variant of CADDYWIPER, which served both to damage the associated IT networks and to obscure its own operations. The attack was marked by Living Off the Land techniques, significant because they decrease the time and resources required to conduct a cyber physical attack and because they reduce the likelihood of detection. The Russian campaign stands out for several reasons. First, it was a successful attack against a widely deployed OT system. Such attacks have been rare, and they've proven difficult to execute. Second, the cyberattacks coincided with a kinetic Russian missile campaign designed to cripple Ukrainian infrastructure as winter approached. Such coordination of cyberattack into a combined arms operation has also been rare and difficult for Russian forces to achieve. Third, the attack showed both careful preparation and an ability to develop offensive tools quickly. And, finally, the attack showed what Russia is likely to attempt in its infrastructure disruption campaign during the winter of 2023 and 2024. There's no particular reason to expect infrastructure attacks to be strictly confined within the borders of Ukraine, so the Shields Ready advice we'll hear about in a few minutes is especially timely. Forcepoint analysts looking at both Russia's war against Ukraine and the war unleashed by Hamas' assault on Israel concluded that cyber operations in any hybrid war are likely to fall into four conceptually distinct, albeit temporally overlapping phases. Phase 1 involves an increase in scale and impact of attacks. In this initial phase, attacks increase in scope, evolving from hashtags to defacements and distributed denial-of-service attacks. Phase 2 is expanded targeting and more sophisticated attacks. The emergence of state-linked proxy cyberthreat actors typically bring about more sophisticated targeting strategies, including cyberterrorism. Phase 3 involves ransomware operations and false flags. Ransomware groups and deceptive tactics become part of the cyber landscape, impacting virtual and physical infrastructures, as well as public perception. And phase 4 is about coordination with kinetic operations. Cyberattacks are closely coordinated with kinetic operations, impacting not only virtual but also physical aspects of the armed conflict. Of these four phases, the fourth has been least in evidence in both of the present wars. Wiper attacks have represented the closest approach to effective targeting coordinated with operations on the ground. Among these, only the Russian attacks on ViaSat networks in the opening hours of the invasion have had tactical effect. And even that effect was short-lived. Far more prominent have been the other three phases, and it's noteworthy that all of these involve deniable auxiliaries: false flag operations, privateering, and co-opted criminal activity. None of these lend themselves to the sort of combined arms coordination historically seen with traditional electronic warfare. Note, too, that the clearest success against infrastructure was against satellite-provided connectivity. Russia had, in the years leading up to its invasion of Ukraine last year, interfered with sections of Ukraine's power grid. Dragos noted in a 2019 blog post, The cyberattack on three power companies in Ukraine in December of 2015 marked a revolutionary event for electric grid operators. This attack was the first known instance of a successful disruption of electric grid operations, resulting in over 225,000 customers without power for upwards of six hours until manual operations could restore power. In December of 2016, the second publicly known ICS targeting malware, CrashOverride, was the first malware framework to target a transmission substation, causing an outage in Kyiv, Ukraine. That hasn't happened at scale during the current full-scale war. It's not because Russia has decided to keep its hands off infrastructure. Quite the contrary. Ukrainian energy infrastructure in particular has absorbed plenty of Russian kinetic missile and drone strikes, and the breaching of dams on the Dnipro amounted to vandalism on a grand scale. It seems, rather, that cyberattacks are harder to pull off than it's often thought and that defenders determined to learn from experience can apply those lessons for greater resilience. The US Cybersecurity and Infrastructure Security Agency and the Federal Emergency Management Agency on Tuesday launched Shields Ready, a sustained national campaign to increase the security and resilience of America's critical infrastructure. Shields Ready complements CISA's Shields Up campaign. According to FEMA, Shields Ready focuses more broadly and strategically on how to prepare critical infrastructure for a potential disruption and how to build more resilience into systems, facilities, and processes by taking action before a crisis or incident even occurs. The approach encourages critical infrastructure operators to focus on the following steps: Identify critical assets and map dependencies, assess risks, plan and exercise, and adapt and improve. the US Department of Energy's Office of Cybersecurity, Energy Security, and Emergency Response and the Argonne National Laboratory hosted its ninth CyberForce Competition on November 4, CyberScoop reports. The competition gave more than 100 teams of students the opportunity to deal with a simulated cyberattack against the company in the distributed energy resources market. Mara Winn, Deputy Director of Preparedness Policy and Risk Analysis at the agency, told CyberScoop, The student teams must integrate, maintain, and secure their internal management systems and industrial control systems for their customers, while providing seamless energy buyback and credit systems for the local grid company. This is exactly what we need people doing on a day-to-day basis. The US Space Force sees the cybersecurity of space systems as crucial to mission capability. Via Satellite quotes Colonel Richard Knisely, Senior Materiel Leader of the Space Force's Commercial Space Office, is saying, The US and our allied forces must now contend with growing threats from satellite link interceptions. It's interesting that he sees the threat as representing a convergence of both electronic and cyberattacks. He states, This results from advanced jamming techniques and illegal satellite uplinks. Our operations are hindered by compromised communication integrity and potential data breaches. Via Satellite also reports that Darren Turner, Chief of Critical Networks Defense for the US National Security Agency's Cybersecurity Directorate, said in his keynote at CyberSatGov that space operators need to begin implementing quantum resistant cryptography. Turner stated, When it comes to space cybersecurity, stopping rampant cyber intrusions is this generation's counterterrorism mission. It will require an infusion of talent and maximum effort across the United States government, our allies, and industry to adapt, innovate, and sharpen our competitive edge in order to dominate in this evolving space. As satellites become increasingly integrated into a range of networked IoT and ICS systems, the Space Force's concerns will grow increasingly relevant to the industrial cybersecurity community.

Dave Bittner: Austin Reid is a senior consultant at ABS Group. I recently spoke with him about threats to maritime transportation systems, or MTS. Here's my conversation with Austin Reid.

Austin Reid: Of course. Yes. So the maritime transportation systems, you know, encompasses everything from your traditional commercial shipping vessels all the way to your port facilities on the coast to your inland port facilities that process those containers and get those out to the consumer. So it's a very large, you know, area that doesn't just necessarily represent things that float or, you know, are near the water.

Dave Bittner: Can we dig into some of the challenges here that people face? I mean, we're talking about an international operation, right?

Austin Reid: Yeah. Exactly. So there's so many stakeholders that influence or partake in, you know, within the MTS. So, basically, it's integrating all of those different parties and trying to make sure, one, that, you know, you can have enough information and ensure that information properly to conduct trade. But, you know, when you try to secure those complex systems, things can be -- you know, it can be very difficult to achieve that.

Dave Bittner: This being an international thing that covers a whole lot of different areas, and that has to have specific challenges itself, just the breadth of it.

Austin Reid: Exactly. Yeah. So the -- you know, like I was -- mentioned before, the MTS covers everything from vessel operations down to port facilities in -- all over the globe. So when you're trying to navigate different regulatory compliance issues in one nation, you may not have those same standards as you would in another nation. So trying to navigate that in a way that you can still be productive and still achieve what you're looking to, you know, achieve from a business standpoint without compromising safety or loss to income. So specific to, I guess, pick a specific example for, you know, vessel systems. So, you know, I come from an early career in maritime shoreside cargo operations. So, when I look at, you know, trying to identify risks or contextualizing those threats and challenges to the sector, I focus on what are the issues and threats to operations that would cause a -- you know, a fail to fail situation or, you know, a workstop-type situation for the user itself or for the operations folks. So, you know, if there's some sort of incident where you -- you know, there's a ransomware event that occurs on terminal or within the, you know, the vessel systems, you know, back in the day as in, you know, 10 to 15 years ago, that may not have been possible. But because of the, you know, increasing, adding additional activities to these vessels or these port facilities, it's opening up additional threats and attack paths for nefarious folks to exploit. And we've seen that recently and in the headlines with some support facilities overseas that have faced ransomware events.

Dave Bittner: Yeah. It's an interesting case. As you mentioned, you know, as you and I are recording this, some folks in Australia have been recovering from what we believe are some ransomware threats. And it's interesting to me that their shutdown was kind of a preventive -- preventative one. You know, they're saying that, rather than proceed not knowing exactly what they were dealing with, they felt it was safer and probably more prudent to put things on hold while they figured things out. But kind of to your broader point, I mean, that speaks to some of the direct challenges that these organizations are facing here. A ransomware threat can shut down multiple ports across a nation.

Austin Reid: There's those connection points and those interfaces between the port facilities and the vessels themselves. So it's one of those challenges that, you know, that if a facility just takes a pause and says, okay. We're going to triage and assess what is actually happening before we, you know, make any actions, and that's critical because, you know, the paramount thing with these operations is ensuring safe operations. So cybersecurity and cyber safety, you know, work hand in hand as -- you know, in all critical infrastructure sectors. But I like to call out specifically within the maritime space because a lot of the assets or a lot of the facilities operate in, you know, remote or austere areas, whether that's a vessel thousands of miles, you know, into the Pacific Ocean. If you have some sort of operational casualty on that asset, you don't have the, you know, the same ability to triage and diagnose that problem as you would at, say, a shore-side facility. So it's, you know, having those processes in place and understanding your systems so you can, you know, meet those -- meet those challenges as they come up. And, you know, that could be incident response. It could just be basic training for basic cyber hygiene. What we've seen and what has been coming out of the Coast Guard and, you know, as early as 2019 is that early maritime cybersecurity events were basically a fault of lack of cyber hygiene, specifically an incident in 2019 where a vessel transiting into Port of New York and New Jersey had a malware event, and it caused a, you know, challenges for where they weren't able to continue safe operation. So Coast Guard got involved with that. And it's just, it's something that, you know, is what we've seen is it's difficult to -- because there haven't been major public incidences of these types of attacks or events occurring, either at sea while underway or necessarily in port operations areas where we can point to and says, Hey. This is a very real threat. This is happening. You know, the industry itself is very reactive. And that's where we're -- you know, that goes back to -- going to back up even farther here. You look at the history and the basis of the modern MTS, it goes back, you know, to Lloyds of London and those insurance brokerages and the P&I clubs within the older world that you know, those processes and those institutional knowledge is inherently -- you know, it's ingrained today, so whereas you have other sectors, you know, power generation or anything that they're -- you know, they don't necessarily have that what I'll call, you know, technical debt to carry them into a --

Dave Bittner: Rich history.

Austin Reid: Yeah. The rich history, the challenges they face to, you know. It's -- it's difficult to work, you know, to try to present these challenges, you know, that the operator will face, the user will face and say, hey, you know, you need to take cyber seriously because XYZ. Other sectors can point to APT activity that have, you know, resulted in loss of -- loss of power generation or loss of the facilities. But right now, thankfully, we haven't necessarily seen that within the MTS. You know, we've seen these ransomware events that have hit port facilities. We've seen these, you know, malware events that have hit vessels. But where we're concerned is we see, you know, in the near term, near to medium term with additional connectivity that's been added to these vessels or will be continually added to these vessels because of, you know, the drive for insights into analytics for conditions maintenance, you know, remote monitoring, emissions compliance or fleet management systems, any of those types of things will open up, you know, new attack paths. And if it's not done in a proper way where you can secure those and, you know, use industry best practices or, you know, ICS or IoT security best practices, you could cause some issues. And, you know, if you don't necessarily have the processes in place and know how to deal with that, there's -- there's some challenges there. And I think it's -- it could be an interesting few years, unfortunately, for the maritime cyberspace for, you know, trying to secure that properly.

Dave Bittner: That's Austin Reid, Senior Consultant at ABS Group. In this week's Learning Lab, an encore of the discussion between Dragos CEO Robert M. Lee and Mark Urban about the five critical controls for ICS.

Robert M. Lee: Today, I wanted to talk about the five critical controls for industrial control systems. And this is something that I'm working on over at the SANS Institute. It's something that's informed from the Dragos Year in Review. So it's all based on real insights, right? It's not theory. It's not, hey, I had an idea. It's off of real incident response cases, real assessments, real -- my work across our customer environments. But, realistically, these are the five things you kind of naturally come to anyways. I look at them as being Intel driven. If you take all the different case studies out there of threats that we're responding to and dealing with, what does it really boil down to that you need to do well, I kind of flippantly say that these are the five things you've got to do for national security risk. If you want to do anything beyond that for business risk, feel free. But, if you're not doing these five things, you're probably deficient. And these are the five things that I wouldn't -- it's probably overly flippant, but I wouldn't want to be in a position testifying in front of Congress without having done these five things in a major attack. These are the ones that are just kind of common sense things based off the attacks and incidents we've seen. What we're doing over at the SANS Institute, Tim Conway and I are writing the paper on it. It's pretty much done, but we will probably iterate on it for a while and obsess about it before we release it. But then you'll see quite a bit out of it -- come out of the SANS Institute, the classes and so forth. But, anyways, without further ado, these five. So the idea behind it is what are the things that we have to do based on the requirements that we're trying to drive as a business and then map it to a framework or standard. And, right now, what I see a lot of people make mistakes in is they'll pick up a NIST cybersecurity framework or a 60443 or a NERC CIP or whatever, and they'll drive their security program by that standard. But that standard is really there as a lexicon in the same way that MITRE ATT&CK for ICS is. It's a lexicon. It's not a bingo card. It's not go do everything. It's here's a common language, and to be able to talk to your peers across the company in between the industry. So you should do the controls and then map the output of them to a standard, not vice versa. And the way the controls start, the first control is ICS-specific incident response plan. And what I've seen throughout my career is that folks will first start with let's think about our architecture and endpoint protection and patching and all these things around our systems, and then eventually we'll get the detection program to try to detect threats. And then, eventually, maybe we'll respond to threats; and -- and we'll try to figure it out then. And what happens, if you start that way, you don't necessarily get all the things that you're going to need during the incident response. So let's hypothetically say that you have 20 requirements out of an incident response ranging from operations requirements to regulatory to security to compliance to legal to whatever you got. Let's say 20 requirements coming out of the incident response. Just a made up number. If you don't design for the incident, on average, you're answering two or three of those questions. But if you design for the incident and then kind of reverse engineer your way into it, you're answering 18 or 19 of them. Like, you're always going to miss something. But you're making sure that data and the collection and the insights that you have are supporting what is going to be the worst day for you, which is your incident. And so, you know, again, shortly stated, we take a lot of incident response cases where people have done good security work, but it's all just disjointed. So the idea is start with the incident response planning first, and reverse engineer what do you need out of your environment or architecture defense program, all these things to be able to support you in an incident, to be able to answer those critical questions to make sure you have the right data stored for the right amount of time from the right locations, that you have the detections that actually gets you to the incident, kind of all those things. That first control's so critical because it really sets the theme for every other control. And it's where you should be deciding what scenarios you want to deal with. As an example, let's say you're a power company. And you didn't prepare for China, Iran, and Russia teaming up to form a superpower to come at you. Who cares. Never happened before. It's not a big deal. Like, if you get punched in the face by three state actors teaming up to come after you, everyone's going to be like, Yeah. No kidding. Right. I still think you can defend against it. But everyone's going to look at you and go, Yeah. That makes sense. Like, you couldn't prepare for that. That makes sense. But if you're a power company and you're not prepared for ransomware across your operations environment or the Ukraine 2015 power outage scenario or Ukraine 2016 power outage scenario, everyone's going to look at you and go, Dude, what? Like, these are three well-known scenarios. They're in your industry. What do you mean you didn't prepare for them? And so I think you have a responsibility to the community, and you have a responsibility to the people that your critical infrastructure serves and your shareholders to make sure that the knowns are covered. Too often we see people go, I want to know the unknown unknown. It's like, dude, just start with the knowns. And a lot of the things that you cover in the knowns will help you in those unknown scenarios. So, anyways, long story short, incident response plan for ICS specifically is number one. And that should set the scenarios. Those scenarios are going to be things that you can brief up to the board and brief down to operations, brief down to security operations personnel, of here are the scenarios we want to be prepared against. And the scenarios really hearken back to like a safety culture and kind of process hazard analysis or HAZOP scenarios. It's very focused on what an engineering mindset would be anyways. You can use the ICS cyber kill chain to think about those scenarios as well. And it just really creates an alignment. Do I want every security operations analyst triaging every possible alert? No. That's silly. But do I want to know what taxes and techniques align with the scenarios that I care most about as an organization so that I can create the run books off of them and all the processes to make sure that, when those things happen, that we're paying special attention to them? Of course. Anyways, so I get that first control done. I can do things like tabletop exercises and other things in that control. But, really, it's what are the scenarios with alignment across the company with an incident response plan specific to them. The second control, then, is a defensible architecture. It's not defended; it's not secure. I hate when vendors come out and go, This is a secure product. No, it's not. It's a defensible product. It's a defensible architecture. But adding the human component is what makes it defended. Okay. So what is a defensible architecture? Well, it's going to depend on your industry and that scenario. If I come up with a scenario against ransomware, which every industry at this point should have across your operations environment, you're going to find things like segmentation is important. You're going to find things like having IT and OT share an Active Directory server is not helpful. Ransomware commonly compromises Active Directory and then populates that thing like a Highway to Death, you know, Highway to Hell just across your organization. Let's make sure that we separate out those AD environments, especially in the critical sites. I might find pretty commonly that my Incident Response requirements have things that depend on ICS on that systems of systems. A lot of IT is system analysis and data analysis. A lot of ICS is systems of systems and physics. So if I want to understand that the logic has been changed in the controller, I'm not doing that with host-based analysis. I'm doing that with network systems of systems, and they see the network interactions. So I want to see span ports or tap infrastructure in a defensive architecture, as an example, from that second control, depending on my scenario. So I'm going to pick out those scenarios and control one and have plans against them. That's going to drive what I need out of my defensible architecture. That defensible architecture is going to reduce as much risk as I can reasonably while enabling me to add humans in to defend. That gets me into my third control, which in ICS is going to be ICS network monitoring. And so that's going to be all the variety of different ICS visibility products out there. Pick your one that works best for you. The point, though, is can I see system-to-system interaction, kind of understand what's happening inside the protocols of ICS traffic, whether it's a Vnet protocol from Yokogawa, Modbus, TCP is a common protocol, OPC for a historian. What's that systems of systems interaction can I identify that an engineer workstation changed the logic of a controller across the network? You know, that type of system to system analysis. The benefit of that category anyways is that that control is going to give you everything massive inventory to go reinforce that defensive architecture. It's going to give you vulnerability identification in any of your modern products. And, more importantly, it's going to get you the detections that you need. So it's kind of reinforcing control, too, and making sure that your prevention controls don't atrophy over time. And it's also making sure we can even get to the incident by having the right detections in place, especially those tactics and techniques and procedures of those adversaries and the stairs we care most about. The fourth control, it's going to be a classic IT control, secure remote access. And for most considerations there won't be huge ICS differences. There are some, but in most cases we'll -- we'll push for multifactor authentication, especially for remote sessions where we can get it. Like an OEM or integrator or maintenance personnel coming in to remote in the site, I want to put them on multifactor authentication. If it can't be supported, then I'll go back and put compensating controls in my defensible architecture and try to have things like jump host or extra monitoring or so forth around those accesses. Either way, I need to identify where those accesses are. So I want that visibility and insights from that control 3 first. I need to understand what my architecture is and I control to, and then I'm going and applying secure remote access where I can. And then the last control is a key vulnerability management program. A lot of folks come into ICS environments and they look at it and go, Oh, my gosh. It's Windows XP or Windows 7. And, oh, it's so vulnerable. That's a very system view. I'm not saying we can't fix those things. But what is the risk that we're trying to reduce here? What are we trying to solve for? Again, go back to that critical in control 1. What do we need out of this, which should inform what vulnerabilities actually matter. When we at Dragos look at our Year in Review reports, we go through every single vulnerability each year on the intel team. And we just think about which ones actually add extra risk in the environment. So something that is either being exploited by adversaries currently or is introducing new functionality into the industrial environment that is risky. So, in other words, if there's a vulnerability that allows me to modify the logic of a controller from an injera workstation, I'd roll my eyes because that's the whole point of the injera workstation. I don't need the vulnerability to do that. There's a lot of native functionality in the environment that makes a lot of vulnerabilities useless. But what are the ones that are adding new functionality that it's risky or actively being exploited. And, when we look at that, on average, it is about 4%. So it's like the Ford of, I don't know, say 20, but what's around the 4% of vulnerabilities you should actually care about? Where are they located, and let's go address them. And that can also get into things like software build materials where I don't just want to know that Honeywell disclosed a vulnerability. I want to know that three other OEMs also had it and didn't disclose it because they didn't know about it because maybe it was like the Pipedream malware and taking advantage of the CODESYS software. So ICS incident response plan, that's going to set the requirements for the rest of the program and alignment across the company, which is usually missing on what are we trying to solve for. Then gets to control 2 on defensible architecture, which is defined by what we need the architecture to support in that incident as well as helping you reduce the risk of it. Control 3 is that ICS network monitoring or network security monitoring, that visibility in system of systems analysis. Control 4 is that secure remote access, very often multifactor authentication. And control 5 is the key vulnerability manager program. And, again, there's a lot of people out there will be like, well, you didn't say anything about antivirus or this or that or the other. Like, there's a lot of controls we're leaving off because these are the five that you would -- would manifest. In the various instances we've seen, these are the five that are most important for you. I'm not saying that other things won't return value. You should go have business discussions on the rest of things and figure out what makes sense for you based on your business risk. But those five are pretty unalienable in the sense that you really need to be doing those five. And those -- that's why we're making them the critical controls. That's why you'll see why people come out from SANS. You'll start seeing it in our courses. And you'll start to see and reinforce from the community. And there's a number of governments around the world I've already talked to that are going to work on amplifying and reinforcing as well because it's just common sense in terms of preparing us for those things that we worry about most.

Dave Bittner: And that's Control Loop, brought to you by the CyberWire and powered by Dragos. For links to all of today's stories, check out our show notes at thecyberwire.com. Sound design for this show is done by Elliott Peltzman, with mixing by Tré Hester. Our senior producer is Jennifer Eiben. Our Dragos producers are Joanne Rush and Mark Urban. Our executive editor is Peter Kilpe. And I'm Dave Bittner. Thanks for listening. We'll see you back here next time.