DCS and SCADA Security Under The Spotlight

Securing Industrial Processes with OTORIO Expertise

DCS/SCADA systems play a crucial role in various industries, providing control and monitoring capabilities for critical infrastructure. These systems are usually complex, made out of many components and have unique characteristics that need to be addressed to ensure robust security. In this blog, we will delve into the world of DCS/SCADA security, discussing the current state of these solutions, identifying some common gaps in their security, and providing actionable steps to improve the security posture.

• DCS/SCADA systems play a crucial role in controlling and monitoring industrial processes across diverse industries, making them prime targets for potential adversaries.

• OTORIO has revealed that although DCS/SCADA systems incorporate certain security features, these alone are insufficient, necessitating active involvement from users, integrators, and vendors to enhance system security.

• Insecure default deployment configurations, division of responsibilities between clients and vendors, and usage of outdated technologies lead to significant security gaps in common systems.

• OTORIO have provided a checklist with the top 10 steps any DCS/SCADA user should consider in order to secure their system in the most cost-effective manner, based on our expertise with these systems.

• This newly introduced resource complements open-source tools that were previously released by OTORIO, and can ease the process of securing those systems (SIEMENS PCS 7 hardening, GE CIMPLICITY hardening, and DCOM hardening tools).

What are DCS and SCADA systems?

Both DCS (Distributed Control System) and SCADA (Supervisory Control and Data Acquisition) systems are used to monitor and control industrial processes. However, there are some key differences between them.

DCS systems commonly used in manufacturing plants. They integrate with various third-party systems, support multiple communication protocols, and offer high-level programming and monitoring capabilities. DCS systems commonly include features like HMI (Human-Machine Interface) and Historian for data storage and analysis.

On the other hand, SCADA systems are commonly being used in industries where the monitored processes are geographically dispersed, such as smart grid and oil and gas. SCADA systems are known for lower complexity and cost compared to DCS systems. They monitor multiple processes and are often limited in their capabilities compared to DCS systems.

Importance of DCS & SCADA security

DCS/SCADA security is of utmost importance due to their criticality and the potential consequences of successful attacks. These systems are highly connected, often deployed in higher Purdue levels, and frequently run on Windows environments, making them appealing targets for attackers. Given their top-of-pyramid positioning, compromising DCS/SCADA systems grants attackers privileged access to internal operational processes, enabling them to disrupt or manipulate operational processes and critical infrastructure.

In fact, DCS systems have been targeted by attackers in the past. For instance, Mandiant's analysis of the TRITON attack framework uncovered that gaining a foothold in DCS was one of the initial steps taken by the attackers. Highlighting the significant threats posed to these systems.

Mandiant's analysis of the TRITON attack framework

The current state of security in DCS/SCADA systems

DCS/SCADA systems provide different security features, such as operations/security auditing and access control options.

However, despite the availability of these features, we have observed that many environments overlook several important security gaps. For instance, while monitoring and auditing play a significant role in identifying and investigating security incidents, security auditing features are often not configured by default. Additionally, logs commonly do not adhere to industry standards, making them difficult to collect and analyze.

Moreover, the implementation of cybersecurity solutions like application whitelisting or endpoint protection (AV/EDR) requires deep system functionality tests and safety checks, and depending on the system’s criticality - also security updates should be verified up to a certain level. In addition, these systems require a level of expertise and maintenance that are not so common in many OT organizations (whitelisting policy updates as example)

Compliance with security standards is also offered by many systems, for example the IEC 62443-3-3 which is a well accepted security standard for industrial automation and system security. But, it is important to note, that while some products may support these standards, their implementation alone may not guarantee comprehensive security.

State of IEC 62443 compliance in common DCS & SCADA products

Main gaps in securing DCS/SCADA

Examining security gaps in DCS/SCADA systems reveals the challenges associated with securing them. The lack of clear division of responsibilities between clients, integrators, and vendors for securing different aspects of these environments, coupled with the older architecture of these systems, frequently leads to insecure deployments and a significant attack surface.

Division of responsibilities between the client, integrator and vendor

A significant challenge with the division of responsibilities in securing these systems relates to the secure deployment process. While vendors usually provide some security guides and recommendations we often notice that they are not fully applied in many environments. One main cause can be that the security part in the deployment process is not part of the initial installation of the system and not required for a functional system, which clients may assume to be secured on default setup. Clients and integrators are responsible for applying long and manual guides and in many cases, important security features and configurations may seem as optional and not a must.

