If ever in a freezing cold room with IT/Sec-Ops people, raising the topic of patch management can heat it up fast. Patching applications on an organization’s client and server endpoints is far more challenging than most people realize. The uncertainty over what applications need to be patched in the next cycle makes it seem a never ending game of whack-a-mole. Worse, if you’ve ever played on one where hitting the mole doesn’t always count, and you had to play while standing on one leg, then you can begin to intuit how challenging patch management can be. Unfortunately, the consequences of failure are far worse than not winning a gaudy stuffed animal. All enterprise breaches due to non-zero-day application vulnerability exploit attacks would have been avoided had patch management been perfect. Fortunately for the weary, there is an astonishingly simple, effortless, and effective way to snuff out those moles for good (figuratively speaking of course), including those invisible ones otherwise known as zero-day attacks.

Patch Management Challenges Highlights

Entire books are required to master the topic. The bullets below may reveal facets of patch management that help you better appreciate the challenges.

●      Amongst the millions of patches implemented by enterprises monthly, there are frequently problems that go unnoticed until after a forensics report traces a breach back to a failed endpoint patch.

●      A single application patch can involve replacing or adding multiple files as well as settings. Any one of these can fail.

●      Enterprise grade tools strive to verify each intended change yet they still fail sometimes.

●      Testing patches prior to deployment to ensure nothing breaks that would disrupt or lower productivity is time consuming and hard to be done thoroughly and methodically.

●      Incompatible patches require choices between risk and productivity.

●      IT-Ops is typically pressured to do testing and implement them with little time and few resources. Vital personnel are sometimes pulled from strategic projects to assist.

●      IT-Ops must prioritize patches because not all can be done within the current cycle.

●      Scheduling, bandwidth considerations, and numerous other matters complicate patch management.

●      Organizational dynamics complicate it whereby different endpoints are patched by different IT groups with different tools.

●      “All or nothing” patches, where all are in a single package, means administrators can no longer withhold problematic patches. It generally complicates compatibility testing. Worse, it can easily delay a patch to a highly exposed application.

●      Patch tools do not support all 3rd party applications and can lag behind considerably on supporting the latest version.

●      Virtualization poses all kinds of problems (a topic of its own).

●      Patching servers is far more difficult than client endpoints: limited windows, host restart restrictions, clustered applications, and inter-dependencies with other server applications and infrastructure.

●      Unknown vulnerabilities or known ones without any available patches, a.k.a. zero-day vulnerabilities.

I’ve only scratched the surface. If you’re one of those that annually reads the Verizon Data Breach Investigations Report (DBIR), perhaps you have a better understanding of why you see the same data breach cause reported year after year after year. I’m referring to breaches tracing back to application exploit attacks that could have been avoided with patches that had been available for months or sometimes years earlier.

Other Means for Mitigating Application Exploit Risks

What is an enterprise to do when software vulnerabilities cannot be patched or software patches cannot absolutely be relied upon? There are a number idiosyncratic workarounds that involve settings, disabling features or functions in applications, filtering out select network communications, and more. Instead of detailing these, other than to say that applying such countermeasures does not scale easily and significantly complicates change management practices, I’ll explore two classes of tools that analysts often recommend.

Anti-Exploit Technology

Microsoft invented this many years ago. It was known as Enhanced Mitigation Experience Toolkit (EMET). The concept called for code injecting ‘blobs’ into the memory of applications to block specific “exploit patterns”. Ideally, different ‘blobs’ would be used for different applications that would be specific to their vulnerabilities. The more specific they are to the application and the vulnerability, the more effective these can be.  This idealized form proved more onerous than patch management. The ‘exploit patterns’ had to be formulated, application compatibility had to be tested, and a variety of other problems could ensure. Microsoft abandoned this approach, watered it down, and folded it into Windows 10.

Other vendors now offer anti-exploit features in their endpoint protection agents. Implementations vary greatly. Some vendors do little more than make use of what Windows 10 does. Others add to it considerably. The common theme amongst them all, however, is that basically the same ‘blobs’ are injected into different applications. These features are fairly ‘set and forget’ but their value is suspect. Many feel anti-exploit features are no more than a paper tiger.

I’ve talked with many market analysts about anti-exploit technology. I asked each how they ‘knew’ that the features were delivering value. The short answer is that they don’t. Before banking on their value, I strong suggest asking users with first-hand knowledge as to what they have observed in the logs of their respective tools.

Host Intrusion Prevention System (HIPS) Technology

