Scribd
Upload
501 views2 pages

Linux Patch Management Guide

This document outlines the Linux patching process. It describes collecting vendor and security patches on a weekly, monthly, quarterly, or annual basis depending on their severity. Patches are analyzed for impact and then reviewed before being deployed in a standard rollout plan to development, test, and production servers with burn-in periods of hours to days depending on patch severity. Quarterly reports of implemented patches are posted to sharepoint.

Uploaded by

Aruun Nagpal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
501 views2 pages

Linux Patch Management Guide

This document outlines the Linux patching process. It describes collecting vendor and security patches on a weekly, monthly, quarterly, or annual basis depending on their severity. Patches are analyzed for impact and then reviewed before being deployed in a standard rollout plan to development, test, and production servers with burn-in periods of hours to days depending on patch severity. Quarterly reports of implemented patches are posted to sharepoint.

Uploaded by

Aruun Nagpal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd

Linux SOP Version 0.

Patching

Purpose The purpose of this process is to identify the tasks and responsibilities involved
when applying the patches to the Linux machine
Scope This process is a Linux process used to govern the Patch Management for Linux
Machines
Records None
Created
Terminology Standard

Central Systems Linux Patch Management

1. Collect Vendor and Security source patch notifications on the following basis:

a. Emergency patches - weekly.


b. Critical patches - monthly.
c. Moderate patches - quarterly.
d. All other patches - annually.

2. Analyze patches for exposure in our environment.

3. Patches will be reviewed in the following areas:

a. Device Driver
b. Operating System
c. Applications under the implementation and use of Open Systems Group.

4. Deploy patches following a standard rollout plan unless accelerated by


management due to the patches impact or exposure.

a. Acquisition of patch from vendor using the most secure method available whenever possible.

b. Installation of patch on Development server.

i. Burn-in of patch as follows:


1. Emergency 2hrs.
2. Critical 1 day
3. Moderate 14 days

c. Installation of patch on Test/QA/PROD server.

ii.Burn-in of patch as follows:


1. Emergency 8hrs.
2. Critical 2 day
3. Moderate 14 days

TCS BT– Operations SOP


- LINUX SOP Version 0.1
c. Installation of patch on Production server.

i. Upon completion of QA burn-in.

5. Quarterly reporting on all patches implemented during the past 3 months will be posted on sharepoint.

TCS BT– Operations SOP

You might also like