The tedium and complexities of applying sub-par ERP bug fixes constitute a vulnerability in itself. This expert offers better alternatives…

Sound cybersecurity policies have always been important but with the interconnected state of modern business, IT leaders are losing sleep over infosec more than ever before. This rising tide has also led to misguided panic and a doomed bid to cover all bases with some unfortunate by-products.

Many think there are no alternatives to the carousel of paying the annual maintenance ‘tax’ and applying continuous disruptive software patches. But this ignores the nature of the modern security threat-scape and that starts with the realization that most enterprise software companies are not security companies and likely never will be.

ERP-vendor-supplied software patches are usually simply bug fixes, and bug fixing is almost always a glorified (and lucrative) form of bad code Whack-A-Mole.

The pain of ERP patches

Typically, software vendors review bugs to determine the validity and significance, which can be an arduous and lengthy process. Vendors must identify all of the possible areas where the affected library or code base was used, what platforms are affected, and its history.

This is the point where vendors may figure out that a bug has existed for quite some time, often up to 20 or even 30 years. In fact, many times the same issue is patched again even years after as it’s very common to “miss a spot.”

Eventually a patch is released, and this is where the true pain begins for organizations. Patching is typically a very lengthy and convoluted process, especially for large enterprise platforms where a company’s extensive customizations are likely to break due to some of the unexpected by-products of that patch’s behavior.

Even if a vendor has a policy of immediate patching (which is very rare and more likely annual or at best monthly), it can easily be a year before the patch is downloaded, installed, tested through the landscape and eventually put into production.

Customers must wait for the patches to be released, perform rigorous regression testing, run Quality Assurance, do end-user testing, and repair the things the patches break—multiplied by every single database or application instance in the company.

This is all massively time consuming, risky, disruptive, and expensive. And then when something very similar pops up again, it is time to revive the entire merry-go-round all over again, because software vendors are commonly only blacklisting commands, which are frequently bypassed by the next command in the list, and customers are forced to repeat this cycle hundreds of times over.

The other side of security patches

In 2018, the Apache Struts vulnerability that led to the Equifax breech was due to an Insecure Deserialization flaw (CWE-502, one of many further CWE:20, Improper Input Validation flaws) heavily prevalent in most applications today.

The patch that was released to address the issue still does not solve the weakness of either CWE-502, or CWE-20; it only addresses the one exposure (CVE-2017-5638), around the same time, another patch was released to address the same type of weakness (CVE-2017-9805).

This is why there have been hundreds of patches released to address Insecure Deserialization most of which are bypassed time and time again.

Beyond the things that have been patched, think of the big headline security cases over the years: Marriott, Target, AdultFriendFinder, eBay… not one was solved by a vendor patch. These companies and others are more likely to have been undone by inattention to weak configurations, insider threats, lax admin actions, unenforced policies and the like. These modern threat landscapes are causing ERP customers to question if they are really safe relying on vendor patches for their security policies.

The simple fact is that vendor patches are complex and even when applied, they tend to be limited in scope because they only address the issue that was discovered in the wild, and do not address the weakness as a whole.

The bigger security picture

Modern security solutions address almost all of the applicable common weakness enumerations, and not just individual exposure points.

For example, instead of dismantling a single SQL injection issue and keying on individual syntax vulnerabilities (vendor patch strategy), modern solutions mitigate SQL injection weaknesses as a whole.

Today, CISOs require modern and more cost-effective security strategies such as in-memory database protections; or real-time self-protection for middleware and applications; and other modern techniques that offer far more effective and proactive ways to address the security hygiene of enterprise software stacks, all with massive reductions in downtime and business disruption.

Where patching is just too impractical or even not possible for the business, CISOs can leverage the use of the aforementioned technologies as a common control or compensating control (where applicable) to meet or exceed security auditors’ expectations.