Point/Counterpoint: Are Vendor Patches Sufficient?

Pat Phelan
VP, Market Research
3 min read
Point/Counterpoint: Are Vendor Patches Sufficient?

Enterprise software customers worldwide view cybersecurity as a top technology challenge. Cybercriminals are always active, so ERP security must be, too. But there remains some chatter about how best to manage the concern. It seems the long-standing protocol of relying on vendor patches for ERP security is ripe for revisiting.  

Why vendor patches?  

Vendor patches may be considered a sort of default option: the patches are issued by the vendor that owns the software; the vendor created them, so one assumes the patches work as intended. Customers typically have access to security patches for releases that are fully supported by the vendor. Some may also believe it’s simpler to deal with the same vendor on patching than to engage a wholly new provider, no matter how easy that new provider is to work with. Call it a status quo mindset.  

Another big reason many organizations stay with vendor patches: a concern that third parties will be unable to get to the source code for legal or structural reasons. On the surface, that seems to be a very big deal, and there’s more to the story.  

Counterpoint: Why vendor patches can be inadequate for ERP security 

Let’s start with commentary from a paper from Aberdeen Research: “In a traditional patch-oriented approach to enterprise software security, implementing vendor patches is a process that never ends — and for about 20% of known exploits, it never fully closes your window of vulnerability.”  

The paper details fundamental shortcomings of vendor patches, which relate to time and scope.  

Time in terms of: 

  • Days/weeks/months for a vulnerability to be discovered 
  • Days/weeks/months for it to be disclosed  
  • Days/weeks/months for vendors to make a patch available 
  • Days/weeks/months for a patch to be implemented by ERP administrators 

Sometimes vendors simply discontinue full support for their own older systems or OEM platforms leaving those systems vulnerable. Because vendor patching typically fails to cover custom code, it leaves companies exposed in those areas, too.  

For vendors, a solution to the vulnerability is almost always a patch. Not so with third-party providers, that are able to provide more comprehensive security solutions beyond patching alone.  

Manage for risk, rather than vulnerabilities 

Third-party support providers can engage in nonproprietary solutions, opening possibilities up to the very best patching solutions, rather than simply what the ERP provider has devised. Third parties can discuss risks and mitigations, for example. And if vendor patches cannot eradicate the vulnerability, non-ERP security partners can talk about mitigating the risk that remains. Nonpatch protocols such as properly segmenting networks and adjusting access controls can effectively address risk even when no patch exists.  

The same Aberdeen paper reveals that 22,000+ vulnerabilities were discovered in 2020. Vendors made patches available for only 70% of them by or near zero day or when the vulnerability was discovered. This presents a huge opportunity for cybercriminals to take advantage of the more than 6,000 known exploits. Ninety days later, 12% of known vulnerabilities remain unpatched by vendors, and virtually all have been exploited. Clearly, a vendor patch solution alone could be inadequate.  

Common weakness enumeration  

By contrast, a risk-focused approach attacks the entire class of vulnerabilities, rather than individual instances. That means it not only provides broader protection but also defends against undetected threats within the covered class. The Aberdeen paper describes this as a virtual patch approach. We also think of it as common weakness enumeration (CWE) level versus vendors’ common vulnerabilities and exposures (CVE)-level approach. 

Downtime is a common part of the patching process. Practitioners will typically time the downtime to avoid business disruption. But first, they have to apply the patches in a test environment and run regression testing, which is a high-effort activity required each time they choose to apply vendor patches. Virtual patches don’t require that, which saves significant time and reduces the risk of a patch disrupting existing code.  

Layered security approach for the win 

Conducting business in the 21st century is complex. Malicious actors are smart, tenacious, and resourceful. Defense for ERP systems must be, too.  

Assuming no single security solution is impervious, a defense-in-depth approach, focused on risk versus vulnerability, would seem more likely to limit the likelihood of a breach, its magnitude if one does occur, and the chance that it remains hidden.  

Vendor patches alone won’t meet the challenge.  

You might also like: