Daniel Benad* explains why patching leaves a false sense of cyber security.
Strong security policies have always been critical for government agencies of all sizes, particularly as more and more look to modernise their systems and digitally transform how they engage with the public.
Yet many agencies are led to believe that patches provided by their various vendors for their ERP and enterprise software platforms is all the security they need.
They’re told that anything which prevents that patch or upgrade from being installed could open them up to criminals looking to break in at a moment’s notice.
However, this overlooks the realities of 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 to their own software and should never be confused with a proactive defence.
Furthermore, this strategy ignores the sheer effort involved in installing these patches, as well as the time it often takes to test them within the agency environment prior to implementation, which can often take up to six months by which time a new bug has likely been identified and a new patch/upgrade needs to be tested.
Unfortunately, many agencies and their IT teams are led to believe there are no alternatives to the merry-go-round of paying an annual maintenance fee to the vendors and applying endless disruptive patches, which in and of themselves are not a security posture alone.
The damage may have already been done
Software vendors typically review bugs and vulnerabilities to ascertain how serious the issue is and how important it is to be fixed – which itself is a laborious and lengthy process.
These 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, such as the recently-revealed Linux Dirty Pipe kernel bug; while not relevant to ERP systems, the Linux vulnerability has existed since 2020 and was only identified this year.
It’s akin to looking at the night sky and seeing the light from a long-dead star.
By then, damage may already have been wrought by a cybercriminal.
Furthermore, just because it’s identified does not mean a patch is immediately installed.
It may have been there for decades, sure, but it could be another year or more before a patch to fix the bug is issued.
These vendor-supplied patches and upgrades are typically sent out as a one-size-fits-all solution and rarely consider the customisations to the unique IT environments of their customers.
IT managers must then 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.
Once that’s done, there’s likely another patch that needs installation, starting the process anew – IT managers would be forgiven for thinking they’re perpetually running on the hamster wheel 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.
The fact is that vendor patches are complex and even when applied they tend to be limited in scope as they generally tackle only the issue that was discovered in the wild, and do not address the weakness as a whole.
In short, agencies which rely on an ERP or enterprise software platform should question whether relying solely on vendor patches is enough to maintain their security posture.
The bigger security picture
It’s important for agencies to not fall for the trap of the ERP vendor pushing the idea that patching must be done, or you’ll be exposed.
This is seemingly done to ensure these agencies keep paying for maintenance every year.
Patching from ERP vendors should not be seen as the key to maintaining a cybersecurity defence.
While fixing vulnerabilities is important, applying one-size-fits-all vendor patches isn’t the only way to do so, particularly as they can be disruptive.
Security is better left to the security experts; agencies should look to deploy leading cybersecurity platforms, firewalls, technologies and defence agencies to mitigate risks.
Agencies 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.
Regular penetration testing is also critical to the maintenance of a secure perimeter; rather than waiting for a software vendor to highlight a long-undiscovered vulnerability, penetration testing can regularly test the defence for holes not just in the ERP, but the entire environment.
In addition, those same bugs and vulnerabilities may be addressed by third party support and maintenance providers who aim to fix the issue at the source, immediately, rather than wait for a patch to be downloaded and tested.
Furthermore, doing so can relinquish the strain on the internal IT team to test and configure the patch for their environment, which takes significant time and resources to manage.
Ultimately it comes down to the fact that vendors of ERP and enterprise software platforms are not security companies.
They make exceptional software, but a patch alone does not equate to a cyber-defence.
The smartest IT teams have long since realised that patching is just too impractical or even impossible for any agencies to undertake ad nauseum, particularly given the ineffectiveness of the patches as compared to the prevalence and performance of dedicated security offerings available today.
*Daniel Benad, group vice president and regional general manager, ANZ and Oceania, Rimini Street.
