Patch Management Policy

Transcription

1 Patch Management Policy L2-POL-12 Version No :1.0

2 Revision History REVISION DATE PREPARED BY APPROVED BY DESCRIPTION Original Apr-2015 Process Owner Management Representative Initial Version No.: 1.0 Release Date: 02-Apr-2015 Accessibility: Internal Page 1 of 5

3 A current and complete inventory of assets is a prerequisite for effective technical vulnerability (patch) management. Specific information needed to support technical vulnerability (patch) management includes the software vendor, version number, current state of deployment and the person(s) responsible for the software. Appropriate and timely action should be taken in response to the identification of potential technical vulnerabilities. The following should be followed for an effective technical vulnerability (patch) management process: 1. Identify information resources to identify relevant technical vulnerabilities. 2. Establish a strategy to deploy update security patches as per the guidelines for security patches installation (refer patching guideline document). 3. Once a potential technical vulnerability has been identified, associated risks and the actions to be taken shall be identified which may involve a. Patching of vulnerable systems or b. Applying other controls. 4. Systems at high risk & critical patches having active exploits shall be installed on priority basis. 5. Patches shall be analyzed & evaluated for relevance and criticality to the operation prior to implementation, non-applicability of patch shall also be verified. 6. All patches shall be appropriately tested before deployment. 7. Latest, relevant and stable security patches shall be deployed in controlled environment which are released by the respective product vendors, from time-to-time: a. Operating Systems in Servers, Network devices, Laptops, Desktops (PCs); b. Software Applications; c. Network Devices (router, switches, firewall etc. and includes firmware). 8. Wherever technically feasible, patch management tools shall be used to assist in the uniform application of configurations, policies and patches at the enterprise level. 9. Non-critical patches shall be installed during scheduled maintenance. 10. If no patch is available, other controls should be considered, such as: a. turning off services or capabilities related to the vulnerability; b. adapting or adding access controls, e.g. firewalls, at network borders ; c. increased monitoring to detect actual attacks; d. raising awareness of the vulnerability. 11. An audit log shall be kept for all patch updates undertaken and retained for minimum one week and subsequently until system is performing in a stable manner post patch update. 1 Restriction on software installation 1. Rules governing software installation by users are established and implemented. 2. Internet Policy point # 9 clearly describes the prohibited sites. 3. Users shall not download freeware utility software under any circumstances on their own. Prior to such downloading, IT shall verify security risks and then download for the user for the period needed, and only after authorization of the business requirement of such freeware download by user's HOD. Version No.: 1.0 Release Date: 02-Apr-2015 Accessibility: Internal Page 2 of 5

4 a. Uncontrolled installation of software on computing devices may lead to introducing vulnerabilities and possible information leakage, loss of integrity or other security incidents, or violation of IPR. 2 Information systems audit controls 1. Verification of operational systems shall be planned in a manner that there is minimum disruption to business process. 2. As part of internal audit process, the planned arrangement is shared with auditee team and their HOD's in advance. This ensures audit requirements for access to systems and data are agreed in advance. 3. The scope of technical audit tests are agreed and controlled. Preferably these are carried out during non-production hours or during off-working days as then there will be no disruption to routine business operations. 4. Audit tests are limited to read-only access to software and data. Requirements for special or additional processing shall be identified and agreed. 3 Guidelines for Patch Installations The goal of patch management is to keep the information technology infrastructure (hardware& software) up to date with the latest stable patches and updates. Patch management is an important part of keeping information technology infrastructure available to the end user. Without regular vulnerability testing and patching, the information technology infrastructure may be prone to security issues. Poor patching can allow viruses and spyware to infect the network and allow security weaknesses to be exploited. These are fixed by regularly updating the software, firmware and drivers. Patch Management Coverage The following patches shall be implemented: Type Hardware - Server / PC Operating System Application Software Network Devices Patch BIOS, firmware, drivers Service packs, patches, Hotfixes Service packs, patches, Hotfixes Firmware, OS Upgrades Vulnerabilities shall be minimized within the IT Infrastructure and Application by keeping patches up to date. All users of IT systems shall allow patches to be deployed to their equipment. Methodology There is six-step method to Patch Management. These six steps, as a closed-loop solution, define an effective framework for patch deployment - whether bringing an un-patched environment up to a baseline level or deploying a patch as part of an emergency response plan. The six steps in the method are: Patching Step Step 1: Discover& Categorize Brief Description / Detailed Steps This phase involves locating assets (workstations, servers, laptops, network devices and applications) on network & categorizing them Version No.: 1.0 Release Date: 02-Apr-2015 Accessibility: Internal Page 3 of 5

