Regular patching your IT assets - Increases cyber immunity

Patch management seems to be an endless and thankless bucket of jobs that only get done when there is nothing else to do (thus almost never “on time”) or when something is about to break in a big way (or just broken!). It just puts off most of the time, leaving vulnerabilities and functional gaps all over the place. The three biggest challenges for an IT professional are security, reliability and performance. Ideally, an organization’s application/software mostly excels at all three but in practice we all know that isn’t true. It is a crucial part and parcel for any corporate IT security strategy or program, but unfortunately for IT managers it becomes equally difficult to do.

NIST (NIST SP 800-45 Version 2) defines patch as “A repair job for a piece of programming; also known as a “fix”. A patch is the immediate solution to an identified problem that is provided to users; it can sometimes be downloaded from the software maker’s website. The patch is not necessarily the best solution for the problem, and the product developers often find a better solution to provide when they package the product for its next release. A patch is usually developed and distributed as a replacement for or an insertion in compiled code (that is, in a binary file or object module). In many operating systems, a special program is provided to manage and track the installation of patches.”

Many a times, Corporates link the vulnerability management program with Patch Management. But, is Patch Management related with Vulnerability Assessment program?

It is partially but not completely. An organization may have policy of undergoing vulnerability assessment of its IT asset once a year or half-yearly or quarterly, but patch management is an always ongoing program and does not necessarily trigger only after a vulnerability assessment program.

However, a vulnerability assessment may project the missing patches in an IT asset so a regular vulnerability assessment may give IT security professional a comfort that the patches has been applied for that IT asset as on day whose vulnerability assessment has been concluded. But as we all know that vulnerability assessment may not be conducted very frequently but patches are released more frequently so patching an IT asset regularly increases the cyber immunity of an organization.

There are various variants of patches:

1. Hotfix: A hotfix or Quick Fix Engineering update (QFE update) is a single, cumulative package that includes information (often in the form of one or more files) that is used to address a problem in a software product (i.e., a software bug). Typically, hotfixes are made to address a specific customer situation.

2. Point Release: A point release is a minor release of a software project, especially one intended to fix bugs or do small cleanups rather than add significant features. Often, there are too many bugs to be fixed in a single major or minor release, creating a need for a point release.

3. Security Patches: A security patch is a change applied to an asset to correct the weakness described by a vulnerability. This corrective action will prevent successful exploitation and remove or mitigate a threat’s capability to exploit a specific vulnerability in an asset. Security patches are the primary method of fixing security vulnerabilities in software. Currently Microsoft releases its security patches once a month, and other operating systems and software projects have security teams dedicated to releasing the most reliable software patches as soon after a vulnerability announcement as possible. Security patches are closely tied to responsible disclosure.

4. Service Packs: A service pack (SP) or a feature pack (FP) comprises a collection of updates, fixes, or enhancements to a software program delivered in the form of a single installable package. Companies often release a service pack when the number of individual patches to a given program reaches a certain (arbitrary) limit, or the software release has shown to be stabilized with a limited number of remaining issues based on users’ feedback and bug tracking.

Why IT professionals fail to patch an asset regularly?

a) Some patches may cause performance issues or “break stuff” and thus are often put off rather than dealing with the complications associated with updating.

b) Many organizations do not have proper asset management so if you don’t know an asset exists on your network you will never succeed to know the vulnerabilities that exist.

c) A system restart is most often required after patching the asset and getting the downtime for system restart from business is very tough for production systems for an IT team.

d) Many patches are released, so it becomes difficult for an IT professional to determine which patch is applicable for which asset manually unless an automated tool is available to do this activity.

e) Many systems are legacy systems so there is a fear in mind whether the system would work after the patches is applied and no one wants to own this risk including business.

f) Many small organizations may not have exact replica of production environment in test environment, so they cannot perform testing of patch and even test results may not bring comfort to IT team if test environment is not exact replica of production systems.

g) Often there is a misconception in the mind of IT team that they need to patch only those which is provided by IT security team as missing patch after Vulnerability Assessment of the asset.

Implementing a Good Patch Management Strategy

i. A good patch management strategy ensures that patches are applied in a timely manner and will not negatively affect operations.

ii. Design a patch management policy or program and it should include all assets. A comprehensive inventory of all software and hardware within your environment is a critical piece of any patch management process.

iii. Establish procedures for checking for the existence of available patches, assessing the applicability of the patches and testing the patches.

iv. Critical vulnerabilities that have published exploit code should be given the highest severity weighting and be addressed immediately – not waiting for a patching cycle.

v. Preference to be given to security patches and should be patched on priority.

vi. Do not treat patches with a set it and forget its mentality.

vii. Patch management should leverage system efficiencies but include decision making of skilled and experienced engineers in the patch approval, rollout and upgrade process.

viii. Rollback capabilities to remediate issues. Capabilities and experience to identify the root cause and execute a rollback is super important to keeping a business functional. Patch management is critical, but not at the cost of uptime to a business.

ix. Some patches may affect production systems, meaning that testing is vital before deployment. Testing should be performed in an isolated test environment, ideally a virtualized mirror of your production environment.

x. Try to leverage the use of automated patching solutions as it addresses major challenge of IT managers that which patch is applicable for which asset and to show the patch status.

xi. If at all, the patching is not possible because of any reasons, the IT team should explore leveraging the virtual patching concept offered by many security solution providers. Virtual patching is the implementation of a security policy meant to prevent an exploit from occurring as a result of a newly discovered vulnerability. However, regular patching needs to be explored while asset has been virtually patched.

xii. Patch Management strategy should include all types of IT assets, for example endpoints, networks, servers, database, etc. The strategy should also incorporate patching cycle and any deviation/exception of any asset from patching should be documented and approved by the Information Security or IT Strategy committee which includes member representation from across the vertical including business.

xiii. Deliver messages to end users prompting them, for example, to install a patch or reboot their machine, or informing them about an in-progress deployment.

xiv. Deploy patches on demand at any given point, such as in emergency situations where a vulnerability is suddenly being actively exploited.

xv. Track patch status via its central, dynamic dashboard, and generate reports that can be customized for different types of recipients.

xvi. Define patch management as KPI for IT team and should be measured periodically.

xvii. IT administrators should scan the complete enterprise network for patch update requirements for each type of OS, application, hardware, mobile device, etc.

The author is ICT Security, Risk & Compliance Manager at CNH Industrial

Air Jordan XXXI 31 Shoes