The industrial control system (ICS) is the set of resources and machines used to supervise and control an industrial process. This article looks at the security issues surrounding Windows devices of the ICS supervision and maintenance layer: SCADA servers and clients, Data Historians, engineering stations, and maintenance laptops.
A SCADA (Supervisory Control And Data Acquisition) system enables the remote management and control of industrial installations. This includes machines such as supervision stations, data centralization servers, maintenance laptops…).
SCADA stations include three main functions:
- Acquisition: Sensors are present on the programmable logic controllers (PLCs) acting on the industrial process. These sensors are connected to the SCADA system so that the various process data can be retrieved.
- Supervision: Operators access the retrieved data and supervise the industrial process in real time.
- Control: when the industrial process allows it, operators can send control commands to PLCs in order to adapt the process.
The nature of these workstations makes them an important element in the production chain, which is why it is necessary to secure their software, which often runs under Windows.
However, there are several limitations compared with a workstation in a conventional office environment:
- The workstations run continuously, with a very low update frequency (once every 1 to 2 years);
- What’s more, these workstations have a long lifespan, often more than 10 years. A SCADA workstation will therefore partly run on an obsolete operating system, which will no longer receive security patches during its lifetime.
- Finally, industrial systems are sometimes totally isolated, preventing the use of security solutions such as Endpoint Detection and Response (EDR), which need to be able to communicate with a central console to send alerts and retrieve actions to be taken.
Conventional security solutions are therefore not applicable in an ecosystem subject to these limitations.
A possible solution: application control
One solution to these problems is application control: this involves managing which applications are allowed to run on a machine, and which are not, by whitelisting authorized applications.
Application control solutions manage both ‘.exe’ files and other program types such as DLLs, drivers, and scripts (e.g. PowerShell, CMD or VBS).
A significant proportion of threats come from malware. This kind of solution allows one to only authorize needed applications, while blocking any undesirable or dangerous ones. Application control also maintains a good level of security in an obsolete system prone to vulnerabilities, since during the compromise stages, an attacker is often led to run malware on a system.
Furthermore, application control is easily integrated into the industrial environment: supervisory workstations are subject to far fewer changes than an office workstation, so there is no need to constantly review the whitelist to add applications to be authorized.
Application control solutions for Windows
Two application control solutions are available natively on Windows: Windows Defender Application Control (WDAC) and AppLocker. WDAC appeared with Windows 10; it is the successor to AppLocker, which has been present since Windows 7. The two solutions have remarkably similar functionalities, however WDAC is actively maintained by Microsoft with regular additions of new features, whereas AppLocker only receives security updates.
When an application is not authorized by the whitelist, its execution will be blocked and the error message below will be displayed to the user. An event containing the blocking information will also be recorded in the Windows logs for review by the Security Operations Center (SOC), or information system administrators.
Application control can operate in blocking or audit mode. In audit mode, the list used is tested: unauthorized applications are still executed, but a blocking event is registered to indicate that they would not work in blocking mode.
For effective application control, it is necessary to create a whitelist that is as restrictive as possible, while still allowing business applications. For both solutions, the whitelist can be set up with three different rules:
- Path-based rules: authorize the application according to the path from which it is executed. These are the easiest rules to use, but they can lead to security issues. It is not uncommon to find authorized folders in the whitelist that are writable by users. Users will then be able to drop any application into the folder to run it, thus bypassing application control.
- Editor rules: authorize the application according to the elements of its digital signature. These rules are just as easy to use as path rules but maintain a high level of security by only authorizing applications from legitimate publishers. The main advantage of this type of rule is that they remain valid after an application update, as the publisher does not change. However, this would require the applications awaiting authorization to be signed, which is not always the case in industrial environments.
- Hash rules: authorize applications according to their hash. These rules impose the highest possible restriction. As each application’s hash is unique, only code explicitly authorized by the policy can be executed. However, this type of rule generates a significant organizational cost: any modification to an application changes its hash; the rule must then be updated to correctly authorize the application.
When it comes to choosing the type of rule to use, there are two possible scenarios:
- On equipment receiving updates, editor rules should be preferred to be able to maintain the validity of the whitelist even after application files have been modified. Path rules can be used secondarily for unsigned applications, while paying particular attention to the access rules for the directories in question.
- On equipment whose configuration will not change, editor rules can be used to easily authorize Windows core code. Business applications can then be authorized using hash rules, as they are unlikely to be modified.
Implementation steps
Now that we know which rules to use, we need to create a whitelist for the machine to be secured. Two approaches are adopted, depending on the type of machine to be managed:
Temporal approach: Deployment by continuous improvement
This method consists in deploying application control starting with a basic policy authorizing Windows components, which is then improved little by little thanks to events generated by the execution of business applications.
This approach is particularly well suited to existing production workstations, where administrators do not have much information on the system. Each event generated must then be reviewed to assess whether the application being executed is legitimate or not. This provides an exhaustive whitelist without authorizing illegitimate applications.
Model-based approach: Deployment on a “golden image”, then replicated on the rest of the machines.
In this approach, WDAC will be deployed on a “golden image“, i.e. a clean image containing all the applications required for the machine’s business use. Once the policy has been correctly configured, the golden image can be cloned on all other machines with the same role. Typically, the golden image could be produced following acceptance testing (FAT/SAT) when a new plant is set up.
This approach is recommended for commissioning new stations into production. By starting with a blank machine where all the software required for the job is installed, we can ensure that no illegitimate applications are present on the machine. It is then possible to use the tools provided by Microsoft to scan the machine and automatically generate a whitelist, authorizing all applications present on the machine.
Limits of application control
It is important to bear in mind the limitations of these solutions, which are not fallible. By their very nature, the actions of an application authorized to be executed are no longer monitored, and the application itself can execute code or launch other programs. Consequently, if an attacker were to discover a vulnerability in a whitelisted application, application control would not prevent its exploitation, which would allow the attacker to influence the industrial process, but it would not allow malicious files such as ransomware to be executed.
There are several ways of bypassing application control, using programs that come as standard with Windows. This is particularly true of ‘mshta.exe’, which can be used to run stand-alone HTML applications (.hta) that can execute code on a machine. For this reason, Microsoft constantly maintains a list of applications present in Windows or signed by Microsoft to be blocked, in order to tighten application control.
The same principle applies to business programs. It is up to manufacturers to have their applications audited to ensure that no vulnerabilities are present that could allow the workstation to be compromised.
Application control on Windows: WDAC or AppLocker?
Overall, both solutions are remarkably similar and compatible with the two deployment modes presented above, so the remaining question is how to choose between the two.
Whenever possible, it is best to choose WDAC: its strength lies in its global control capability and its various functionalities. AppLocker can only control programs ran by the user, whereas WDAC can also control programs ran by Windows, such as drivers.
What is more, WDAC integrates additional features such as protection against elevation of privileges, and automatic verification of user access on path rules. Microsoft also continues to support the solution and enhance it with new features, while AppLocker only receives security updates.
AppLocker is generally simpler to use than WDAC and allows differentiation regarding the application of rules according to the machine’s users, whereas WDAC’s rules apply to the whole machine without distinction.
However, WDAC is only available on Windows 10 and above. On machines running Windows 7, which are still very common on industrial networks, AppLocker is the only native solution available and should therefore be used. On Windows 10 and above, WDAC is the better application control solution, and should be preferred.
In addition, AppLocker can be used alongside WDAC if you need to differentiate rules for different users. WDAC should then be implemented at the most restrictive level possible, then AppLocker can be used to fine-tune the restrictions.
