How To Prevent Software Vulnerabilities in Commercial Applications

As businesses move further into the world of agile development, they are increasingly creating their own applications. These applications can present a host of vulnerabilities that, if not addressed, could bring down the company. But what about commercial applications – ERP or CRM systems, databases, office productivity suites, or billing software? While it’s comforting to think that these proven vendors are laser-focused on preventing software vulnerabilities, vulnerabilities occur nonetheless. In some cases, customers can pay the price.

What Are Software Vulnerabilities?

At a high level, software vulnerability is a flaw or weakness that can be exploited by bad actors. Those bad actors can use the vulnerability to gain access to an organization’s sensitive data or perform unauthorized actions. No software is immune to vulnerabilities; the key is to find and remediate them as quickly as possible.

Microsoft is a perfect example. It has a huge ecosystem of software used by the majority of companies worldwide. The sheer array of Microsoft software products means that vulnerabilities are inevitable. The recent study by BeyondTrust found that Microsoft reported 1,212 vulnerabilities in the past year, which is actually pretty much par for the course.

The pervasiveness of Microsoft software also makes it a prime target. “If I’m an attacker and I want the highest chance of success without knowing much about the organization, I’m going to assume that it uses Microsoft technologies,” said John Fung, director of cybersecurity operations at MorganFranklin Consulting. “If you can exploit something on Microsoft, your attack surface or potential list of targets increases exponentially.”

How Do Software Vulnerabilities Happen?

There are many ways that vulnerabilities can get into software, some the fault of the software vendor and some the fault of the user.

On the vendor side, errors introducing new features can lead to integration errors as well as general bugs and glitches, while upgrades can cause configuration along with permission and access vulnerabilities. Any of these errors can lead to security risks, from privilege escalation and security feature bypass to information disclosure, denial of service, spoofing, tampering, or remote code execution. The BeyondTrust study found many recent remote code execution vulnerabilities in Microsoft Exchange Server, Windows DNS Server, and Microsoft Defender for IoT.

But what about consistent upgrades and events like Patch Tuesday, a designated day each month when Microsoft releases its security fixes? Those are important but only apply to on-premises software or software that runs in private clouds. They don’t apply to the increasingly common software-as-a-service model.

There are fewer guidelines for when software is patched or vulnerabilities addressed in the cloud and no standardized reporting method for cloud-based software vulnerabilities, said Morey Haber, chief security officer at BeyondTrust.

“In the cloud, software is patched all the time, and you’re often forced to stay lockedstep with the current release,” Haber said.

Some vendors, like ServiceNow, do allow organizations to remain on older versions because of issues related to integrations or dedicated APIs, but that can present other problems. For example, organizations may lose track of vulnerabilities if they avoid the upgrade, Haber noted.

Trust, but Verify

Like so many other responsibilities in a cloud-based environment, software vulnerabilities in commercial software becomes a shared responsibility. Of course, the software vendor itself has the primary responsibility, but without involvement from user organizations, potential risks increase.

“There is a lot that companies can do,” said Elizabeth Butwin Mann, consulting leader for cybersecurity at EY Americas. “You have to look at cyberthreats and vulnerabilities as an element of the business model in which we all operate today. The nature of the environment we’re in is going to create exposures to vulnerabilities.”

An important step that IT pros can take to stem vulnerabilities is to vet prospective vendors and software before hitting the “purchase” button. Fung suggested asking vendors whether they have a secure software development lifecycle (SSDLC) program. In an SSDLC program, code is tested before it is committed.

It’s also critical to know everything you can about the vendor’s service-level agreements (SLAs) for reporting and patching, what they use to ensure code integrity on the back end, whether they use single sign-on, and whether they have SOC-2 certification. Those are the basics. “As a CISO, I won’t use a cloud solution unless the basics are there and have been verified by an independent auditor,” Fung said.

In their SLAs, software vendors typically commit to fixing the vulnerability within 30, 60, or 90 days of when the vulnerability has been disclosed. At the same time, many software agreements point out their limited liabilities, which means, in effect, that vendors will do their best to fix problems but can’t be held liable if they did proper due diligence.

