Management of Patches in Control Systems

The updates of control systems, whether they are for security or functionality reasons, should be guided by a management of patches process which adequately identifies the life-cycle and periodicity. A good management of patches in control systems has to face up to the culture of this environment, which opposes changes to a system which works; and to the manufacturing culture, which is not very inclined to publish patches in order to solve security problems. Fortunately, both limitations are almost things of the past.

Phases of the Management of Patches and Updates

As a recurring process, it is possible to define the monitoring or life-cycle for the management of patches and updates. There are 6 phases of this process which can be identified:

-Phases in the management of patches-

• Identifying of assets and core software: The identifying of assets and their core software installed, as well as the level of patches, is a complex task but it it improves security and operations. Having these foundations will allow for changes in the system to be carried out without risks and it will allow for a previous known and functional state to be returned to, should a problem occur whilst installing an update.
• Availability: In accordance with the assets and software identified, the list of current patches must be checked and those which affect each asset in the process must be identified.
• Applicability: The published patches are not always valid for all devices; therefore there must a verification to determine if that specific update is suitable for the assets of our process.
• Acquisition: It is not always easy to obtain the update files from a reliable source, or to check the veracity of the patch. The use of hashes is not usual for patches regarding control systems.
• Validation: The aim of validation is to ensure that the update does not have an adverse effect on the process. To carry this out, mock assets must be used and the deployment phase should be followed. It is hoped that with the validation, the implications of the update are checked; this may include changes in the firewall policies, configuration modifications, etc.
• Deployment: During the validation process, a deployment packet should be made. The packet should contain the update file(s) and the installation instructions, as well as a list of the assets in which the deployment should take place.

Problems and Solutions

The management of patches presents various difficulties when being applied to control systems; difficulties which do not tend to be present, or are at least to a lesser extent in IT systems.

The most important difficulty is that of having an inventory of assets which collects the software deployed in each device, this includes the versions of each application as well as its configuration. It is very common for different versions of the same problem to be deployed in a control system, and each of them should be patched according to their specific needs. For this reason, it is necessary to have a Master Assets List (MAL) which collects the core software of each asset.

The correct identification of the patches to be installed is not always simple as the proactive support, such as that provided by Siemens or ABB with their warning and life-cycle management services, on behalf of the manufactures does not tend to be a common characteristic in control systems. Each manufacturer has its own system of notifying clients, including the policy of not notifying them, making clients visit the web pages of distributors or other sources; therefore the search for patches and updates can become a tedious task. Furthermore, determining if it is a security patch or not is also not very easy in many cases, therefore it will be necessary to carefully read the published documentation or to even talk directly to the manufacturer.

The use of automated tools within control systems for the management of patches is complicated, as the tools for the management of assets have already demonstrated when an environment includes equipment or devices which are not very extended and that do not admit standard consultancy methods. The automated tools for the deployment of patches and updates may not be recognised by industrial devices, resulting in their use being pointless or barely beneficial within OT environments.

Another aspect to bear in mind tends to be the determination to update or carry out other corrective actions to mitigate the problem without having to deploy a patch. The best solution is always to apply the patch, but some devices may have certain factors or characteristics which cause delays in its installation. For that reason, having a mitigation plan which raises the security to a level which is accepted by the company may be a temporal solution to the patch application.

Challenges

The challenges that the management of patches face are numerous and encompass various fields.

In terms of processing, hurdles must be overcome such as the limits imposed by the service contract, the change of paradigm in the evaluation of vulnerabilities based on classic IT methods, the confidentiality of patches (they are not always available to the general public, or they are delivered according to the client's priority) and the discovering of new vulnerabilities.

At a technical level, the challenges will be the obtaining and transferring of patches, the time taken for deployment and the old and obsolete systems.

In terms of the legal sector, the largest challenges are those to do with international business (as the majority of manufacturers sell worldwide), the use of Open Source Software (OSS), the manufacturer's guarantee, the way in which assets are managed (internally, by a contracted third party, by the manufacturers themselves, etc.) and the ability to obtain and create patches (industrial manufacturers may have difficulties when creating security patches or ones which include new vulnerabilities). 

Best Practice

The good practice regarding the management of patches can be grouped in five large sections.

Compensatory Controls

The patches cannot be available whenever they are wanted, and so a culture which avoids problems must be created. The first thing to evaluate is what tends to fail in control systems, the vulnerabilities they are affected by and their consequences. From there, measures such as the correct hardening of devices, the control of traffic and the access to the control systems via firewalls, segmenting the network according to the criticality of the devices, carrying out audits and security evaluations and using blank lists will mean that a determined fault will not be a problem for the company, even though it will take some time for the patch to solve it.

Often, manufactures provide alternative solutions (workarounds) associated to the weaknesses or vulnerabilities of problem which are temporarily corrected until the patch is developed or can be applied.

Establishing a Management of Patches Programme

Implementing an adequate management of patches programme in control systems will allow for the controlling of updates which affect the company's assets. The management of patches should contain a policy which is orientated towards making its application easier and reducing the possible risks.

Patch Testing

The distribution of patches is carried out by manufacturers once it has been verified that they work correctly. This process does not guarantee their application in all control systems as each process is unique and therefore all patches should be tested, in the setting of a controlled test, before they are installed. Those systems which are found to be redundant can use back-up equipment in order to deploy the patches and verify the correct working within them, this way they do not interrupt any process which is under way as this is managed by the main equipment.

Patch Distribution

The patch manager needs internet access to download updates, but a control system shall not connect itself to the internet. Therefore the patch manager should be placed in the appropriate place within the network, from which it has internet access and can be connected to the control system equipment. If if were necessary, more patch managers can be placed which are linked to the main manager. To assure the authenticity of patches, they should be verified by being signed or with a hash-based verification which guarantees its integrity and that it truly comes from a reliable source.

-Deployment of patch tools-

Patch Programming

Patches cannot be applied at any point in time, but rather they depend on many factors (criticality, state of the process etc.) according to the process. The process of the application of patches should be planned in line with the needs of the process once they have been tested in a controlled setting. The process of planning the incorporation of patches into a system should be thought about in terms of the maintenance tasks applicable to the process.

The management of patches is a process which should be included within all industries to improve the level of security of their control systems. Their incorporation will generate some extra initial work which will be made up for in terms of the level of security and the reduction in stoppage time due to possible faults or malware infections.