Why CISOs aren’t waiting around for vendor patches

This increased concern should lead to a better security posture, but instead has led to misguided panic and a doomed bid to cover all bases to great expense and with some unfortunate by-products.

Many IT leaders are led to believe there are no alternatives to the merry-go-round of paying an annual maintenance “tax” and applying endless disruptive software patches.

But this overlooks the modern security threatscape, and more importantly ignores the fact that most enterprise software companies are not security companies. Vendor-supplied ERP software patches are often just bug fixes, which are almost always tantamount to a glorified and lucrative form of bad code Whac-A-Mole.

Security patches may not be timely

Software vendors typically review bugs to ascertain how serious the bug is and how important it is to be fixed – which itself is a laborious and lengthy process.

Vendors need to identify how widely the affected library or code base was used, what platforms were affected, and its history.

At this point, vendors may learn that a bug has existed for a significant period, in some cases up to 20 or 30 years. By then, damage may already have been wrought by a cyber criminal.

Get off the security patching hamster wheel

VIEW ALL

Eventually a patch is released by the vendor – and as anyone in an IT management role will know, this is often when the pain begins.

Patching is often a lengthy and convoluted process, particularly for large enterprise platforms with extensive customisations, many of which are likely to break once the patch is applied due to some unexpected by-product of that patch’s behaviour.

Even if a company has a policy of immediate patching, it can easily be a year before the patch is downloaded, installed, tested through the landscape, and eventually applied.

IT managers must wait for the patches to be released before performing rigorous regression testing, running quality assurance, undertaking end-user testing, and repairing the customisations the patches break – all this, multiplied by every single database or application instance in the company.

This process is time consuming, risky, disruptive, and expensive.

But wait: we’re not finished. When something similar pops up again, it’ll require another run on the hamster wheel all over again as software vendors are commonly only blacklisting commands, which are often bypassed by the next command in the list.

This means customers must repeat this cycle hundreds of times over.

For instance, the Apache Struts vulnerability which led to the Equifax breach was due to an Insecure Deserialisation flaw (CWE-502, one of many further CWE:20, Improper Input Validation flaws) heavily prevalent in most applications today.

Yet the patch released to address the issue still doesn’t address the weakness of either CWE-502, or CWE-20. Rather, it only solves one exposure (CVE-2017-5638).

Meanwhile another patch was released around the same time to address a similar weakness (CVE-2017-9805).

Hundreds of patches have been released to address Insecure Deserialisation, most of which are bypassed repeatedly.

Now, cast your mind to picture the security breaches which made headlines globally over the years: Marriott, Target, AdultFriendFinder, eBay, to name just four – and not one of those was fixed with a vendor patch.

It’s more likely that companies will be undone due to inattention to weak configurations, insider threats, careless admin actions or unenforced policies.

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

In short, ERP customers are right to question whether relying on vendor patches is enough to maintain their security posture.

The bigger security picture

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

For instance, instead of the vendor patch strategy of dismantling a single SQL injection issue and keying on individual syntax vulnerabilities, modern security offerings mitigate SQL injection weaknesses as a whole.

CISOs require more modern and cost-effective security tactics such as in-memory database protections, or real-time self-protection for middleware and applications, which provide much more effective methods to addressing security issues within enterprise software stacks, while also enabling huge reductions in downtime and business disruption.

The smartest CISOs have long since realised that patching is just too impractical or even impossible for the business to continue to undertake ad nauseum, particularly given the ineffectiveness of the patches as compared to the prevalence and performance of dedicated security offerings available today.

Eric Helmer is the chief technology officer at Rimini Street.