Browse Prior Art Database

System and method to assess the risk of a software patch

IP.com Disclosure Number: IPCOM000248354D
Publication Date: 2016-Nov-17
Document File: 4 page(s) / 45K

Publishing Venue

The IP.com Prior Art Database

Abstract

When installing a software update or a patch on a device, organizations and users are always concerned about the negative impacts of the operation: an update can either fail to install leaving the software in an unusable state, or it can install successfully but negatively impact stability of the operating system or other applications.

The traditional approach to mitigate this risk is testing the update in a test environment before deploying it to a large set of devices. Software vendors perform testing in their environments, but are not able to test all the possible configurations existing on the field. Large customers usually repeat the testing, running on the configurations that they most likely have deployed in their environments.

To mitigate the risks, well organized large customers traditionally bought and maintained a very small number of configurations for their hardware and software so that they can keep track of them and exhaustively check all of them. But even for these customers the "bring your own device" model is changing the landscape and no longer allows to keep strict control on the number of available configurations.

So, exhaustive testing is no longer a viable approach.

This article describes a method to compute a risk factor of installing a software update or a patch on a specific device or family of devices without performing exhaustive testing, so that you can figure out in advance what is the risk of installing the update on a device, and you can take decisions:

- As the organization delivering the patch, you may decide to add a device with a high risk factor to the test bed; - As the manufacturer of the os device you may decide to not install automatically high risk patches while the user is working with the device; - As the end user installing the patch, you may decide to not install the patch at all.

These are just examples of how this magic number can be used to reduce the error rate of installing software on devices.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 01 of 4

System and method to assess the risk of a software patch

This disclosure describes a method to compute the risk of a software update or of a patch on a specific device or family of devices. The method analyzes the intrinsic risk of the patch plus the characteristics of the device to assess the deployment risk.

The method collects the following set of information:

1. The characteristics of the patch: it affects OS files, it requires a reboot, it contains a small or large number of files and so on;

2. The set of applications using the patched files on the target system;

3. The characteristics of the target machine: the hardware age, the version of the operating system and the version and age of the operating system drivers;

4. The set of tests performed by either the software vendor or the customer or both of them with the associated software and hardware configurations;

The method computes the intrinsic risk factor for the patch based on the data collected at the first step, then uses the data collected at step 3 and 4 to compute a fingerprint of the tested configurations and a fingerprint of the target machine or family of machines in order to assess the distance between them and thus a risk factor.

The advantage of this method is to allow a calculation for the risk of a patch in an environment where a rich set of configurations are present.

The first step of the method collects static information about a patch analyzing the package bundle of the patch (e.g. MSI, RPM or APK). It extracts information about:

1. The number of files involved and their location: the higher the number of files, the riskiest is the patch. If the files are located in the shared folder, this is an additional indication that the patch can have far reaching impacts;

2. The type of software patched: an application or the operating system itself or a system driver. Also the reboot needed flag is an indication of the impacts of the patch;

Based on these data, it is possible to compute the intrinsic risk of a patch as a function of the types of files patched, the type of software patched, the size of the patched software. The files in the patch can be characterized into different groups:


1. Operating system files: modules that are the core for the operating system


2. Drivers: additional modules required to drive the machine hardware


3. Common files: files used by multiple applications, like shared libraries


4. Application files: files used by the single patched application

The above list is basically ordered based on the risk of updating a file: the operating system is used by any application on the machine, drivers are possibly used by many applications but not all of them (even a graphic driver is used with different extent by different applications) and so on.

To assess the risk of a patch it is thus necessary to understand how many applications can be affected by the replacement of a file; the more applications require the file, the higher the risk or upgra...