Sound security policies have always been important but with the interconnected state of modern business, IT leaders are concerned more than ever before. However, 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 threatscape and that starts with the realisation 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 Whac-A-Mole.
Can you wait so long for a security patch?
Typically, software vendors review bugs to determine their validity and significance, which can be an arduous and lengthy process. Vendors must identify all of the possible areas where the affected library or codebase 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.”
Get off the security patching hamster wheel
But 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 customisations are likely to break due to some of the unexpected by-products of that patch’s behaviour. Even if a company 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. Oh, and then when something very similar pops up again, it’s time to revive the entire hamster wheel 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.
For example, the Apache Struts vulnerability that led to the Equifax breach 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. And THE patch that was released to address the issue still doesn’t 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. The smartest CISOs leverage the use of these technologies as a common control or compensating control as applicable to meet or exceed security auditors expectations where patching is just too impractical or even not possible for the business.