These tools can enforce policies in multiple dimensions: file system operations, registry operations, memory operations, and even API operations.  Few organizations have specialists to craft such policies. Most must rely on vendors to craft application/vulnerability-specific policies. I’ve talked to many in the US Department of Defense who have opined on difficulty, level of effort, resulting schedule delays, and overall burden on change management resulting from using HIPS tools.

There’s little to no data publicly available on how well application vulnerabilities are covered by these mitigations and even less on how effective they prove to be in the field. As with anti-exploit, ask those actually using them about actual observations of their delivering value. Explore the compatibility testing operations and overall level of effort. I’m confident you’ll find yet another tool that looks hopeful or even pedantic on paper but ineffective and onerous in reality.

AppGuard’s Mistrust of Applications Delivers a Simple, Effortless, Effective Mitigation to Application Exploits

Let us reconnect this back to patch management before explaining how AppGuard does this. You don’t always have a patch to implement. You can’t patch an unknown vulnerability. History shows what was presumed patched actually wasn’t. And implementing patches can be too disruptive to production operations.

Application exploits effectively hijack an application, causing it do harmful actions: download and launch an executable from the Internet, alter system files, and/or inject code into the memory of another application, to name just a few. Exploits can occur at at any moment. This is one reason AppGuard does not trust the applications and utilities on endpoints. This is why AppGuard ‘places them under guard’, hence the name, AppGuard.

Any application can be guarded. What results is that any process spawned becomes a ‘guarded process’. For any ‘guarded process’ to interact with anything else on the endpoint, conceptually, it must communicate that intent to the operating system kernel, which would then facilitate writing to some file, altering a registry key, or reading/writing to the memory of some other application. AppGuard’s lightweight driver acts like a “kernel-level traffic cop”, intercepting these ‘intentions’ for action on the endpoint and making a real-time decision as to whether or not to allow an action to proceed. It the action is to alter ‘system-space’ or mess with the memory of another application, AppGuard blocks the action before it can occur. If the action is for anything else, AppGuard allows it to proceed. This effectively isolates the application, preventing the application exploit from carrying out harmful actions. Further, AppGuard does not trust ‘user-space’ because it is too easy to get an unknown executable or script there. So, AppGuard only allows those ‘trustworthy’ (e.g., digitally signed application, validated in real-time) to launch, or not. Those allowed to launch are ‘guarded’. All this is done without any of the cumbersome, brittle mechanisms such as host-based sandboxing or process virtualization.

Unlike sandboxing and process virtualization, AppGuard can ‘guard’ any application. Even better, AppGuard only needs to know the full path name of an application’s parent or primary executable. It doesn’t need to know to know all of the excruciating details of each application as does whitelisting, HIPS, behavior analytics, host-based sandboxing, and process virtualization. AppGuard see every child, grandchild (and so on) process that the parent spawns and dynamically guarded them. It discovers this at run-time (BTW, this is patented).

This means that AppGuard naturally adapts to endpoint changes. After an application is updated or patched, the parent executable’s full path name generally does not change. Consider that of Microsoft Word, “c:\program files\...\winword.exe”, which has not changed in over a decade. It’s the ‘children’ and ‘grandchildren’ that change, and AppGuard doesn’t need to know them before run-time. Slight digression, some vendors such as Adobe change some of their application full path names annually. A simple ‘wildcard’ symbol in the policy rule deals with that.

So, the applications and utilities on your endpoints can be ‘placed under guard’ by AppGuard such that application exploits cannot do harmful actions to the endpoint yet this protection endures months and in many cases years of application feature updates and security patches.

AppGuard customers in over 100 countries in all kinds of industries see blocking events in their AppGuard logs EVERY TIME their endpoints are attacked with an application exploit. This tiger has teeth!

Conclusion and Parting Thoughts

One may be tempted to forgo application patching with AppGuard. We don’t recommend that. Theoretically, a hijacked application poses risks, albeit very small. Instead, we advise our customers to implement patches but to do so when they feel they are ready. Let AppGuard alleviate the pressure so the patches can be thoroughly tested and so the servers can comfortably be patched within narrowly confined maintenance windows. Allow me one bold statement, if every enterprise breach due to an application exploit, had instead deployed AppGuard, none of those breaches would have occured. Also, remember that cold room filled with the IT/Sec-Ops people? You’d have to raise a different topic to warm up the room if they all deployed AppGuard.

AppGuard is NOT Limited to only Blocking Application Exploit Attacks. AppGuard Blocks Fileless, Pass-the-Hash/Ticket Attacks and Whatever Else Worries You, and Without Breaking a Sweat.