Sound security policies have always been important, but IT leaders are more concerned with the interconnected state of modern business 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 threat landscape. That starts with realizing 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.
Can You Wait So Long for a Security Patch?
Typically, software vendors review bugs to determine their validity and significance, which can be arduous and lengthy. Vendors must identify all 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. The same issue is often 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 actual 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 company has a policy of immediate patching (which is very rare and more likely annual or at best quarterly), it can easily be a year before the patch is downloaded, installed and 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 that 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. 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 hundreds of patches were released to address Insecure Deserialization, most of which are bypassed time and time again by hackers. 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 discovered in the wild and do not address the weakness as a whole.
There must be (and there is) a better way.
The Bigger Security Picture
Modern security solutions address almost all applicable common weakness enumerations, 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 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.