Mitigating controls for ineffective patching

By Louay Ghashash

PATCH MANAGEMENT PROCESS

It is well known and understood in the industry that patch management is a fundamental corner stone of any security program. It has become well known and understood that without effective patch management, businesses will open their systems to myriad of attacks and data breaches.

Majority of today’s attack and data breaches could have been avoided with patch management. Despite that, and while business understand the benefit; running smooth patch management is easier said than done; we often see issues and problems complicating that process and hindering its smooth operation.

BEST PRACTICES OF PATCH MANAGEMENT

Many security standards and best practices mandate or recommend that critical patches should be installed within less than 2-4 weeks from vendor release, high severity patches should be installed within less than 4 weeks and medium patches to be installed as soon as possible. Running an effective patch management requires that all the following areas and systems must be included in the process: - Firmware and BIOS - Hypervisors - Operating Systems - Application - Libraries and applets - 3rd party systems - IoT devices

Focusing Patching efforts on Operating Systems only is not considered a good patch management practice.

PROBLEMS STOPPING EFFECTIVE PATCHING

Patch Management process is often over simplified, however if we look under the hood, we found many intricacies and complexities hidden within that process.

Legacy systems

Legacy systems have to be a biggest roadblock in the road of patch management. Nowadays, there are many legacy systems, including Windows 2008, applications built on Java Run time environment that are >15 years old, Windows XP and even Windows NT4 still running around. Chances are that these legacy systems will stick around for many more years to come.

Systems Testing

Running an effective patch management goes well beyond getting latest Microsoft patches and apply them, therefore Business requires testing to be completed before approving patches. An effective testing has to be a massive task delaying businesses from rolling patches in time. Systems need to undergo thorough testing before the patches can be installed. Time and efforts required for testing are not small, vendors nowadays are releasing new patches and updates faster than ever, putting a lot of constrains on business’s resources and teams.

Non-Production Systems

The lack of available non-production systems made testing patches before rolling them out another challenge added to this problem. Systems complexity means that full thorough testing plan must be put in place and in some instances, full regression testing may be needed before approving any

patches to production

Patches Frequency

The number of disclosed critical and high patches and updates have significantly increased in the past decades. We are regularly seen on monthly basis vendors like Microsoft releasing critical and high severity patches. Just check how many critical system patches vendors like Microsoft or Apple have released in the past 6 months. While it is great that we know there is a solution out there, this however, doesn’t make the job of IT department any easier.

Backward Compatibility

Some of the patches have known backward compatibility issues, e.g., some Java libraries updates cause many issues and problems to systems relying on them. jQuery, a popular library used in modern web application is a nightmare to update; some of the major versions of jQuery are not backward compatible; developers may have in some instances to rewrite large amount of code to cater for the new version changes.

Business Resistance

Many businesses have unrealistic high expectations on system availability and as a result, they demand that all outages kept to minimum. This put a lot of pressure and constrains on IT departments to bring down systems during patch cycle.

Cost

All the previous factors contributed to making combined cost of resources, systems, afterhours rates and 3rd party major hurdles that complicate this problem even further. Many IT departments haven’t factored these costs in their security program.

MITIGATING CONTROLS

These controls should be considered as a last resort under your arsenal. In fact, all of these controls should already exist and operational in IT departments.

Network Segmentation

You have a vulnerable system you can’t patch? Segment it. One of the effective mitigating controls is segmenting the system(s) from the rest of your network. This includes: - Blocking all inbound and outbound access to these systems. This will significantly reduce any exposure of these systems to the attacks from the internet. - Isolating these systems in their own subnet and heavily restricting inbound/outbound traffic from the rest of the network will also need to be considered. - Removing these systems from your Domain/Active

Directory will reduce any chance of attackers abusing domain trust relationship The above controls should be part of your Zero trust strategy anyway.

Endpoint Detection and Response

If you still running traditional Antivirus, invest in Endpoint Detection and Response (EDR). Keep in mind that not all EDRs are created equal; some of EDR vendors do a fantastic job of blocking attacks on vulnerable unpatched system, others, not that much. Having EDR doesn’t give any green light for not patching, but it should give business some ease of mind.

Systems Hardening

Hardening unpatched and vulnerable systems as much as possible is also a good practice you should consider. This includes reviewing any default accounts, systems, uninstall and remove application and services, and stopping any unnecessary services on these systems. CIS and Microsoft amongst others publish regularly good hardening standards for various systems.

Security Event Monitoring Solutions

If you can’t fix the problem, monitor it. At least you can detect when something wrong is happening. All systems must be regularly monitored and assessed for any indicators of attacks and compromises. You should to invest additional time and efforts to ensure that events on unpatched and legacy systems are monitored and alerts are actioned promptly. Validate with your Security Event vendor and add some additional monitoring, if possible, for these systems.

IT Risk Management Process

When patching is not working well, legacy systems exist these are all risks that IT must ensure that businesses are aware of. The vehicle of that awareness is an effective Information Security Risk Management Process that is aligned with the corporate risk framework. Without it, business maybe under the illusion that technology risks are managed by IT; IT don’t have the required budget and resources to manage it, and it becomes a disaster waiting to happen.

Conclusion

While running an effective and a well-oiled patch management process is complex and require a lot of energy and resources from IT; the above recommendations and controls could help reducing the impact or likelihood of not running patches. Nonetheless these should not be used or considered as excuse for not patching.

Finally, IT should plan and consider existing some of its legacy systems as soon as possible or leverage some of the serverless cloud-based technology that alleviate the need of patching.

About the Author Louay is a founder and Director of SpartansSec with over 22 years’ experience in Information security across number of industries and verticals. He has also acted as Chief Information Security Officer (CISO) across number of customer engagements including Non-for-Profit Retails and FSI.

Louay holds a Bachelor Degree in Electrical Engineering and a Master Degree in Networking Systems Engineering. He also holds the following industry certifications: CISA, CISM, CRISC, QSA and ISO27001LA