Customers should find out how many vulnerabilities a software vendor has also disclosed over the past several years. If the vendor has disclosed a lot of vulnerabilities, that’s, Haber said. It’s better than not disclosing any at all, which can be a red flag.

But some of the biggest vendors, including Microsoft, are pretty tight-lipped about vulnerabilities. Because of their grip on the market, there isn’t much you can do about it.

However, large vendors have a vested interest in doing it right. Fung pointed to the example of Atlassian, which experienced a public exploit of its Confluence Server and data center software in May. The researchers who found the vulnerability reported it to Atlassian, who tried to quickly fix the issue. “They knew they had to address it as fast as possible because if they didn’t, people wouldn’t trust that their information and knowledge repositories were secure anymore,” Fung noted.

Vulnerability Scanning, Assessment, and Management Software

So, how can a company prevent software vulnerabilities when dealing with commercial software? Add some of your own tools and precautions, experts said.

At the very least, use the strong vulnerability scanning, assessment, and management tool to find, prioritize, and remediate any weaknesses. Product features should include the following:

  • Dynamic discovery and inventory
  • Asset visibility
  • Security actions prioritization
  • Broad attack vector coverage
  • real-time monitoring
  • The ability to organize host assets
  • A way to understand context and business risk

Examples of vulnerability prevention tools include CrowdStrike Falcon, ManageEngine Vulnerability Manager Plus, Nessus Professional, and Paessler PRTG Network Monitor.

“We expect that our clients will want to do some of their own vulnerability assessment, because saying it’s the vendor’s problem or responsibility doesn’t help if you get compromised,” EY America’s Mann said. “There are tones of new tools being introduced all the time that can help.”

Another helpful type of tool is cloud network application protection platforms (CNAPP). CNAPPs make sure that privileged accounts can’t be created, no malicious API calls exist, and mailboxes haven’t been granted special permission for downloads. These products, from vendors like Zscaler, Orca, Aqua Security, and Lacework, do a good job at monitoring software for vulnerabilities, permissions, and misconfigurations. Additionally, CNAPPs can find out-of-date libraries that could be vulnerable. Haber called CNAPP one of the most up-and-coming cloud-based workload protection options available today.

Finally, there is cloud infrastructure entitlements management (CIEM). ICES examines privileges and entitlements to ensure that systems are not overprovisioned or allowing bad actors to create a route or administrative account to abuse the system.

More Ways to Prevent Software Vulnerabilities

There are plenty of other steps an IT pro can take to limit vulnerabilities.

Make time to upgrade and patch — and do it immediately.

Even if it means small amounts of downtime, it’s worth it, Haber said.

Do your own asset inventory, which should include integrations.

“A lot of companies don’t even know what software they have or understand the importance of various applications to the business strategy,” Mann said.

The situation gets even more complex when figuring in customizations, extensions, and integrations, but all these connections in the ecosystems are vulnerable, she added.

Limit user access and functionality.

The less access you allow, the less that can go wrong. Active Directory is a great example. “If you know what you’re trying to accomplish and you know the tool well enough or use professional services to enable only that functionality, you’ll be limiting your attack surface dramatically,” Fung said.

That includes removing administrative rights and enforcing least privilege, both of which are critical to reducing the attack surface. Removing administrative rights is often now a requirement for cyber insurance providers and is a control consistent with zero-trust principles.

Delete your root accounts.

Your root account in AWS, for example, is the only account that performs critical functions. Even AWS recommends creating another administrative account and deleting the root account. “If a threat actor has gotten to root or privileged administrator accounts, it’s game over,” Haber said.

The Future of Preventing Software Vulnerabilities

Over time, the industry will likely develop standards for cloud-based software vulnerability identification and remediation on par with on-premises software. And it will be just in time: As software becomes more complicated and more interdependent in different libraries, more vulnerabilities will likely emerge.

For now, IT pros are best served by scrutinizing even the biggest software vendors and applying their own checks and balances.

About the author

Karen D. Schwartz is a technology and business writer with more than 20 years of experience. She has written on a broad range of technology topics for publications including CIO, InformationWeek, GCN, FCW, FedTech, BizTech, eWeek and Government Executive.

Leave a Comment

%d bloggers like this: