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.

Risk

End of Bibblio RCM includes -->
4/15/2021
10:00 AM
Fred Langston
Fred Langston
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv

Nation-State Attacks Force a New Paradigm: Patching as Incident Response

IT no longer has the luxury of thoroughly testing critical vulnerability patches before rolling them out.

Patching security vulnerabilities has always been the most important security activity an IT team does. For the 25+ years I've spent in security, keeping systems up to date with security patches has been recommendation No. 1 in any set of IT best practices. And during most of this time, we have had the luxury of patching at our own pace.

We've agreed that 30 days to apply patches is the standard of good practice and that the IT team should expedite applying critical severity security patches. But now, after a three-month period when zero-day exploits were identified for SolarWinds, Accellion, Exchange, Chrome, iOS, Android, BIG-IP, and more, and with 11 zero-days identified in just one week, we must accept the reality that the old best practices are just not good enough anymore.

Related Content:

Rethinking Cyberattack Response: Prevention & Preparedness

Special Report: How Data Breaches Affect the Enterprise

New From The Edge: 9 Modern-Day Best Practices for Log Management

Every time we begin the next wave of incident responses (IRs) after each zero-day exploit is identified in the wild, we send out urgent messaging to help address these critical emerging threats. And the primary thing I've said over and over again is that any security patch for a zero-day or that addresses a critical severity vulnerability must be treated as a Level 1 security incident.

Because the bad actors know that most organizations do not patch faster than 30 days, and a huge number do not patch well at all, it's open season for the nation-states and their criminal advanced persistent threat (APT) groups to literally lay waste to wide swaths of industry and government. Our current approach to address these threats is failing in epic fashion right before our eyes.

Why It's Better to Risk an Outage
Security practitioners have long sympathized with the risks IT faces in emergency security patching. We have even tacitly suggested that, since it is a massive problem to risk bringing down critical systems and affecting operations when deploying a patch, it's OK to move methodically, take the time to test thoroughly, and plan a measured rollout. The bad actors' tactics are forcing us to change, no matter how strong the resistance. Once a zero-day is in the wild, every potential threat actor on the planet will sprint at top speed to use that zero-day exploit as widely as possible.

And if you wait to patch, you will be victimized and likely suffer a massively disruptive IR event that is likely to flatten the systems you were trying so hard to keep operating, with the data on those systems staged for sale on Dark Web auction sites. Ransom demands are hitting tens of millions of dollars — especially if more than one APT group is actively exploiting the same vulnerability.

Even if you pay the ransom, you'll spend $20,000 to $500,000 or more in response and rebuilding costs, not to mention the expense of service disruptions, lost revenue, fines, audits, higher insurance premiums, public relations campaigns to repair your reputation, and more.

In nearly every case, if the victimized organization had treated the zero-day vulnerability patch as an emergency, Level 1 security incident, activated their IR plan, and developed and implemented a real-time method to rapidly test and deploy the security patch, they would have avoided the costs of rebuilding from the ground up. They could also have avoided disruption of business operations, loss of service and revenue, lower customer retention, tarnished company reputation, increased regulatory scrutiny and potential fines, etc.

Incipient Security Events Require a Level 1 Response
It is vastly less expensive, less disruptive, and less impactful to call a cybersecurity incident and activate an IR plan that includes a playbook for responding to an incipient security event whose remediation is emergency testing and patching of systems.

The paradigm shift here is the concept of an incipient security event — one that hasn't happened yet, but it will, if given enough time. And that window before the bad actors try to use the exploit against your assets has already started to close.

IT and security operations must adopt the concept of an incipient security event that requires a Level 1 incident response. The inconvenience of an Exchange outage over a weekend due to a patch is insignificant in cost and impact when compared to a cyberattack on that same Exchange server that takes down every system on your network.

This is the new reality. This is not the security team harping about good cyber hygiene; this is a new paradigm forced by attackers who are more sophisticated, organized, and motivated and have found an attack methodology that pays off like a rigged slot machine.

Crucial severity vulnerabilities must be treated as incidents requiring an emergency response. This means changing foundational concepts in IT management and building something new. But because we cannot control the attackers' methods, and they have found the holes in our IT processes, they will bury us if we fail to respond.

Fred Langston CISSP, CCSK, a co-founder of CI Security, has long been at the forefront of information security. He has over 28 years of professional information security experience working for hundreds of clients to create effective information security strategies and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
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
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
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
Video
Cartoon
Current Issue
Practical Network Security Approaches for a Multicloud, Hybrid IT World
The report covers areas enterprises should focus on for their multicloud/hybrid cloud security strategy: -increase visibility over the environment -learning cloud-specific skills -relying on established security frameworks -re-architecting the network
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
CVE-2022-30333
PUBLISHED: 2022-05-09
RARLAB UnRAR before 6.12 on Linux and UNIX allows directory traversal to write to files during an extract (aka unpack) operation, as demonstrated by creating a ~/.ssh/authorized_keys file. NOTE: WinRAR and Android RAR are unaffected.
CVE-2022-23066
PUBLISHED: 2022-05-09
In Solana rBPF versions 0.2.26 and 0.2.27 are affected by Incorrect Calculation which is caused by improper implementation of sdiv instruction. This can lead to the wrong execution path, resulting in huge loss in specific cases. For example, the result of a sdiv instruction may decide whether to tra...
CVE-2022-28463
PUBLISHED: 2022-05-08
ImageMagick 7.1.0-27 is vulnerable to Buffer Overflow.
CVE-2022-28470
PUBLISHED: 2022-05-08
marcador package in PyPI 0.1 through 0.13 included a code-execution backdoor.
CVE-2022-1620
PUBLISHED: 2022-05-08
NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 in GitHub repository vim/vim prior to 8.2.4901. NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 allows attackers to cause a denial of service (application crash) via a crafted input.