5 Patching Step Brief Description / Detailed Steps The first step is to identify and categorize assets: taking a full inventory of all workstations, Network devices and servers on the network. After the assets are identified, they need to be categorized based on the criticality, exposure and risk. By categorizing assets, picture is developed of machines which require rapid patch management (within hours or days) and which require standard management (weeks or may be months). Main consideration for categorizing machines is based on the information that machine protects. Other issues to consider are public visibility (as in the case of a website) and sensitivity (Application server, Domain controller, Mail server, Database servers, etc.). Step 2: Analyze This phase involves analysis process, current patch levels must be determined and a minimum baseline level should be defined. This will be done by referring the vendor s description on each updates and other contributions by people from internet/blogs. Current patch levels are assessed. The Patch analysis is done manually, by comparing latest available patches in the system and released by OEM; by respective asset owner, service provider (category 2) with the help of OEM, if required. by various considerations. Typically, the operating patch updation needs to be analyzed on the basis of hardware as well as applications installed on it for patch compatibility. Step 3: Research and Test This phase involves missing service packs. The patches must be researched and understood. A risk analysis must be done for missing patches. All relevant patches/ hotfixes are tested on test servers for a observation period, before updating to production servers. Current patch levels will fall into one of the three categories: 1. Totally-patched, in which all systems are completely up-to-date; 2. Totally un-patched, in which none of the systems are up-to-date, systems have different service pack across the organization 3. Somewhere-in-the-middle. Minimum baseline levels of patches are set by respective vendors based on the requirement and need. With respect to other devices (such as windows servers, Linux servers, Applications, Network devices) the defined patch level is N-1 (the patch/hotfix just below the latest version). This minimum patch baseline may vary even there is a performance issue during analysis, research and test phases. Extensive research is conducted before process of deploying any service packs or patches to network to avoid unexpected negative impact on a machine, application or any other resource. Research is done by referring the manuals, experiences and aftereffects posted by other system/network administrators from the internet and other related publications released OEM (Microsoft, HP, IBM, Cisco, CA, SANS, CERT- IN etc). Step 4: Remediate To remedy the vulnerabilities found by bringing systems up to date. This is best accomplished via policy-based solution. Frequent VA and Penetration Testing by security professionals / agencies should be conducted and patches updated against High and Medium vulnerabilities. Remediation is the act or process of remedying; concerned with the correction of a faulty situation. Remediation in the context of software means to correct, update, patch, or rollback to bring a system in to compliance, therefore this phase involves patch deployment, installation, and un-installation (if necessary) in a controlled manner. This is governed through a change control process with close Version No.: 1.0 Release Date: 02-Apr-2015 Accessibility: Internal Page 4 of 5

6 Patching Step Brief Description / Detailed Steps supervision of critical systems. All the patch download and deployment is done on Test servers. Step 5: Fallback Plan The fall back (to original state), although not always a necessary step, describes the ability to roll back a patch should the need arise (in case of failure). Step five may become necessary in the event that an applied patch causes problems on the network. The system restores and backup of all resources is deployed when a patch requires rollback on server machines or network devices. Rollback is essentially the ability to uninstall a patch and restore the system to its prior state. In the event that a patch does cause problems, first step is to uninstall the patch itself before restoring or rolling back. Step 6: Report Reporting includes conducting a change review and verifysuccessful deployment of patches. Reporting should also include enough review, analysis, and adjustment to close the loop and begin the cycle again automatically. This is to confirm the successful deployment of patches and verify that there is no negative impact. Reporting exposes situations that require an immediate return to the analysis phase, such as a failure in deployment. Reporting also allows an opportunity to review 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 are required (often to meet industry or statutory regulations), documentation of changes is crucial to proving compliance. Reporting is done by mail and an excel sheet with all updated patches are prepared. Patching Plan All types of patches related to Desktops/Laptops, Servers and Network Devices are automatically downloaded in a central location. These are reviewed / analyzed by respective asset / process owner and those relevant are pushed to all devices. Version No.: 1.0 Release Date: 02-Apr-2015 Accessibility: Internal Page 5 of 5