How to Make Your Security Program Resilient to the Next Big Ransomware Attack
The US’s largest fuel pipeline was hit with a ransomware attack that took it offline. It is expected to be inoperational for more than a week. The scale of such an attack has left many in the security community wondering what went wrong. At Randori, we take the position that these attacks are inevitable, and that as a defender, you have to ask yourself when they will happen, not if.
For a look at why, we have to turn the clocks all the way back to 2012, when I gave an interview explaining why SCADA (Supervisory Control and Data Acquisition) systems are frequently misconfigured to allow more access than is necessary.
The organizations who implement SCADA, and those who operate them, must ask whether the system actually needs to be connected to the internet — many don’t need to be. The more interconnected you are, or the more you offload maintenance burden to third-parties, the more you expose yourself to risk.
We’ve been dealing with the same problems for a decade. Here’s what this same story looked like in 2012: SCADA: Old Systems with New Risks!
Treat Machines like IT Assets
We use computers to control physical systems: from running the brakes in your car or keeping an airplane in the air, to moving oil across the Texas desert and filtering water. The problem is that when implementing these systems people think of them as a product they purchase and deploy, and they don’t think it’s something someone might want to subvert. They think of it as a machine, and not as an IT asset, and so they’re not implementing the same kind of defenses that they might do for their other systems — EDR on my HR laptops? Sure! EDR on my hydro-controller HMI? Maybe not…
What’s more, these systems make the opportunity cost of downtime very clear: if you’re pumping a million dollars a minute of oil through a pipeline, you’ve got a very strong incentive to not turn a system off, even to patch a computer. The downtime would cost money, and you’re worried that patching or changing the system might introduce new, unknown risks.
I’ve had process engineers tell me that when they test and validate a system, they often include a “validated configuration” of the software versions. This means that if they update or change that software, they might need to revalidate a whole system. (This can make sense! Imagine if an update changes the timing of a feedback control loop!)
Create Redundancies to Slow Down Ransomware
What this means to you: Like any other high value system, you need to build in layers of defenses and controls to act as redundancies. (Defense in depth, anybody?) Parts of the system will be extremely sensitive — but that doesn’t mean they have to threaten the whole operation. It should be a lot of hoops — a lot of individual failures — for ransomware to shutdown a pipeline, because you know which systems are sensitive and lacking defenses, so you know where you can put extra process and control to defend those jewels.
When I see an outage like this, my first thought is not that we’re witnessing a sophisticated attack. I tend to think that we’re seeing an old, piecemeal system that ended up being vulnerable to opportunistic ransomware, most probably by happenstance rather than highly targeted attack. In fact, it won’t surprise me if we learn that someone was browsing the internet and reading email from a computer that’s used to control a valve or something to that effect.
Know where you are weak and red team to stress test
Resiliency is easier to talk about than achieve. How do you create lots of “hoops” for an attacker to jump through without knowing what’s possible, or where you’re weak? How do you know if the layers of defenses you’ve laid work? You need to know where you’re weak on your perimeter and the most likely place for an attacker to strike. The right attack surface management (ASM) platform will do that for you. It should give you the attacker’s point of view, and indicate the most likely places for attack. Knowing you’re weak is only half the battle — compromise is inevitable, but breach isn’t. You need to stress test individual components and the system as a whole. Use a red team to test various components of your system to ensure that the redundancies work. If you implement this process, you might not need to come in on the weekend to combat the next Colonial attack. You’ll be able to rest easier when you have confidence that your system is resilient enough to combat ransomware even when parts of it get exposed.
