This page has not yet been translated to English.

Page tree
Skip to end of metadata
Go to start of metadata

15 - PatchManager

PatchManager is available as an optional module.

Patches often repair security vulnerabilities through which attackers may gain access to systems running the affected software. In responding to security emergencies, rapid deployment of patches is important. A complicating factor, the release of a patch actually stimulates hackers to develop an exploit for the security bug, due to the public release of information about the vulnerability that typically accompanies patch releases. By reverse-engineering patch files, attackers can obtain the information necessary to stage an effective attack. This puts extra pressure on administrators to timely patch their systems. Patch management helps speed up patch deployment and improves the efficiency of the complete process by coordinating and standardizing patch deployment procedures, preventing successful exploitation of software bugs by hackers.

The patch management cycle can be broken down into different stages (see chapters 15.1 through 15.7). Depending on wishes and requirements, companies can merge stages by bundling them and assigning them to the same person, or define further action points as required. Existing change and release management standards can be (partially) integrated. Some steps of the procedure can be automated, most notably the deployment, but several key actions will have to be carried out manually for each cycle. To optimize this process, planning is crucial. It can be very helpful to define a patch management policy that deals with common questions. Should all available patches be installed by default, or will there be a classification, possibly based on the severity of the vulnerabilities they remedy? Will patches be installed proactively (to plug possible security holes) or reactively (only when problems arise), or a combination of both? To prevent spending unnecessary time on patch-by-patch decisions, it is recommended to set as many generalized rules as possible. At the same time, simply installing every available patch is not a solution: to prevent network and system load and compatibility problems, conscious choices need to be made. 

Because patch management is a time-consuming task, complete automation can be a tempting proposition. PatchManager can function near-autonomously: automated rollouts of critical patches can be configured through PatchManager’s SETTINGS tab. Even though this method makes sure that clients are timely supplied with the latest critical patches, configuring PatchManager this way is not advised. A patch might well be applicable to a specific client, but that does not mean it can be installed without problems. Compatibility problems may arise after its installation, inhibiting system or software availability. A proper testing procedure should always be part of patch management; cutting corners on any part of the cycle is not recommended.

The PATCHMANAGER module supports the use of SQL Server Express, but for medium to large networks, the use of a dedicated SQL Server is recommended.

15.1 - Step 1: Inventory update

Firstly, it is important to take and keep an inventory of machines in the network and their software and hardware. The CLIENTS module lets administrators access a full list of installed software for each network client. The inventory can be organized to provide different types of information. The default view shows a flat list of all software that is installed on the selected clients. The listing includes the installation date, the software vendor and the currently installed version. By grouping the items according to vendor and name, for each product a quick overview is available to check if the latest version has been installed on all machines.

At this point, it is recommended to check if network clients are running any software that is not part of the standard deployment. Administrators cannot be aware of potential security risks for all software in existence. Using the Software inventory helps spot unsanctioned software installations. Administrators can decide to either add the software to their official deployment list (Whitelist), or to remove them (Blacklist). Users of G DATA Endpoint Protection Business can use the PolicyManager module (see chapter 14) to apply network-wide policies, whitelisting or blacklisting software to control deployment.

Not only is it important to keep track of software; successful deployment also depends on physical prerequisites like hardware specifications. Using the Hardware inventory function, a wide range of specifications can be tracked. Physical specs, like CPU speed and the amount of internal memory, help predict patch deployment speed and performance. The amount of free disk space is important in order to prevent patch deployment from generating errors. Additionally, bios and motherboard firmware versions can be tracked, to compare against newly published firmware.

15.2 - Step 2: Information gathering

As soon as an inventory has been established, administrators should keep up with information about the latest patches. The PatchManager module provides a list of all available patches for a wide range of products on the PATCH CONFIGURATION tab. The database is updated automatically as soon as vendors publish a new patch. An overview of vendors, products and patches can be gathered from a set of charts at the top of the tab.

By default, the list of patches is grouped by VENDOR, PRIORITY, and PRODUCT. This allows administrators to quickly look up patches for a specific product. The default display filter settings exclude full software installers from the list, as well as any blocked entries. Click RESET ALL FILTERS to reset the display filter. If a patch has superseded another patch, its entry can be expanded to display a list of patches it supersedes. More information about individual patches, often including full release notes, can be obtained by rightclicking on a patch and checking its properties.

15.3 - Step 3: Strategy and planning

Whenever a new patch is released, it should be checked against all client systems to see if it applies to a product that is in use in the network. For critical patches, this process can be automated on the SETTINGS tab. To manually check one or more patches for applicability, select it on the STATUS OVERVIEW tab and click CHECK PATCHES FOR APPLICABILITY. This schedules a PATCH APPLICABILITY JOB for the specified client(s). Alternatively, an automatic scan can be carried out for each new patch that is added to the database, including critical as well as less critical ones. Using the TASKS module, plan a PATCH APPLICABILITY JOB that is executed as soon as a new patch is available. PatchManager then checks the new patches for applicability across all specified clients. Even though patch applicability jobs can automatically install patches if they are found to be applicable, it is recommended to plan patch tests beforehand (see chapter 15.4).

