What is Operational Technology Penetration Testing?

Contents:

1. What is OT (Operational Technology)?
2. Who Supplies OT Technology and Where is it Used?
3. What Threats do OT Systems Face?
4. How Should OT be Security Tested?
5. 5 Steps for OT Penetration Testing
6. Risk Management and Mitigation

What is OT (Operational Technology)?

ICS (Industrial Control Systems) and SCADA (Supervisory Control and Data Acquisition) are systems used to monitor and control industrial processes and infrastructure. ICS are responsible for the direct control and automation of physical equipment and processes, while SCADA systems are used to monitor and collect data from those processes to provide a higher-level view of the overall systems. They play a crucial role in ensuring the efficient and safe operation of many important industrial systems as well as maintaining the overall stability of a country's infrastructure.

Who Supplies OT Technology and Where is it Used?

Several vendors supply OT and SCADA technology such as Siemens, GE Digital, Schneider Electric and Rockwell Automation. Operational Technology and SCADA systems are used in several different industries such as:

• Energy: e.g., monitoring and control of power generation and distribution of electricity
• Water: e.g., monitoring and control of wastewater treatment and water production facilities
• Oil and Gas: e.g., monitoring and control of pipeline and drilling operations
• Transportation: e.g., aviation, trains, buses, and subway systems
• Telecommunications: e.g., telephony networks
• Agriculture: e.g., irrigation and crop management
• Manufacturing: e.g., monitoring and control of production processes in manufacturing industries, such as chemical, and food and beverage

What Threats Do OT Systems Face?

Operational Technology faces the same cyber security threats that standard and everyday systems face and more. That is because many SCADA and OT systems were not designed with security in mind, and many lack basic security controls that you would see on common systems such as firewalls, intrusion detection and prevention and even basic encryption.

Whilst firewalls are becoming more prevalent the main issue here is the individual ICS assets. For example, PLCs (Programmable Logic Board) might only support a single processor password, but more problematic is the lack of HMAC (Hashed Based Message Authentication Codes) authentication which means once an attacker is suitably situated on the network there is not much stopping you writing whatever data you like to the PLC and the only thing stopping this would be physical security. More sophisticated controls such as 802.1x (The standard for port-based Network Access Control) often will not be implemented because ICS devices such as PLCs do not support it.

For example, if we look back to 2010 the Stuxnet malware caused considerable damage to Iran's nuclear program by targeting programmable logic controllers (PLCs) compromising them leading to the exfiltration of information regarding their industrial systems and even causing fast-spinning centrifuges to tear themselves apart. Although this attack was supposedly delivered via USB, it still shows the damage that malware can cause. Fast forward to 2016 and 2017, and both GE Digital and Schneider Electric's software were found to have vulnerabilities which could have allowed attackers to remotely execute code and take control of the systems.

These systems can also be susceptible to the more well-known attack vectors too, such as SQLi (SQL Injection) and XSS (Cross Site Scripting) via their management interfaces.

How Should OT Be Security Tested?

Penetration Testing Operational Technology ought to be distinct from conventional systems in a few ways. The engagement should begin with the scoping phase, as with all penetration tests. The approach should be responsible and cautious, considering the potential consequences of a successful attack on the system.

The consultant performing the engagement should have specialised knowledge and experience in OT systems, as well as the protocols and technologies they use, due to their unique nature and complexity. Ideally, any operational technology should be tested in a controlled environment that closely resembles the production environment rather than on live production systems. This will guarantee that testing will cause as little disruption or damage as possible.

Methodologies will also differ from standard penetration tests because they must be adapted to the characteristics of the systems under review. For instance, PLCs would not be tested in the same way as a regular Windows Server. OT devices have embedded CPUs that are prone to overload and frequently have poor network stack handling, which might interfere with device operation. In many situations, there are also legacy systems that employ out-of-date operating systems.

With the lack of HMAC in place on some PLCs as mentioned earlier and the fact that data can be written freely to PLCs, it is important to understand the impact of this. Could setpoints be altered outside of safe operating limits, for example? As with the 2021 Florida water attack, why was it even possible for the compromised HMI (Human Machine Interface) to command the PLC to dose dangerous levels of chemicals into the water supply system?

These systems, along with those that use end-of-life operating systems, introduce several problems that the vendor cannot and will not resolve. A simple malformed/oversized packet can bring these systems to a grinding halt which could be an adversary’s main goal. So, if indeed an attacker can send a simple malformed packet at system assets and cause significant downtime a lot of additional security controls will need to be in place to thwart this scenario which is why this issue needs to be validated by an appropriate professional.

With all this in mind the following steps should be taken before performing any security testing on OT environments.

5 Steps for OT Penetration Testing

1. Ensure the consultant has the necessary OT experience and knowledge to perform these types of engagements.
2. Establish explicit ground rules for interaction and refrain from using active, potentially dangerous penetration testing methods on live networks (I am looking at you Nessus).
3. Know your environment and engage with an OT/SCADA subject matter expert
4. Perform security testing on non-production systems where at all possible
5. Security testing should employ real world attack scenarios to ensure maximum value to your cyber security strategy.

Relating to the last bullet point (real world scenarios) it is worth establishing with your security consultant your Primary Security Concerns (PSCs). These help them understand your worries and ensure a valuable tailored engagement. Here are some examples of PSC's which I have personally been given in the past:

• In production, can the services the OT device is listening on data/programming ports (e.g., Modbus/ethernet) be reached if so, what can be done?
• Offline: What could an attacker do to an ICS asset if they could reach the data/programming TCP/UDP ports?
• Malware - OT Systems are vulnerable to Malware, Ransomware and Denial of Service attacks. (These attacks can have a massive monetary impact).
• External Attacks - The world has been heading the way of the home worker for a long time now however COVID-19 fast tracked this and as such more people are administering devices from home. What are the risks?
• Lack of Security Controls - As discussed earlier in the article, many systems were designed without a single security measure being implemented.
• Insider Threat - What about that rogue employee who decides to interrupt the normal operation of the system which could of course lead to significant monetary loss and/or a health and safety issue.
• Physical Security - What would happen if one of these systems were sabotaged or vandalised?

Risk Management and Mitigation

I have given you a high-level view of threats, attack history and why security testing OT is not Penetration Testing. But what can you do to manage the risk and even mitigate some of the attack vectors?

We can fit mitigation activities into three categories.

• Host
  • Ensure an adequate patching policy is in place for software and firmware.
  • Ensure there is an adequate disaster recovery plan in place and that any configuration files are backed-up.
  • Deployment procedures for new installations, ensuring that devices are secured before they are operational.
• Network
  • Conduct regular security testing.
  • Regular monitoring of systems for suspicious activity
  • Segmentation – For example, grouping together OT/ICS assets that require real-time communications between one-another into logical networks; explicitly governing communication messages between the logical networks with firewalls and industrial IPS.
• Physical
  • Lockable racks
  • Door access control