Vulnerability Management: Monitoring your Application Patch compliance

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someone

One of the most important preventative cyber mitigation strategies for security managers to make sure organisations adopt is a timely approach to Application Patching. Let’s look at why application patching is so important and how this fits into your overall vulnerability management process.

Why Do We Patch Applications?

User applications are a common target for attackers, this is why the Australian Signals Directorate (ASD) incorporates a ‘Patch Applications’ mitigation strategy in it’s Essential Eight security controls.  Adversaries intending to steal corporate data target user applications since they directly interact with users’ documents, files and folders.

Applications can be self-contained on the user’s PC or they have multiple components in two-tier or three-tier solutions, where any compromise affords the attacker greater access. A search on NIST’s National Vulnerability Database[1] for entries relating to Oracle, for example, returns a count of 6,360 individual vulnerability records. In the last three months alone (at the time of writing) 444 unique Oracle vulnerabilities were identified, with the knock-on effect of enterprise applications being exposed to attackers through these attack points. Looking at Adobe, a quick search over the last three months reveals 82 unique vulnerabilities, many of which have high or critical severity ratings.

These searches show that even the most reputable application providers publish products that are riddled with vulnerabilities, so patching and monitoring for vulnerabilities must be extended to every application you host, not just the common ones. If designers in your marketing team use Adobe’s Creative Cloud suite, you have to monitor every one of those applications and roll out patches when available.

Patching or Vulnerability Management?

The issue with manual tracking of application vulnerabilities is that it is time consuming, especially when there is more than a handful to keep tabs on. It’s all too easy to miss some. This is why security teams resort to implementing a vulnerability management system to track and assess their organisation’s exposure, reporting on patch deficiencies and misconfigurations.

 The Vulnerability Management Lifecycle

The main aim of a vulnerability management system is to help reduce the time applications are vulnerable to attack. Three distinct time epochs need consideration for each vulnerability, shown in Figure 1. First, the time between the vulnerability notification sent to the vendor and that notification made public is important. There is a lag between the vendor learning of the vulnerability and that vendor coding, testing and releasing the public patch. This epoch is impossible for organisations to manage, since the only course of action is to apply the patch – which at this stage you don’t have. Compensating controls in security architecture can provide some level of protection, such as updated IPSs rules, firewall blocks and monitoring using a SIEM to look for indicators of compromise. However, vendor patches are usually released at the same time as the vulnerability notification, so the risk is (mostly) insignificant.

Responsible Disclosure

Most vulnerability researchers practice responsible disclosure. This means all stakeholders (vendor, researcher, NIST, etc.) agree on a period of time for the vendor to patch the application before the vulnerability details are made public. The public vulnerability notification is then made at the same time as the vendor releases the patch, so administrators can fix the problem immediately.

The vulnerability management cycle, step 1 - notification

Vulnerability Notification

The vulnerability management cycle, step 2 - Patch Released

Patch Released

The vulnerability management cycle, step 3 - Patch Applied

Patch Applied

Figure 1 The three stages of a vulnerability’s lifecycle

A bigger problem is the lag between the time the patch is released and its deployment to your end systems. When a vulnerability is disclosed to the public, attackers begin developing exploits, targeting the weaknesses to find ways to elevate privileges, open back doors and override user controls.

If your organisation takes four weeks to roll out a patch and the hackers take one week to build an exploit, you are at risk for three weeks. This window of opportunity is enough for attackers to detect your exposure, break into your network and steal your data. This is why a vulnerability management system is recommended for monitoring and reporting on your entire infrastructure, across client systems, network systems and servers.

Vulnerability Management Systems in Decision Support

The best approach to application patching is to use a vulnerability management system as a patch monitor as well as a configuration checker. Vulnerability management systems, such as those from Qualys, SAINT and Tenable Network Security, perform full scans of every device on the network, searching for vulnerabilities in the device’s current state. Furthermore, these tools can perform what are known as credentialed scans, where they obtain login rights to endpoints, so they check what’s actually installed on the computer and how it has been configured. They perform a full patch audit and configuration check, highlighting where applications require patches or configuration changes to remove risks.

Vulnerability management systems also report in real-time, continually sweeping through the network, looking for changes, while ingesting vulnerability information from the likes of NIST so they always have the latest benchmarks. Once the security team is equipped with an up-to-date picture of where issues are in your infrastructure, deciding what work to prioritise becomes much easier.

Recognise your vulnerabilities and take action

Vulnerability management is one of the most critical cyber security processes the security team undertakes. It provides a synoptic picture of the entire business, reporting on security weaknesses, misconfigurations and the patch deficit.

Now that the security team is armed with the facts relating to risks and exposures, prioritising the work plan is easy and justification as to why you have done some patching over rolling out a new application will be factual rather than based on hypothesis.

[1] https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=Oracle