A.14.2.2 Resolver Corporate Patch Management Policy

1. Purpose

This policy defines the procedures to be adopted for technical vulnerability and patch management.

Speed, accuracy, and security in sending, receiving, and storing information have become key to success in business today. When information systems fail or become compromised due to a security breach, the loss in time, money, and reputation can be disastrous.

The main purpose of vulnerability and patch management is to keep the components that form part of information technology infrastructure (hardware, software, and services) up to date with the latest patches and updates.

Patch management is not an event, it’s a process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities.

Without regular vulnerability scanning and patching, the information technology infrastructure could fall foul of problems that are fixed by regularly updating the software, firmware, and drivers. Poor patching can allow viruses and spyware to infect the network and allow security weaknesses to be exploited

Users of this document are all Resolver’s employees

2. Reference documents

  • ISO/IEC 27001:2013 standard, control A.11.2.7
  • Information Security Policy

3. Scope

All of Resolver’s Information Technology assets.

This policy applies to all components of the information technology infrastructure deployed and managed by Resolver company:

  • Servers based on:
    • Windows OS
    • Mac\Linux OS
  • Databases
  • Storages
  • Load Balancers
  • Web Application server
  • Firewall, Wi-Fi routers/access points, and other virtual and physical appliances.
  • And all other software and hardware components of the deployed infrastructure

4. Policy

All machines shall be regularly scanned for compliance and vulnerabilities. All vendor updates shall be assessed for criticality and applied at least monthly. Critical updates should be applied as quickly as they can be scheduled.

Vulnerability Remediation / Patch installation Time frame requirement

Vulnerability Severity Rating Cloud Hosted systems Corporate externally exposed systems Corporate internal system
Critical 8 days 8 days 14 days
High 8 days 8 days 30 days
Medium 30 days 30 days 30 days
Low Risk assessment-based decision, but not later than 60 days Risk assessment-based decision, but not later than 60 days Risk assessment-based decision, but not later than 90 days
  • Operating Systems (OSes) with announced “End-of-life” (EOL) dates will not be used for new deployments.
  • Force migration of end-users with announced EOL OSes should be planned for at least one month before the last patch will be released, better 6 months before.

5. Risks / Challenges of Patch Management

Without effective vulnerability and patch management, there is a risk of the unavailability of
systems. This can be caused by viruses and malware exploiting systems or by out of date software and drivers making systems unstable.

5.1. Patch Scheduling

Timing, prioritization, and testing are intertwined issues for enterprise patch management. Ideally, an organization would deploy every new patch immediately to minimize the time that systems are vulnerable to the associated software flaws.

DevOps department should schedule maintenance time frame windows for the patching process, for all Resolver’s Hosted on Could platforms environments providing in Resolver’s SaaS Portfolio.

  • The current patching window is 3rd Wednesday of every month, 8 days after patch Tuesday.

Internal corporate IT department should schedule their own time frame.

The window should be as close as possible and synchronized with an official time frame of scheduled patch releases of products Resolver depending on, for example:

Microsoft security updates are released on the second Tuesday of each month.

5.2. Alternative Host Architectures

Enterprise patch management is relatively straightforward when all of the hosts are fully managed and running typical applications and operating systems on a regular platform. When alternative host architectures are employed, patch management can be considerably more challenging. Examples of these architectures include the following:

Unmanaged hosts. As mentioned in the previous clause, it can be much more difficult to control patching when hosts are not centrally managed (i.e., users manage their own hosts, appliances, IoT devices).

Non-standard IT components (e.g., appliances). On such hosts, it’s often not possible to patch individual applications independently. Rather, the organization must wait for the component vendor to release updated software. This wait time may be significantly longer than that used by the primary application vendors, resulting in significant vulnerability windows.

5.3. Software Inventory Management

Enterprise patch management is dependent on having a current and complete inventory of the patchable software (applications and operating systems) installed on each host. This inventory should include not only which software is currently installed on each host, but also what version of each piece of software is installed. Without this information, the correct patches cannot be identified, acquired, and installed. This inventory information is also necessary for identifying older versions of installed software so that they can be brought up to date. A major benefit of updating older versions is that it reduces the number of software versions that need to be patched and have their patches tested.

5.4. Resource Overload

