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 //

Vulnerability Management

3/31/2020
01:45 PM
50%
50%

Patching Poses Security Problems with Move to More Remote Work

Security teams were not ready for the wholesale move to remote work and the sudden expansion of the attack surface area, experts say.

A growing body of survey data suggests that the move to remote work has caused a growing number of headaches for security teams, especially regarding securing remote systems and maintaining up-to-date software through patching. 

In mid-March, 45% of companies encouraged workers to move to remote working, up from only 13% of companies in 2018, according to IT community Spiceworks. Yet security teams consider their company's capability to patch remote systems to be inadequate, according to a recent study released by Automox, a cyber-hygiene tools provider. While 48% of security teams patch on-premises desktops and laptops in the first three days, that declines to 42% for remote desktops and laptops, according to the firm.

"Remote desktops usually play second fiddle in terms of patching and prioritization — it's usually more difficult to manage them," says Chris Hass, director of information security and research for Automox. "Most teams have a good idea of what is going on with the corporate machines, but they often don't have any visibility into remote workers' systems, so there absolutely has been a large increase in the attack surface because of remote work."

A major impact on businesses from the coronavirus pandemic is the speed with which companies have moved to remote working, changing the way that employees access business applications and increasing the potential attack surface area — a particular headache for IT security. 

Most companies were not prepared for such a broad-based move to working remotely. While, on the whole, anywhere from 56% to 62% of employees could work from home, according to remote work analyst Global Workplace Analytics, only about 15% of respondents said their disaster recovery plans do not require any changes at all, according to a survey by Spiceworks of IT professionals

Because companies were taken by surprise, most are not prepared to patch and attest to the security of remote systems, says AJ Singh, co-founder and vice president of product management for remote management services firm NinjaRMM.

"Remote work has absolutely increased the complexity and scale of patch management in organizations," he says. "Now, in addition to maintaining and patching servers and devices on-prem, IT professionals must also manage the devices used by remote workers, making sure they are secure before accessing a business's data."

Patching is already an expensive proposition, with hundreds and thousands of vulnerabilities affecting a business's software and systems, says Sumedh Thakar, president and chief product officer at Qualys. The only way for most companies to deal with the issue is to prioritize the vulnerabilities based on the criticality of the assets affected by the issues. For example, companies should only focus on the BlueKeep vulnerability if they have Remote Desktop Protocol (RDP) services in place, for example. 

However, the move to remote work has changed the calculus of prioritization for many companies and reduced their visibility, he says.

"It is becoming immediately clear that traditional enterprise security solutions deployed inside the organization's network are completely ineffective in patching [and] remediating these remote endpoints due to the pressure they would put on VPN concentrators, bandwidth for deploying patches or sheer amount of time they would put to tweak these solutions," Thakar says, adding: "Now, prioritization based on risk becomes interesting because vulnerabilities critical for these remote endpoints are probably different than those posing risk to traditional server farms."

Automation is another critical tool for better handling the patching of remote workers' systems. To get patching under control, businesses need to have the right tools in place to automate large parts of the patching process, says NinjaRMM's Singh.

"Ultimately, companies need to accept the fact that patch management is a constant chore regardless of remote work or working in an office," he says. "For the foreseeable future, however, it will be more important than ever to make sure end users' machines are tightly secured to avoid any loss or breach of sensitive data."

For vendors, the move to extensive remote working may result in significant business. While 44% of companies had already committed to spending more on IT in 2020, now 39% have further increased their budgets, according to Spiceworks

And remote working is the area most in need of improvement, the survey found. Almost all — 92% — of IT professionals are concerned about the security of company-owned devices used from home and connecting to a home network.

Related Content

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Untangling Third-Party Risk (and Fourth, and Fifth...)."

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
3/31/2020 | 8:12:20 PM
Another variable but not an excuse
Definitely adds another complex variable to the equation but not enough to risk not patching. Servers its an easy point for me to make so I'll stay away from that. For workstations, yes it can be more difficult because if you aren't on VDI you can't clone the host before patching. However, look what happened to the pharma company Merck. They suffered a security incident from WannaCry, a vulnerability very similar to BlueKeep and it really damaged their 3rd quarter and made it impossible for them to work for a series of days.

Is it more complex, yes granted. But if you don't and you end up falling victim to an incident due to lack of patching you are putting yourself in the same predicament anyway.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.