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 of 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 mitigate 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 face problems 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
All of Resolver’s Information Technology assets.
This policy applies to all components of the information technology infrastructure deployed and managed by Resolver company:
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. |
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.
Timing, prioritization, and testing are intertwined issues for enterprise patch management. Ideally, an organization would deploy every new patch immediately to minimize the time 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 provided in Resolver’s SaaS Portfolio.
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.
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, controlling patching can be much more difficult 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.
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.
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. 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.
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. Resolver should be capable of detecting side effects, such as changes to security configuration settings, caused by patch installation.
Running the vulnerability scanning thoroughly after the systems are patched is strongly recommended.
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. Resolver should use other methods of confirming installation, such as a vulnerability scanner that is independent of the patch management system.
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.
Inventory report should involve the list of assets with OS version and application 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 the Security bulletin distribution list of all Application and OS vendors in your inventory list, In order to get the updates/patches release notifications in real-time.
The next step is the analysis phase, assessing current patch levels. It can be done by vulnerability or patch management systems (Nessus) are 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 and which applications are installed on the machine. Based on that information, most tools will consult a “master list” of patches available for a given OS and application and determine which 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.
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.
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 a 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, including 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:
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), 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.
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.
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:
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.
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.
This document is valid as of August 2023.
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:
EFFECTIVE ON: August 2023
REVIEW CYCLE: Annual at least and as needed