Enterprise patch management can cause resources to become overloaded. For example, many hosts might start downloading the same large patch (or bundle of patches) at the same time. This could consume excessive network bandwidth or, if the patches are coming from an organization patch server, overwhelm the resources of that server. The resolver should ensure that their enterprise patch management can avoid resource overload situations, such as by sizing the solution to meet expected volumes of requests, and staggering the delivery of patches so that the enterprise patch management system does not try to transfer patches to too many hosts at the same time.

5.5. Installation Side Effects

Installing a patch may cause side effects to occur. A common example is an installation inadvertently altering existing security configuration settings or adding new settings. This may create a new security problem in the process of fixing the original vulnerability via patching. The resolver should be capable of detecting side effects, such as changes to security configuration settings, caused by patch installation.

It is strongly recommended to run the vulnerability scanning thoroughly after the systems were patched.

5.6. Patch Implementation Verification

As discussed in the previous clause, an installed patch might not take effect until the affected software is restarted or other state changes are made. It can be surprisingly difficult to examine a host and determine whether or not a particular patch has taken effect. This is further complicated when there is no indication for a patch when it would take effect (reboot required/not required, etc.) One option is to attempt to exploit the vulnerability, but this is generally only feasible if an exploit already exists, and there are substantial risks with attempting exploitation, even under highly controlled conditions. The resolver should use other methods of confirming installation, such as a vulnerability scanner that is independent of the patch management system.

6. Patch management procedure (phases/steps)

6.1. Discover

The first step in Patch Management is to define your starting point. The first step is to identify and categorize your assets: taking a full inventory of all workstations and servers on your network.

The inventory report should involve the list of assets with the OS versions and applications installed on it. Once your assets are identified, they need to be categorized based on exposure and risk.
By categorizing assets, you develop a picture of which machines require rapid patch management (within hours or days) and which require standard management (weeks.) Categorizing your assets is almost always a manual process. It’s difficult to automate a process that essentially identifies “important machines” and “less-important machines.” One consideration when categorizing machines is the information that the machine protects. Other issues to consider are public visibility (as in the case of a website) and sensitivity (customer credit card numbers, PII, PHI). The most important question to ask is “what will be the impact on the company if this machine is down or compromised?”

Risk Analysis should be an integral part of the Patch Management process.

After getting all the information, you should be proactively enrolled in all Security bulletin’s distribution list of all Application and OS vendors in your inventory list, In order to get the updates/patches release notifications in real-time.

6.2. Analyze

The next step is the analysis phase, in which current patch levels are assessed. It can be done by vulnerability or patch management systems (Nessus) is designed to scan the systems they discover for installed and missing patches. The accuracy of this step is critical. Worst-case scenarios are false-positives; reporting a patch as a present when in fact it is not. This may result in the patch never being applied. The less-critical counter to this is a false-negative; reporting a needed patch is not present when in fact it is. This will usually result in the re-application of the patch, with little harm done. This patch analysis is based on several different information points. Typically, the operating system needs to be determined for a given device, as well as which applications installed on the machine. Based on that information, most tools will consult a “master list” of patches that are available for a given OS and application and determine which of these patches are installed and which are not. This “Master List” is analogous to antivirus software virus definition files and should be downloaded regularly from vendor websites.

6.3. Patch testing

Let’s consider the results of the first two steps: You should now have a clear picture of your current patch levels. Patch Level Minimum Baselines an important concept is the minimum patch level you require on your network. This minimum patch baseline will be unique to each network and can only be determined by a thorough understanding of the analysis, research, and test phases.

6.4. Research

Before you begin the process of deploying any service packs or patches to your environment, it is STRONGLY recommended that you research what you are about to deploy. Occasionally, the application of a patch, or even service pack, can have an unexpected negative impact on a machine; therefore, it is necessary to understand what you are deploying to your environment. Review resources such as the MITRE, NIST websites, where vulnerabilities are reviewed and detailed. Vendors publish articles describing vulnerabilities and include release notes and/or read-me files describing installation options and precautions. Vendor testing should never replace your own, however. Every environment is different and third-party or custom software makes interactions unique and unpredictable. Based on the information you collect, you should determine the following for each patch you deploy:

  • What is the nature of the vulnerability?
  • What application or OS component is affected by it?
  • How easy is it to exploit the vulnerability?
  • What is the severity of the vulnerability?
  • If the vulnerability is exploited, how much damage could be caused?
  • Vulnerabilities are typically rated as low, medium, high or critical, critical being the highest level of potential damage should the vulnerability go un-patched.
  • What is your level of exposure to vulnerability?

