Operational Technology (OT) systems drive and support the critical infrastructure the world depends upon.  These systems power our homes, produce the gasoline for our cars, run our mass transit systems, and many more things that keep our civilization running smoothly.  These systems often are seen as so sensitive and critical to the businesses they run, they aren't assessed, updated, or secured like the rest of the network.

The Purdue Enterprise Reference Architecture (PERA)

Since the 1990's, the prevailing way to ensure OT systems were available was to isolate them from all other systems.  The key word here is available; the Perdue Enterprise Reference Architecture (PERA) divided the enterprise into five zones.  Zones 0,1,2 and 3 were designed to ensure plant processes' availability and consistency.  This model intended to separate OT systems from IT systems, ensuring the plant was operational without interruption.

This assumes that IT systems don't need access to information or control over any of these OT systems and that they are never connected or the Internet (which was in its infancy during the time this was developed.)  Security in this model is rarely mentioned as it is designed primarily for plant and operational availability instead. These systems often went years, sometimes decades, without updates or security controls.

23 years later, this model is still used with OT systems.  These systems today are still largely isolated, vendors are slow to update software, and often times systems still run on legacy operating systems.  However, these networks have now been connected to the broader enterprise, often isolated by firewalls or in rare cases, data diodes.  More and more, however, the systems within these isolated networks need or provide data to and from the IT networks they are attached to.  This opens these systems to potential attack, so security should be prioritized over availability.

Compliance vs. Security - The Battle of the Ages

OT systems are often subject to industry-specific compliance requirements, NIST, NERC, ISO, etc., all have specific requirements.  Organizations usually have dedicated departments to implement and ensure that all compliance requirements are met and well documented.  However, just because these requirements are met and documented does not mean these systems are secure.  While security efforts often map well to their corresponding compliance controls, compliance alone doesn't indicate a well-secured system.

Instead, if organizations focus on securing and performing testing of the implemented security controls, compliance activities can often be documented in tandem.  Once actual security controls are put into place, tested, and risks identified and mitigated, compliance efforts can be documented and verified, allowing both goals to be achieved.  This gives organizations the best of both worlds, ensuring a robust security program around their OT systems and providing compliance documentation where required.

Assessing the Exclusions

Assessing OT systems is becoming more and more imperative as attackers, exploits, and malware for ICS/SCADA systems are becoming more and more prevalent. These systems have become more vulnerable than ever and are oftentimes the specific targets of attacks.  Successful attacks on these systems can have disastrous consequences, often risking human life and safety and having large monetary costs associated with the outage.

This has been demonstrated several times in recent years, with the Colonial Pipeline and the power outage in Ukraine being some of the most recent major outages.  Hackers penetrated the control systems and caused widespread outages, and were able to keep the systems down for long durations causing severe disruptions to commerce and endangering the public and reputation of these companies.

Testing the security controls around these systems could have easily prevented these attacks and the damage the outages caused.  A simple assessment that identified the risks and provided the organizations with the information required to put protections in place around these systems could have made a large difference in the outcome of this situation.

The sensitivity of OT systems makes them excluded from testing and isolated from the rest of the network.  This isolation is often an extreme form of security measure, a practice commonly known as an ‘air gap'. Putting an air gap between networks can be an effective security practice if done properly; this is rarely the case. Data from the OT systems are becoming a more frequent need for operational functionality, especially in the power transmission and generation sectors.

Access to this data is often governed by a firewall that allows other systems access to or feeds from these systems.  This firewall is often mistaken as an air gap by many organizations when in reality, it is only providing a layer of network isolation. In addition to getting data out of the OT systems, development, testing, and system update activities need to be performed, often leading to more access through the firewall than is communicated or known.

To further complicate matters, these systems are often run on legacy hardware and software.  Hardware replacements for these systems are often proprietary and expensive, and updating the software can cause issues communicating with the older hardware.  In many cases, these systems can be decades out of date. Entire control systems often are required to run on older versions of Unix and Windows that remain vulnerable because they have reached the end of life outside of the OT environments.

Testing these systems becomes imperative to provide an adequate picture of risk, knowing the threats to the system and organization at large, and knowing the methods, tools, and capabilities an attacker might utilize to access these systems. Performance testing the security controls in and around these systems is not without risks; however, not assessing these systems is a risk greater than testing these systems.

In Conclusion

Testing of these systems is no longer an optional activity. Instead, it has become an operational imperative.  The threat environment is now such that the operational risk of not testing outweighs the operational risk of testing these systems.  Testing can be performed safely and should be something done regularly.

By utilizing safe testing techniques, good operational practice, and security hygiene, interruption to operations can be minimized if not eliminated. Here at Lares, we have experts that can help organizations properly test and secure their OT environments, and they should be included in the scope of testing, not excluded.  With the proper tools and techniques, OT systems can be tested along with the rest of the systems on the network and help organizations see a comprehensive view of the risks within their infrastructure.