Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


// // //
10:00 AM
Dan Verton
Dan Verton
Connect Directly
E-Mail vvv

The Colonial Pipeline Attack Is Your Boardroom Wake-Up Call

Why business leaders must adopt a risk-led approach to cybersecurity.

Our approach to national cybersecurity is broken. And this didn't just happen recently — cybersecurity has been broken for decades.

The ransomware attack against the Colonial Pipeline system occurred almost 17 years to the day after I testified before the Senate Subcommittee on Terrorism, Technology, and Homeland Security on cyber-risks facing critical infrastructure, particularly the industrial control systems (ICS) used to manage those infrastructures. And while there have been other incidents before this one that should have sparked radical changes in our approach to cybersecurity, I, like many other longtime observers, thought (perhaps naively) that this one would be the wake-up call our business leaders needed.

Related Content:

Critical Infrastructure Under Attack

Special Report: Assessing Cybersecurity Risk in Today's Enterprises

New From The Edge: How Are Cyber Insurance Companies Assessing Ransomware Risk?

Whether or not we hit the perpetual snooze button once again remains to be seen. But there is a way forward to fix our broken system: Adopt a risk-led approach to cybersecurity that once and for all bridges the gap between cybersecurity and the business and aligns the entire enterprise to a North Star focus on what risks matter most to the organization.

The Significance of the Colonial Pipeline Attack
Everybody knew an incident like the one targeting Colonial Pipeline was coming. The warning lights have been blinking red for 20 years. It was only four years ago that the Russian threat group known as Sandworm took down the Ukrainian power grid. A year later, the NotPetya ransomware attack cost shipping company Maersk and FedEx $300 million each. There will be more Colonial Pipeline attacks on other critical infrastructures and businesses.

But what this event really demonstrates is the urgent need for business leaders and boards of directors to have a conversation with their chief information security officers about cyber-risk in terms they can understand. The loss from the Colonial Pipeline attack is enormous but also measurable. As regrettable as the event was, it may actually help some non-IT leaders understand cyber-risk. After all, that which is quantifiable is more actionable.

Cyber-risk should be viewed and treated the same as any other operational risk. Cyber threats are not hypotheticals — they are imminent and very real risks to businesses. However, without understanding that risk is a business issue, not a technical issue, critical infrastructure owners and operators will likely not focus their resources on the right things.

The ObamaTrump, and Biden administrations each introduced strategies to shift toward a risk-led approach to cybersecurity. Yet boardroom decisions do not reflect this nationally recognized — and growing — prioritization of automated cyber-risk quantification. Everything from resource allocation to operations and processes can be better managed through increased use of risk-led security programs. This approach provides more flexibility and better strategies for prioritization, and it is often more cost-effective in the long run.

Solving the Prioritization Challenge
My review of what has been reported publicly about the Colonial Pipeline attack, combined with personal conversations with one of the nation's preeminent ICS experts, leads me to believe that two main factors may have contributed to the temporary loss of this very critical piece of energy infrastructure:

  • Business and cybersecurity leaders did not have a detailed conversation about cyber-risks and the potential financial and operational impact.
    • We've known for decades that ICS systems have been operating with dangerous interconnections to business networks. A risk conversation, informed by real-world threat intelligence, would have made the ransomware scenario a top priority.

  • Like all other businesses, the cyber defenders of the Colonial Pipeline (threat analysts and incident responders) are drowning in alert data and have no way to prioritize their workflows and automate responses.
    • The Department of Homeland Security issued a ransomware alert for the energy sector just two months before the Colonial Pipeline attack. This threat intelligence should have informed risk-quantification efforts as well as orchestrated and automated responses across the entire security technology stack.

A risk-led approach to cybersecurity takes the adversary into account. Thinking like a threat actor forces you to dissect and evaluate scenarios for which to prepare — and risks to consider that may require new investment. Not only are the threat landscape and the parts of it that are relevant to your business changing, but the controls, applications, endpoints, and type of data present in your environment are changing as well. A risk-led approach moves your cyber-risk quantification effort beyond point-in-time assessments and makes it programmatic in nature.

The Colonial Pipeline attack's freeze of business-decision systems rather than control systems leads me to believe that we're still not successfully explaining the significance of cyber-risk to business leaders. The cyber-risk community needs to find a way to expose business leaders and government agencies to the consequences and potential long-term impacts of cyber threats. We need to demonstrate that, from an investment perspective, it's time for all leaders to embrace the significance of risk management. Reactive measures will not suffice, and outdated manual risk management plans will not stand up to the test of time.

Dan Verton is a former intelligence officer in the US Marine Corps and has authored several books on cybersecurity. He is currently a director at ThreatConnect. View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
6/4/2021 | 11:28:14 AM
I Think They'll Hit the Snooze Button, Again
Unfortunately, until cybersecurity failures start to hit the C-level executive in the pocketbook, nothing will change. Many of my colleagues and I have been advocating IT asset management, the foundation for IT security, for years now, only to fall on deaf ears at the executive level. That is until something terrible happens, like a failed software audit, lease penalties, or lost data. But then it's back to business as usual – focusing on P&L and shareholders. HIPAA forced the executive to be responsible, and maybe when we see some significant settlements from GDPR and other privacy laws, they will take security seriously. But until then, I'm afraid Wall Street will drive data responsibility and management maturity.
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file