Use the above information to guide your deployment of patches. Conduct a risk analysis. For example, if you find a high occurrence of missing patches for severe vulnerabilities, you may wish to address those systems first. Is this a severe vulnerability on your mission-critical application servers, or is it a low-severity across internal workstations? Based on that determination, you can begin to address the issues of testing the new patches for deployment.
A Few Precautions.

It should also be noted that, in the case of major system upgrades (and some small ones, too), reasonable precautions should be taken before making any change. This includes reading release notes and any deployment guide. There may be a recommendation to back up critical data or the entire system before deployment, so read carefully.

6.5. Test

The reason for testing patches prior to deployment may be obvious, but should be stated clearly:

patches sometimes break operating systems or applications. It’s a fact of patch management. Even in the case of a fully tested service pack, there is always a chance that it will conflict with some as-yet-undiscovered quirk in a small number of environments and, when that conflict occurs, servers come down. Therefore, the importance of testing in your own environment, on your own machines, can’t be stressed enough.

The testing phase of deployment includes applying patches to a test environment prior to deploying them to a production system. The nature of a patch is that it has been written quickly to address a critical issue. Therefore, there is not always time to thoroughly test a patch prior to release. This is not to imply that patches are untested; but the testing isn’t nearly as extensive as in the case of a service pack, which goes through beta testing and review prior to release. Of course, service packs should not be immune to the testing phase. Although they are tested thoroughly by their vendors, no vendor can test every update in every possible environment, so no patch or service pack should ever be deployed without being tested in your own test environment first.

  • So how do you test a patch?

Deploy it to a test/staging machine configured the same as the production system(s) that need the patch. It is strongly recommended that you develop a test environment and use that environment to test patch deployment before deploying to production.

Whatever your test environment is, deploy patches, run acceptance tests on that environment. Then observe and record the results:

  • Is the system still functioning?
  • Are the applications and services on it still functioning?
  • Do the results of the install coincide with the expected results:
    • application extensions are updated; registry keys are changed?
    • If no negative impact is determined, the patch can be deemed safe.
    • If a problem occurs, go back to the research phase.

7. Deploy

  • Create a backup/snapshot and verify its integrity by deploying it on a standby system.
  • If the system is critical and deployed in High-availability configuration with component redundancy behind a Load Balancer (LB), prepare the LB, remove the system from the production destination pool of LB.
    • Patch the system. Validate the base functionality of the application.
    • Swap the patched standby system into production and keep the previous unpatched production system as a standby for emergency patch regression.
    • Closely monitor the patched production system for any issues not identified during testing.
    • Patch the standby system (old production) after confidence is established with the production unit.
    • Update configuration management tasks and related records (Jira ticket).

8. Report

Reporting is the final step in the Patch Management process. You must be able to confirm the successful deployment of patches and verify that there is no negative impact. Reporting should expose situations that require an immediate return to the analysis phase, such as a failure in deployment. Reporting also allows an opportunity to review the patch management process and look for areas of improvement, as well as providing valuable statistical information regarding patching activity. In environments where internal or external audits (often to meet industry or federal regulations) are required, documentation of changes is crucial to proving compliance.

Reporting conducts a change review and verifies the successful deployment of patches. Reporting should also include enough review, analysis, and adjustment to close the loop and begin the cycle again automatically.

9. Non-Conformance

All policies require the participation of staff and contractors to be successful. Any employee or contractor found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

10. Validity and document management

This document is valid as of July 2020.

The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.

When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:

  • The number of incidents arising from the unclear definition of the ISMS scope.
  • The number of corrective actions taken due to an inadequately defined ISMS scope.
  • The time put in by employees implementing the ISMS to resolve dilemmas concerning the unclear scope.

EFFECTIVE ON: September 2020

REVIEW CYCLE: Annual at least and as needed

REVIEW, APPROVAL & CHANGE HISTORY: Last time reviewed and approved in August 2020 by Resolver’s Information Technology Security team.