Security guides for DCS/SCADA systems

While some issues may originate from insecure recommendations in the installation guide or professional forums, as we detected in SIEMENS PCS 7 environments, others may be even harder to notice. For example, the responsibility for the security of proprietary communication in those systems may lie with either the client or the vendor, depending on the specific product. We discovered this after reporting unsecure communication issues in both GE CIMPLICITY and ABB 800xA. GE addressed it as a product issue (CVE-2022-21798), while ABB defined it as the client's responsibility. In practice, this feature is optional and not configured by default.

While certain issues can arise from insecure recommendations found in installation guides or professional forums, as we observed in SIEMENS PCS 7 environments, others can be even more challenging to identify. For instance, the responsibility for securing proprietary communication within these systems may rest with either the client, integrator or vendor, depending on the specific product. We discovered this when reporting insecure communication concerns in both GE CIMPLICITY and ABB 800xA. GE acknowledged it as a product issue (CVE-2022-21798), whereas ABB designated it as the client's responsibility to set up IPSec for secure communication between servers in the environment.

ABB recommends clients to configure IPSec 

Another example relates to SBOM patch management. Vendors may assume clients are following advisories related to all components in their environments, even if installed as part of another solution installation. For example, in recent findings related to SIEMENS products, a vulnerability we’ve found in the Automation License Manager component affected many solutions - but advisory was released for the specific component only.

Automation License Manager advisory - PCS 7 and many additional products are not listed

Evolving systems, often based on legacy design

DCS/SCADA systems face security challenges due to their reliance on legacy designs and technologies. Wide use of old technologies, extensive network exposure and high trust in input files all contribute to a large attack surface on those systems.

Many industrial products heavily rely on outdated technologies such as DCOM. Although still supported by Microsoft, these technologies may not adhere to the latest best practices. For instance, dynamic port allocation in DCOM can make it challenging to properly segment services and requires special solutions. Additionally, insecure security configuration for DCOM services is also common in those systems, as highlighted recently after the DCOM hardening update by Microsoft, which caused issues in many industrial products.

Forced security patch impacting vendors with insecure DCOM configurations

The high network exposure of these systems, with many services listening on different ports, using different protocols and with separate security, further increases the potential attack surface.
During our research we’ve noticed 15-30 listening ports, exposed to the local network on each machine! Each of them potentially leading to additional risks of potential vulnerabilities, such as the Siemens Automation License Manager vulnerabilities we’ve disclosed this year.

Wide attack surface: ~15-30 exposed ports per machine

The exposure goes beyond implementation issues within the vendor's software, as third-party software like databases and Windows communication channels can also be vulnerable or configured insecurely. For instance, the recent discovery of the CVE-2023-21554 vulnerability in the widely used MSMQ (Microsoft Message Queuing) service exemplifies this risk, impacting DCS, SCADA, HMI, and Historian products. Another example involves our identification of an exposed Oracle DB with hardcoded credentials in SIEMENS SICAM Toolbox II - the configuration server of SICAM RTUs.

Furthermore, the loading of input files in these systems, such as project files or configuration backups, which are often unsigned and unverified, can lead to the execution of scripts and the introduction of potentially harmful configurations. This poses a significant risk, particularly when weak access controls are present in the network or when unsafe supply chain practices are involved.

Improving the security posture of DCS and SCADA

To improve the security posture of DCS/SCADA systems, there are several steps that users can take. These include hardening the systems, following vendor guidelines carefully,  limiting network access to necessary ports only, monitoring the Software Bill of Materials (SBOM) installed on the machines, and protecting sensitive files and backups. 

To ease the process, we’ve written a short checklist for bridging common security gaps in different systems.

DCS/SCADA security checklist

Additionally, our team has released multiple open-source hardening tools for automation of the detection and hardening tasks of common issues. This includes SIEMENS PCS 7 hardening, GE CIMPLICITY hardening, and DCOM hardening tools, which can assist in improving security.

OTORIO open source hardening tools - Siemens PCS 7, ABB 800xA and Microsoft DCOM

It is important to note that before making any active changes, it is essential to verify they are valid and safe for your specific system version and configuration.

Summary

DCS and SCADA security requires joint responsibility from both clients and vendors. While the current state of security has some gaps, there are various measures that can be taken to enhance the security posture. By implementing best practices, following guidelines, and leveraging available resources, organizations can significantly improve the security of their DCS/SCADA systems.