Methodology To Implementing Patch Management
We are constantly seeing that the time period between a vulnerability is discovered in application or OS and appearance of an exploit is getting shorter, in some instances it has taken only a few hours before a vulnerability is exploited. IT managers are being put under pressure to promptly patch their production systems which conflicts with best practices of quality assurance testing. It is leaving a number of companies struggling to keep up-to-date with regular releases of new patches and updates both for OS and third party applications. This brings the need for the organisations to develop a procedure to ensure the availability of resources, install critical security patches and to crash the systems which are in process.
Before implementing a procedure we would need to understand the risk of patching and not patching. Although, it is important to protect your organisations from threats, patching the known vulnerability is only a portion of the risk equation. It is also important to develop a risk management strategy, this will go hand in hand with creating a patch management plan. The risk assessment should be performed on all the servers in your network. The assessment should consider the criticality of your data on these servers, what is the impact of the server’s downtime on your organisations operations and vulnerability of your servers to internal or external attacks. The risk management plan you develop will affect your patch management process and how you choose to apply patches and fixes. Your organisation should develop a procedure to evaluate and criticality of the software patch instead of blindly deploying every patch and hotfix. Your risk assessment plan should comprise the risks of not patching the reported vulnerability, extended downtime, decreased functionality and data loss.
There are several phases to a good patch management plan. These phases could vary based on the organisations size and structure however the fundamental procedure remains the same.
In phase one, you should collect the asset inventory data on your servers, switches, routers, desktops, laptops. The data collected should include the hostnames, locations, IP address, MAC addresses, operating system and current revision level, for your servers you would additionally collect functions and services running.
If you have documentation available on what services should be installed when installing a new operating system it is recommended to follow this. If no documentation is available, then consider performing vulnerability scans against your servers to discover unnecessary services that should be removed. You need to be cautious when disabling services as turning off services can make applying patches updates more difficult, i.e. deploying patches would require the machine to be running server service, file and print sharing enabled, remote registry access. You can use tools such SCA Security configuration and analysis to compare the host configuration against prearranged template. SCA will counter security holes but you should understand the consequences of making changes to a system, implement these changes on your test systems first. Other tool such as Nessus could be used to scan for security vulnerabilities.
Rating should be given to each of your servers to indicate its criticality to your organisations mission, higher rating = more critical the system. Dynamics to consider when rating these servers are: its role in the organisation, impact of its down time on the organisation, time and effort required in disaster recovery. This rating would become extremely important when making a decision on how and when to patch the system.
Dividing servers based upon criticality:
MISSION CRITICAL- This is where even one hour of downtime could have significant impact, such unavailability of ecommerce site which can have effect on loss in revenue and customers confidence.
BUSINESS CRITICAL- This is where business services requires continuous availability at any cost but short break in service will not be disastrous. These could be your email-servers.
BUSINESS OPERATIONAL- This is where breaks in service will not be catastrophic such as file servers, print servers etc.
Patch managers should ensure that there is available documentation around what traffic is being allowed through the internal network. This will help evaluate threats posed by known vulnerabilities and assign risk factor.
This phase involves developing a test environment.
Once the organisation has baselined your environment you should build the test environment which to some extent mirrors your production environment. This could include test servers representing all mission critical applications. For smaller IT organisations, the patches should be applied to least critical servers and are easily recoverable. These can be servers without a lot of data or application which need to be restored such as print servers. A personnel could be designated to verify the stability of your servers after the patching has been completed.
Lab in Box approach could be used by using VMWare. This is good and cost effective way to test compatibility of patches with the OS and applications running in your production servers/environments. This would allow you to evaluate multiple configurations of OS, applications and their interactions with each other before and after the patch installations.
This phase involves full backup of all data and server configuration before patching must be made. You should periodic test the restore process to check the integrity of backed up data. At the time of updating your workstations, you can establish a group of test users who should first receive the new updates. After successfully deploying to your test group, you should slowly expand the updates to the rest of your organisation. The users should be encouraged to store their critical data on the network share to ease restoration process.
Evaluate which updates are critical and which ones are unnecessary. Patch management tools make this easier by maintaining the database for the patch status of monitored systems and scanning them on demand.
The next phases include receiving information on the latest software updates and vulnerabilities. Auditing the organisation for applicable software updates, assessing and authorising available software updates, deploying authorised software updates within your organisation in a timely and accurate manner then tracking update deployment across your organisation. Tools like Ivanti Patch for Windows Servers can cover all the steps outlined above.
Upon completion of the patch testing and ready to be deployed on production environment the results of the testing should be documented and approved. The system owner must be prepared in case the disaster recovery steps are required. Your helpdesk should be made aware of the scheduled updates and remediation instructions if users are affected. If any dissimilar events occur during the deployment, the details of action occurred and the system it occurred on should be documented.
After your patch have passed in internal testing and configuration management review (phase five) you are ready to deploy the patches. Ivanti Patch for Windows Servers can be used to monitor the patch status, gather patches from vendors and distribute them in your environment. This tool has the ability to schedule your patch distribution and will not require user’s intervention which means your patch deployments can be run at off peak hours. However, patching of mission and critical servers should be performed manually during the off hours in case the disaster recovery plan needs to be implemented. In scenarios where patch is not an emergency fix, these patches can be applied during your maintenance window. You should ensure that your maintenance windows allows for recovery process when required. Ivanti Patch for Windows Servers can also help your organisation with patching business operational servers as well as workstations including agents.
This phase highlights procedures and policies to follow.
- You should designate a patch management lead and ensure they have support from the management to be able to get the job done.
- Your organisation must establish policies for patch updates. The non-critical updates on the non-critical systems can be applied in a maintenance window. Emergency updates to be applied after the stability of these patches have been ensured. The emergency patches should only be applied if they fix the problem that your servers are currently experiencing. The patches which are critical should be applied during off hours after ensuring patch stability.
- This step requires to check the existence, applicability of patches available and testing the patches. Ivanti Patch for windows servers can help you overcome points highlighted on this step. You must also ensure that your testing team contains members who are aware of the applications used in your environment.
- The fourth step includes updating your workstations images with new updates.
- The last step is to deliver regular reports of your patch status to the management. Ivanti also offers variety of reporting features which can be utilised.
Find out more about Ivanti Patch for Windows Servers here