Virtual Patching gives a rapid way of a solution to provide web security. Even though the preferred solution is temporary, it would fix the vulnerable web application. Once the code gets fixed, the virtual patch is being deployed on every ingress point which can access the code and the new code deployments are covered by the patch.
Many of the organizations are not always feasible to do traditional patching for multiple reasons:
-
Some organizations do not have enough resources to pull them for unplanned work.
-
There is a scenario where the organizations do not manage their systems. They have to wait for their service provider who manages development projects.
-
The vulnerabilities are found in third-party software. But the organization does not have either source code access or have permission to alter it.
By using a virtual patching system, an organization buys itself the time needed to free up resources, work with its vendors, and develop a sound risk response without leaving systems vulnerable during this process.
Some recommended best practices for Virtual Patching:
-
Determine every software you are using.
It would be easy for you to understand what needs to be patched once you can identify what you have (OS, server, or desktop applications). -
Need to patch servers, PCs, and mobile devices.
-
Required a methodology to patch any of the hardware-based appliances, like firewalls, routers, and so on.
-
Schedule a well-organized procedure to patch the systems every month.
There are many approaches you can consider for this. But it is your decision what is best for your business. -
Identify all the dependencies if you are dealing with multiple servers.
While rebooting the servers, dependencies matter at the time of restart to work everything fine. -
To know more about the implications of deploying a set of patches, read the release notes or Read-Me files. It would be good enough if a check for the software user forums to understand if anyone has any issues with the new patches.
-
Don’t rush to deploy the patches
It is better to apply patches after 30 days from their release unless there is an inevitable threat. Then there will be an opportunity to see what effect it is having elsewhere in similar software user communities. -
Need to test the patches on a test region, before they apply to the production environment.
Since this requires a lot of extra purchases such as hardware and software to build the test environment, this can be burdensome and high-priced for most companies. If you don’t have a budget to do this, some companies offer patching services. Testing those patches before deployment to production systems is one of the tasks they perform. -
While testing in the test region, identify whether the computers require a reboot or if they do so automatically.
90% of the patch deployments require reboots. Once determined, plan for a maintenance window accordingly to push the patches to the production environment. Else unexpected server reboots may affect the business operations or do damage to databases, etc. -
A smoke testing procedure can be done after patches are applied.
This is to ensure every application and service is back online and running correctly once the servers and PCs restart. -
Need to include other stakeholders in the organization before making the changes.
They can help you to have an idea about the system or organizational demands that can affect the patch deployment task. -
Inform the end-users about the planned time frame for patch deployment.
When patching workstations, remind the users DO NOT SHUT their PC DOWN; but to save every document, close all applications, and log out of their workstation. Also, notify them what to do if they encounter an issue after the patch deployment. -
Prepare a good roll-back plan.
If there is a significant problem with the deployment, the roll-back plan allows to immediately reverse the patches and go back to the pre-patched system. -
Need a good backup of each system and also, take an image snapshot of the servers before the patch deployment.
-
Ensure to put the auto-scheduled maintenance jobs on hold, else they can mess things up if it is left running.
-
Don’t use tools like Auto-Update, as you cannot control when patches are applied.
If auto-update happens:
*Wont be able to test the applications before patches are deployed
*No smoke testing procedure post-patching
*No patch deployment reporting that is required to show -
Review the patching report after deployment and look for patches that failed to deploy.
Investigate why they failed to deploy, develop your remediation plan, and then redeploy. -
Ensure to accommodate exceptional cases.
Some servers or applications can’t be upgraded or patched to maintain compatibility with a critical application that is in use. In such cases, need to confirm that there is another strategy for protecting that system from the vulnerability left exposed by the inability to patch the software.