After scanning for applicability, select the appropriate server or client(s) in the CLIENTS view and open the STATUS OVERVIEW tab of PatchManager. By default, the list is grouped by STATUS, PRIORITY, VENDOR and PRODUCT. This helps to quickly locate patches that are applicable, not applicable or have already been installed. Patches that are applicable for the client system(s) are the ones that need to be reviewed, tested and finally deployed.

To help decide whether to deploy a certain patch or not, PatchManager provides a set of information for each patch. In its list overview, the PatchManager module shows the products that a patch applies to, as well as its release date, its official title, and its priority. For each patch, a full description and usually a URL to the official release notes are provided. These pieces of information help administrators decide how severe a certain vulnerability is, and how quickly its patch needs to be deployed. The most significant patches should be installed with a higher priority than non-critical patches. The important point to remember is that not all patches should be installed by default. The point of patch management automation is not to take decision making out of the equation, but to provide enough details to make informed decisions, and to streamline the deployment process. PatchManager provides as much information as it can, but the decision to test and finally deploy a patch, is always up to the administrator.

15.4 - Step 4: Testing

Once it has been decided that a specific patch will be deployed, the testing procedure can start. It is recommended to use a set of representative machines to test patches. These machines should be similar to the clients that are actually in use, in order to test for possible problems without disrupting the actual clients. However, not every administrator will have access to enough machines to build a small-sized replica of their network. Virtualization is the recommended method; if there is really no other solution, a non-vital subset of the network can be used. In this case, using G DATA Administrator, a test environment can be organized in one or more groups. Patches can be deployed to one or more clients in one or more groups, to observe the installation and its effects.

To deploy one or more patches to a test group, select the group in the CLIENTS view. Open the TASKS module and create a new SOFTWARE DISTRIBUTION JOB. Select the patch(es) to be distributed and specify at which time this should occur. Selecting the patch can be made easier by grouping the patch list by VENDOR or PRODUCT. Repeat this process with all appropriate patches and for all appropriate test groups. It is recommended to test only one patch per system at the same time, to be able to pinpoint possible problems on a specific patch.

During the testing period, as well as the verification phase after deployment, the REPORTMANAGER module can assist in finding out what the status is of patches being deployed, and which machines are potentially generating errors (see chapter 6.3). ReportManager lets the administrator select several modules to be combined into one report. Its PATCHMANAGER category provides several useful options, such as the patches most frequently not installed or computers with unexecuted software distribution jobs (which may point to installation problems), or computers with the most frequent patch requests or refusals (for analysis afterwards).

In addition to the ReportManager module, patch testing status can also be located in the TASKS module itself. Open the relevant task and check the details to see the status for each patch. If it appears that a patch has not been deployed successfully, update the Software inventory for that client to double-check. If the patch cannot be deployed, check the system locally and try a manual patch deployment. If a patch is causing problems during the testing phase, it should not be deployed on a large scale until the problems have been resolved.

Patch testing could theoretically be skipped: PatchManager can automatically install critical patches if the respective option is enabled on the SETTINGS tab. This is not recommended: patches should always be tested for compatibility and only be rolled out if it has been ensured that they will not cause problems.

15.5 - Step 5: Schedule and assessment

After finishing the testing stage, the actual deployment can be planned. With all applicable patches located and tested, a schedule can be set up. Using your patch management policy, decide in which order the patches should be deployed and to which (groups of) machines at first. Use the MESSAGES function of the CLIENTS module to notify clients of the patch schedule and to warn them about eventual reboots.

15.6 - Step 6: Patch deployment

For patches that have been properly tested, a SOFTWARE DISTRIBUTION JOB can be planned. Use the TASKS module to schedule a SOFTWARE DISTRIBUTION JOB with the appropriate patches for the appropriate clients. To prevent interference with end user workflows, patches can be scheduled to be deployed at a specific time, or directly after the next boot or login. An optional delay prevents patches from being deployed while other system-intensive processes may be running. 

15.7 - Step 7: Verification and reporting

To verify and evaluate patch deployment, the inventory tools can be of great assistance. Additionally, the PatchManager module offers the possibility for direct user feedback. Patches that are applicable to the system, but have not been deployed yet or will not be deployed at all, can be requested by end users in case there is an urgent need to patch a product. If the administrator enables the respective option, end users can request patches to be rolled back, due to performance or compatibility issues. Administrators can manually initiate rollbacks at any time, allowing for quick solutions if a specific patch is causing issues. The distribution and rollback request system integrates directly with the PatchManager module and allows the administrator to plan a distribution or rollback job directly from the SECURITY EVENTS module.

  • No labels