Home / Blog / Audits in control systems

Audits in control systems

Posted on 09/17/2015, by INCIBE
Audits in control systems

As is carried out by security departments in corporate environments, it is advisable for owners and operators of control systems to use cybersecurity audits as a preventive mechanism with the aim of finding out whether or not their systems are vulnerable and, as such, take the appropriate measures to protect them and make them more secure against attacks.

When performing such procedure, it is important to bear in mind the differences existing between corporate systems and control systems, since it may be that tools used in tests will have a serious impact on the control system, with operational failures being possible, as well as the complete cessation of operation and, as such, the potential impact of the tests to be carried out should be understood. All activities that may put the production system at risk must be carried out in a test system in order that potential failures do not impact the business or security of the installation.

An audit test can be carried out in different ways depending on what its objective is. Some tasks do not differ from those carried out in classic audits, but others must be carried out in a specific way. We indicate the different types below:


Review of technical documentation

The review of technical documentation attempts to obtain information from documents such as the assets inventory, architectural diagrams, diagrams of processes or documents of the procedures and the process. This review can be an effective tool if the aim is to prepare a cybersecurity audit or improve the process. It is normal in these cases to carry out a review of documentation in accordance with the need for it, as the audit advances.

It is important to bear in mind that a review of documentation does not allow vulnerabilities in the hardware and software of which the control system consists to be identified.

Review of functionality and configuration

The review of functionality and control of the configuration allow the control system to be evaluated through validation. This effort is focussed on understanding the unique requirements of control systems and their characteristics, and it allows identification of the areas in which to focus the audit in order to optimise it and observe weaknesses.

Through this procedure it is possible to improve the security of a production system without affecting its operation and allow aspects to be corrected such as default passwords, unnecessary open ports, etc.

Interviews with staff

Meetings with control systems operators are a very important source of information. Scheduling formal technical meetings with the staff who work with the control system can bring more relevant information than technical documentation. Furthermore, the time necessary for those in charge of carrying out the audit to assimilate it is also less.

The main objective of these interviews is to ensure greater knowledge and understanding of the processes and procedures of the control systems by the audit team.

Risk analysis

The risk analysis in control systems, as with corporate settings, is used to determine whether or not an asset is protected and at what level.

Carrying out a risk analysis requires less time and fewer resources than an audit, but its results may not be a good indicator of the security of the system since they only give a general idea of the system’s security, indicating the weak points on which to focus an audit.

A risk analysis is appropriate for certain situations, but they should never replace audits if the objective is to assess the system for vulnerabilities.


Laboratory audit

A laboratory audit is carried out on the control system that is disconnected from the production system, with the latter being a replica that is as similar as possible to the production system so that the data can be extrapolated.

A laboratory audit is effective when the objective is the search for vulnerabilities within the processes and protocols of communications used. It is necessary to bear in mind that the results may not be of much value if the owner cannot resolve the vulnerabilities identified because this has to be carried out by the manufacturers. However, knowing these vulnerabilities allows them to be aware of the risk to which the system is exposed and evaluate the possibility of taking additional measures to mitigate them.

The objective of a laboratory audit is to discover the real state of the production system’s security, describing the actions that an attacker may perform in the event of an intrusion, always keeping in mind the potential differences between the environment analysed and the real environment.

To carry it out, an intrusive-active type analysis is carried out in the devices. This analysis includes tests such as scans of ports and services, scans of vulnerabilities, etc., that may result in a state of instability within the system.

The information that can be obtained may be limited since it is often difficult to fully accurately replicate the configuration of a real environment. Audits of this type, which are black box tests, allow levels of security to be obtained both in the product and implementation.

Audit of a system in production

An audit of a control system in production is carried out in the installations themselves, while they are in operation, which means that all their characteristics are active during the test. This type of audit is carried out as a follow-up to a laboratory audit or when there is no other way of testing a control system, and it allows us to know the real level of security of the installation.

The audit of a system in production has implications such as the risk of devices crashing, excess network traffic, etc., which must be understood both by the system owner and by those in charge of carrying out the analysis. The objective, as with a laboratory audit, consists of answering the question of what an attacker could do in the system, although it is not always possible to answer this question through the audit.

To carry it out without affecting the process, or affecting it as little as possible, a passive or non-intrusive-active analysis is carried out, that is, without affecting or having any impact on the system, focussing on the monitoring of communications and on the configurations of the different devices.

End-to-end penetration audit

This is a test in which the objective is to obtain an understanding of how far an attacker could go. It is usually agreed in advance to what point the system will attempt access, normally in order to avoid actions that could affect the control process.

There are two ways of carrying them out:

  • From the outside: they are carried out without having any knowledge or a minimal knowledge of the system’s network, attempting to gain access through any of the services published.
  • From the inside: starting with the assumption that an attacker has already gained access to a specific point of the system, usually the corporate part.

Audit of components

This is focussed on the security of the product and it consists of testing the devices in isolation, that is, disconnected from the rest of the control system.

It is necessary to bear in mind that upon isolating a device, a large part of its functions, such as communications, may not be available and, as such, in this case the results will be partial. By contrast, it allows more extensive and intrusive tests without fear of affecting the system.

Likewise, it usually involves an associated analysis of the source code of the operating system and of the services and applications of the device.



During the whole audit process it is necessary to carry out a series of activities that lead to a correct analysis of the security of the system or device in question. The most important activities to perform include:


  • Identification of computers and verification of security controls
  • Scanning of services and ports
  • Identification of services
  • Identification of installed patches and those that should be
  • Search for 0-day vulnerabilities and the development of custom-made exploits
  • Fuzzing of services and ports
  • Analysis of the source code of applications and operating systems
  • Reverse engineering on the applications
  • Analysis of password strength
  • Web intrusion test
  • Device intrusion test
  • Verification of controls compliance with security policies