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.

Vulnerabilities / Threats //

Advanced Threats

10:00 AM
Yaniv Valik
Yaniv Valik
Connect Directly
E-Mail vvv

Texas Chose to Fight Ransomware and Not Pay. What About the Rest of Us?

Law-abiding folks like us applauded Texas for its bravery - but would we have the steel will to stand on the side of justice if it happened to us? Probably not.

There's no justice in the world — at least that's how it must feel for security admins in small towns, school districts, and other local government bodies. Already strapped for cash and operating on shoestring budgets, these organizations and institutions have become the prime target for ransomware hackers.

There is little doubt that ransomware has become a major plague for enterprises; hackers long ago discovered that most organizations would rather pay than fight. Fortunately for them, they have the resources to do so. But that's not the case for local governments. According to an August report from Barracuda, "a recent analysis of hundreds of attacks across a broad set of targets revealed that government organizations are the intended victims of nearly two-thirds of all ransomware attacks."

It's low-hanging fruit for hackers, but money is money.

Without the resources to mitigate or prevent these attacks, governments and their institutions tend to pay. Unlike a business that can declare bankruptcy or a medical practice that can disband and start from scratch when attacked, governments can't just walk away. Usually.

But when hackers took on Texas last summer, they didn't take into account the "don't tread on me" spirit of that state's residents. To refresh your memory, hackers targeted 22 municipalities in that state with ransomware and demanded $2.5 million to free up the systems, but state officials refused to pay. Instead, the state's IT officials decided to restore the affected systems. By mid-September, half of the affected towns had restored their services. The attack prompted a major re-evaluation of how Texas could avoid attacks in the future and recover more quickly if an attack succeeded.

Law-abiding folks like us applauded Texas for its bravery — but would we have the steel will to stand on the side of justice if it happened to us? Texas didn't say how much it cost the state to rebuild its systems or whether it would have been cheaper to just pay the damn ransom. And what about the days or even weeks systems were offline until they were restored? Could we — managers of businesses large or small — afford an outage of that length? Probably not. So, does that mean we have no choice but to pay?

Double-Edged Defense
The answer to that question is "yes" — unless. The only sure way to prevent ransomware attacks is to catch them before they take place — that is, before hackers are able to embed their malware into IT systems that eventually will get locked up when the malware is activated. That prevention must entail a double-edged defense: preventing ransomware from slipping into a system and preventing ransomware already inside the system from activating itself.

To keep ransomware, or any malware, out of a network is ostensibly simple: To embed itself, ransomware must be installed on a computer or device that has access to the network. E-mail is the most common delivery method; according to studies, spearphishing accounts for 91% of all cyberattacks. When a person opens a rogue attachment or clicks on a link that leads to a suspicious site, hackers can install malware, ransomware, keyloggers, or a whole host of rogue applications that can be used to steal data, shut down operations, or extort a ransom.

If you can't keep ransomware out of the system, the only alternative is to stop it before it can activate itself. One way to do that is to use artificial intelligence to take a "status photo" of a system or network: what applications are operating, what systems are in use, and how much processing power is being used in relation to the activities taking place in a system.

A security system that is constantly scanning those activities could be programmed to detect when rogue activity — not associated with any legitimate process or application — is taking place. When that activity is detected, the security system would intervene to shut down the associated process, thus mitigating what might turn out to be an attack.

Another way to prevent attacks is to set up a very strict whitelist of connections that can be made into the organization. For example, many ransomware attacks are routed through servers in China and Eastern Europe; blocking out those IP addresses for connection to the network will automatically keep out all dangers associated with those addresses. Firewalls are not sufficient because there is plenty of malware that can beat them; the messages and links that are interdicted are going to have to be examined manually.

Finally, another proactive way to avoid having to pay should a ransomware attack occur is to make sure you have up-to-date, isolated, and secure backups that are scanned by a variety of anti-malware tools on a continuous basis.

It's unfair that hackers pick on the weakest organizations, the ones with the least resources. It's also unfair that they just have to dispatch a suspicious e-mail to put their plan in motion, while we have to work very hard to prevent them from succeeding. And it's certainly unfair that our choices are either pay or work for months to repair the damage, as Texas is doing. But using the methods described here, we might have a chance to bring a little justice back into our relationship with hackers.

Related Content: 

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "CASB 101: Why a Cloud Access Security Broker Matters."

Yaniv Valik is a product management leader with a strong technical background, specializing in cyber resilience, security, and hardening of critical data systems for enterprise organizations, both on-premise and in the cloud. View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-03-01
The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previousl...
PUBLISHED: 2021-03-01
When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request...
PUBLISHED: 2021-03-01
In Dataiku DSS before 8.0.6, insufficient access control in the Jupyter notebooks integration allows users (who have coding permissions) to read and overwrite notebooks in projects that they are not authorized to access.
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.