Last Friday, Colonial Pipeline — the company responsible for nearly half the fuel supply to the US East Coast — confirmed it had been hit by a ransomware attack. The company shut down its entire pipeline system, roughly 5,500 miles of infrastructure, as a precaution. As I write this, the pipeline remains offline, and the implications are still unfolding. But the technical lessons are already clear, and they should concern every engineer working on systems that touch the physical world.
The Attack Vector: DarkSide and Double Extortion#
The attack has been attributed to DarkSide, a ransomware-as-a-service (RaaS) operation that’s been active since mid-2020. What makes DarkSide particularly insidious is its “double extortion” model: they don’t just encrypt your data, they exfiltrate it first and threaten to publish it if you don’t pay.
From what’s been reported so far, the attack targeted Colonial’s IT systems — the business side — rather than the operational technology (OT) systems that directly control the pipeline. But here’s the critical detail: Colonial shut down the OT systems preemptively because they couldn’t be confident the attackers hadn’t moved laterally into those networks.
This is the nightmare scenario that industrial control system (ICS) security professionals have been warning about for years. The convergence of IT and OT networks creates attack surfaces that didn’t exist a decade ago. When your business systems and your control systems share any connectivity whatsoever, compromising one puts the other at risk.
The Air Gap Myth#
I’ve spent years working on systems where the assumption was “our critical infrastructure is air-gapped.” In my experience, true air gaps are extraordinarily rare in practice. What most organizations have is a belief in an air gap, supported by a network diagram drawn five years ago that no longer reflects reality.
The truth is that modern industrial systems need data flowing between OT and IT layers for monitoring, analytics, and optimization. Someone eventually connects a historian server. Someone sets up remote access for a vendor. Someone plugs in a USB drive to update firmware. Each of these is a bridge across the supposed gap.
Colonial Pipeline reportedly had some level of network segmentation between IT and OT, but the fact that they couldn’t confidently say “no, the attackers can’t reach our pipeline controls” tells you everything about how effective that segmentation actually was.
For those of us building and maintaining systems: network segmentation isn’t a one-time architecture decision. It’s an ongoing operational discipline that needs continuous verification. Tools like Shodan regularly find industrial control systems exposed directly to the internet. If external researchers can find them, so can DarkSide.
Ransomware as a Supply Chain Problem#
What strikes me about this incident is the scale of the downstream impact. Colonial Pipeline is a single company, but its shutdown affects fuel distribution across the entire eastern United States. Gas stations are running dry. Airlines are scrambling for fuel. And it’s all because of one compromised organization.
This is a supply chain problem in the most literal sense. We’ve spent the last year talking about software supply chain security — SolarWinds, Codecov, dependency confusion attacks — but Colonial Pipeline reminds us that physical supply chains have the same single-point-of-failure vulnerabilities.
As engineers, we need to think about this from both directions. If you’re building systems for critical infrastructure, the security bar isn’t “good enough for a SaaS product.” You need defense in depth, you need incident response plans that assume breach, and you need the ability to operate in degraded mode rather than shutting everything down because you can’t verify what’s been compromised.
Incident Response: The Hard Choices#
Colonial’s decision to shut down the pipeline entirely is being second-guessed by some, but I think it was the right call given the information they had. When you can’t verify the integrity of your control systems, running a pipeline that carries highly flammable materials is an unacceptable risk.
But it exposes a massive gap in most organizations’ incident response planning: what do you do when your IR plan says “isolate affected systems” but isolating those systems means shutting down critical national infrastructure?
This is where tabletop exercises earn their keep. Every organization running critical infrastructure should be running scenarios like this regularly. Not just “ransomware hits the file server” but “ransomware hits the business network and we can’t verify OT integrity.” The decisions you need to make in that scenario — who has authority to shut down operations, how do you communicate with customers and regulators, what’s your manual operations fallback — those decisions need to be made before you’re in the middle of a crisis.
My Take#
I’ve been in this industry long enough to have watched the IT/OT convergence happen in real time, and the Colonial Pipeline attack is, sadly, exactly the kind of incident many of us have been predicting. The uncomfortable reality is that our critical infrastructure was built in an era when “connected” meant something very different, and we’ve been bolting on connectivity faster than we’ve been bolting on security.
The DarkSide group has reportedly said they “didn’t intend to create problems for society” and only wanted money. That’s almost darkly funny — it shows how even the attackers didn’t fully grasp the cascading effects of what they were doing. When you attack infrastructure at this scale, intent is irrelevant; impact is everything.
For those of us in the developer and DevOps world, the takeaway is this: the systems we build don’t exist in isolation. That API you’re connecting to a SCADA system, that dashboard you’re building for pipeline monitoring, that cloud migration you’re planning for operational data — all of it is expanding the attack surface of systems that people depend on for basic necessities.
Security isn’t someone else’s problem. It’s built into every architectural decision we make, every network connection we allow, and every assumption we fail to verify.