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.

Application Security

11/1/2017
04:18 PM
Curtis Franklin
Curtis Franklin
Curt Franklin
50%
50%

WannaCry Was an Avoidable Mess for NHS

A new report says that the UK's NHS could have avoided WannaCry entirely. Is it possible to secure a network from the ravages of bottom-line focused management?

How much security can technology provide? More to the point, how much insecurity can technology overcome? It's the kind of question that makes entrepreneurs dream and executives worry.

The great divide between technology and practice has been newly illuminated by a report on the National Audit Office's investigation of the WannaCry attack that hit the National Health Service. Here's the shocking news: It could have been stopped.

Now, anyone who followed WannaCry, how it spread and what it did, knows that millions of organizations around the world were not hit by the attack because of the operating systems they use or precautions they had taken. In the case of the NHS, it turns out that they were vulnerable and knew they were vulnerable at least a year before WannaCry.

The service had begun to respond, but the response was a variation on the old management favorite, "We'll fix it when we eventually replace the systems now using vulnerable software." Unfortunately for the NHS and at least a few thousand of its patients, WannaCry didn't wait for "eventually."

A decision to remediate by replacement, and wait until the normal refresh cycle plays out to replace, is a management decision, not a security team decision. And it is, let me emphasize, a decision based on money. Most security decisions are, at their core, motivated by money, but in this case it was a gamble that was lost in very public fashion.

Let's all admit something: If we knew -- really knew -- that every piece of hardware and software attached to the network was fully patched and up to date, and that every application was written to best practices standards for robust, secure behavior, then there is a great deal of funding currently sent to security spending that could go elsewhere. A non-trivial fraction of our total security spending goes to papering over holes that we are confident exist in our applications and infrastructure.

In talking with engineers, developers and security researchers it has become obvious that there is a great deal of development going on that is intended to, in blunt terms, protect us from ourselves. We want to be secure, but we don't want any "friction" in our transactions. We want our systems to be safe, but we don't want to take the time to test systems for security. We want to have secure applications, but we demand that they be updated hourly while hoping they'll be safe.

Throughout all of this we have to come face to face with the limits of technology. Security systems are becoming more capable, more flexible and faster, but they are constantly running up against failures in policy, process and human behavior. The day may come when scientists give enterprise networks at least a temporary advantage over the criminals who want to get in. I'm not convinced that we will ever have designs that keep us in front of short-sighted decision-making and ill-considered behavior for any meaningful length of time.

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Register for Dark Reading Newsletters
White Papers
Video
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20934
PUBLISHED: 2020-11-28
An issue was discovered in the Linux kernel before 5.2.6. On NUMA systems, the Linux fair scheduler has a use-after-free in show_numa_stats() because NUMA fault statistics are inappropriately freed, aka CID-16d51a590a8c.
CVE-2020-29368
PUBLISHED: 2020-11-28
An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.
CVE-2020-29369
PUBLISHED: 2020-11-28
An issue was discovered in mm/mmap.c in the Linux kernel before 5.7.11. There is a race condition between certain expand functions (expand_downwards and expand_upwards) and page-table free operations from an munmap call, aka CID-246c320a8cfe.
CVE-2020-29370
PUBLISHED: 2020-11-28
An issue was discovered in kmem_cache_alloc_bulk in mm/slub.c in the Linux kernel before 5.5.11. The slowpath lacks the required TID increment, aka CID-fd4d9c7d0c71.
CVE-2020-29371
PUBLISHED: 2020-11-28
An issue was discovered in romfs_dev_read in fs/romfs/storage.c in the Linux kernel before 5.8.4. Uninitialized memory leaks to userspace, aka CID-bcf85fcedfdd.