What is 'Resilient Patching'?

Keeping systems and software patched and up to date has become a constant mantra within cybersecurity circles. The majority of cybersecurity incidents occur due to unpatched systems and software.

According to a conducted by the Ponemon Institute, 60% of breaches in 2019 were linked to a vulnerability in which a patch was available, but not applied.

In fact, according to the UK’s National Cyber Security Center, the one thing that an organization should do to protect from cyberattacks is implementing updates and patching for known vulnerabilities.

That’s because threat actors are constantly probing organizations for known software and system vulnerabilities to exploit.  As an example, the Wannacry ransomware crypto worm is still used today four years after it was first implemented as systems to this day still remain unpatched for their targeted vulnerability.

The Challenge of Traditional Patching

We all know that keeping systems and software fully patched is essential to protect against malware and cyberattacks.  So why don’t IT departments do it?  Well for one, we ‘know’ a lot of things.

We know that we should exercise three times a week, stay away from sugary drinks and go to the doctor for annual checkups.  While we intend to do these things, we often don’t for a variety of reasons.  It’s the same when it comes to the traditional physical patching of systems and software.  Some of the reasons why IT tends to procrastinate patching efforts include the following:

• The list of systems and software that need patching has become overwhelming
• Organizations are completely dependent on their invested technologies and can’t afford for systems and applications to be taken offline for necessary patching
• Because there are so many moving parts that must work cooperatively within today’s systems, patches must often be implemented in a testing environment first to discover introduced glitches and incompatibilities
• The network can slow to a crawl for organizations with a large on-prem presence whenever a critical patch is needed across the entire IT estate
• Because IT staff are so stretched today, they must prioritize patching efforts while also juggling other projects that bring greater value to the organization

While it would be nice if enterprises could simply implement automatic patching of ‘everything’ in the same fashion that many personal computer users do, it’s just not possible for today’s complex enterprise environments.

The patching race

Patching is a race between defenders and threat actors. Once a patch is released, it’s a matter of who gets there first. Defenders need to patch everything perfectly, and on time; while attackers need only find a single vulnerable system to establish their attack beachhead. Even for IT departments that are vigilant about patching, they often find themselves waiting for the designated release dates such as ‘Patch Tuesday.’  It is no surprise why the attackers have the advantage.

The Practice Known as Patch and Pray

There is a lot to pray for when it comes to patching.

Patching makes you reliant on other people to patch and release their binaries.  For developers, it is code that they don’t normally build as part of a software release.

Software companies depend on bug bounty hunters and external cybersecurity teams to discover vulnerabilities within their own code.  The whole process in fact requires an involved leap of faith.

One must assume that the fully patched software behaves as intended and that an attacker can’t simply gain influence over the patch as well.

A ‘patch and forget strategy’ is all too common as organizations don’t have the time to check on applied patches.

And then there are those instances in which a patch goes bad and creates disruptions that must be remediated.

If patching is so important, it is clear there needs to be a better way.

WAF Style Virtual Patching

Some have turned to virtual patching.

was a concept introduced by the web application firewall (WAF) industry. This WAF style of patching is about applying a mitigation signature in an external appliance (WAF) to ensure that a designated attack never reaches the application.

There are a few problems with this style of virtual patching, however:

• These signatures are easily mutated and defeated by an attacker.
• The appliance becomes a choke point and is typically applied at the perimeter.
• There is limited capacity for these rules/signatures.
• It requires complex processing and doesn’t scale adequately for cloud-native workloads.

While WAF-style virtual patching alleviates some of the weaknesses of traditional physical patching, it too has far too many dependencies while introducing its own sets of challenges.

Resilient Patching

Fortunately, there is a new way to patch and protect today’s software. This modernistic solution is known as resilient patching.

Resilient patching does not involve the perpetual chasing of vulnerabilities and signatures. Like its virtual patching predecessors, it is applied externally.  The difference though is the way in which it creates a virtual operating environment that enforces the Principle of Least Privilege (PoLP) to all applications.

In the same way that PoLP policies deny standard users blanket level local admin rights, resilient patching locks down the application by enforcing its pre-specified behavior, thus locking any and all deviations.

As a result, an attacker can reach an application, but fail to gain influence over it.  We hold the app to pre-specified behavior and lockout deviations.