Defending Against Industroyer2 and Securing OT in a Connected World

With its most recent deployment of the Industroyer2 malware to Ukraine, there has been an increase in cyberattacks by state-sponsored hackers on the nation’s vital resources. However, the effects of the attacks go beyond the country’s main operations to critical business functions. Let’s learn more about Industroyer2, other attack methods, how to counter them, and how OT links to the infrastructure of regular business operations.

In April 2022, SandstormOpens a new window , a hacking group active since 2009 and associated with Russia’s General Staff Main Intelligence Directorate (GRU), launched an attack against Ukraine’s electrical infrastructure. The attack, Industroyer2, one of many during the Russian invasion of Ukraine, was thwarted, but it is one more instance of a new facet of warfare.  

Attacks against operational technology (OT) are not limited to national takeover attempts. Related to denial of service attacks, disruption of OT can take down critical business services, resulting in loss of service or product delivery as an organization struggles to survive. All organizations that use OT must ensure secure operation, and the safety of employees, throughout all hardware and software lifecycles.

See More: Modern Strategies to Combat Cyberattacks on Operational Technology

What is OT?

Before looking at Industroyer2, other attack vectors, and how to defend against them, it is crucial to understand OT and how it relates to general business infrastructure.

Figure 1, from my previous article on ICS security shows an example of a basic, poorly configured OT environment connected to a business network. The OT (ICS) network controls industrial processes. The data collected by the supervisory systems are aggregated, correlated, and written to the business data center servers. All network segments, including the office environment and the internet, are simply separated by a core switch, a switch only operating at layer 2; no VLANs are configured.  

Any infection reaching a business office system could find its way to the OT network. Further, nothing prevents one device on the network from “seeing” all other devices, violating zero-trust, and elevating the risk of insider attacks.

Sandstorm operators relied on a configuration like this example to enable its attack objectives, but Ukraine had already hardened its power OT environment.

What is Industroyer2?

The original Industroyer, first identified in 2017, also controlled by Sandstorm, targeted power systems in Ukraine. André Lameiras reportedOpens a new window that it was the first identified malware designed specifically to attack power grids.

Industroyer and Industroyer2 essentially work the same, and Sandstorm’s development of them required in-depth knowledge of the components used by Ukraine. The primary difference is in scope, with Industroyer focusing on IEC-101 and IEC-104, OT management protocols within IEC-61850Opens a new window , for access to process controls. According to the Blackberry Research and Intelligence TeamOpens a new window , Industroyer2 focuses on IEC-104 controllers to disrupt services.

It is unclear how the initial infection occurred, but researchers know it included a worm. Industroyer2 is installed and begins to disrupt OT, specifically high-voltage electrical substations. An updated copy of CaddyWiperOpens a new window , system wiping malware, is also included in the payload and makes the infected system unbootable. Additional system wiping malware (ORCSHRED, SOLOSHRED, and AWFULSHRED) are installed on any Linux or Solaris systems vulnerable to infection, destroying any chance of quick recovery.

The Industroyer2 attack was well planned and executed and continues to move against the power grid, but Ukraine is prepared; the attack was effectively managed, an example of the importance of OT design and incident response planning.

Industroyer2 is just one example of attacks against OT, attacks that are not just a threat to governments and critical national infrastructure. Private organizations are also potential targets. Any organization using OT requires special attention, addressing security objectives different from those related to general business infrastructure.

Securing OT in a Connected World

Securing OT involves a set of considerations, each implemented at a level needed by related risk, including

• Restricting physical access
• Protecting individual OT components from compromise
• Securing supply chains
• Business continuity management
  • Managing incident response capabilities 
  • Ensuring operational redundancy
• Restricting network access with zero-trust methodologies

Restrict physical access

Physical access to an OT device, especially sensors and actuators, gives a threat actor full access to achieve attack objectives. Physical access controlsOpens a new window should provide layers of barriers, along with detection and alerting safeguards, creating carefully controlled restricted areas.

Protect individual OT components from compromise

Protecting many OT devices requires similar steps needed for all other infrastructure, including

• System hardening
• Enforcing the least privilege and separation of duties
• Monitoring
• Continuous and scheduled auditing processes of the effectiveness of
  • Physical controls
  • Logical controls
  • Antimalware efforts
  • File integrity
• Patching

Supply chain security

Another consideration for protecting IIoTOpens a new window (Industrial Internet of Things) devices is managing supply chain risk. As I wrote in a previous article, the software supply chain (SSC) consists of the pathways for delivering new software, firmware, or updates. The problem with this channel is its vulnerabilities, which enable threat actors to insert malware during the update process.

Figure 3 is an elementary example of how a threat actor might insert a malicious payload into the SSC, enabling infection of the updated devices/systems and causing a compromise that is difficult to find if the proper monitoring controls, including physical inspection, are not in place. 

In addition to providing a long list of ways to protect the OT supply chain, the CISA provides an infographicOpens a new window listing essential steps for building an effective supply chain risk management practice.

1. Identify – Determine who from your organization needs to be involved
2. Manage – Develop your supply chain security policies and procedures
3. Assess – Understand the hardware, software, and services you process
4. Know – Map your supply chain to understand better what components you procure and how the related vendors manage them
5. Verify – Determine how your organization will assess the security culture of suppliers, all links in the supply chain
6. Evaluate – Establish timeframes and systems for checking supply chain practices against guidelines

Supply chain security is paramount, but fully addressing it goes far beyond the scope of this article. For additional information, see

• Supply Chain Attacks: Why Risk Management and Business Continuity Planning are Essential
• Supply Chain Risk ManagementOpens a new window (video)
• ICT Supply Chain Resource LibraryOpens a new window , Cyber Security and Infrastructure Security Agency

Regardless of how you manage SSC risk, it is essential to strictly control any vendor access to OT devices, ensuring that any changes pass through a change management process, including the testing and validating of any software or firmware updates.

Business continuity management

Business continuity managementOpens a new window for OT goes far beyond just keeping the business running; it also includes ensuring that OT devices that control manufacturing or service generation processes will not fail in a way that causes human injury or death. In this article, I will focus on two elements of BCM: incident management and operational redundancy.

See More: Rise of Hacktivism: The Evolving Role of Hacktivists In the Ukraine-Russia Conflict

Incident response helps ensure mitigation of business impact, the continued safety of employees, and the quick return to normalcy. Effective incident response requires planning, testing, training, and regular reviews of documented communication channels and involved stakeholders; and the continued effectiveness of the various response processes needed to address all possible OT incidents.

My free book, Incident Management and Response Guide: Tools, Techniques,  Planning, and TemplatesOpens a new window , provides a sound basis for building a new incident response program or reviewing the one already in place. 

The redundancyOpens a new window of OT infrastructure can help bypass compromised components, enabling continued operation. The continued operation might be at a service level below what customers expect, but a complete failure is avoided. Redundancy can also help ensure safe management of temporarily shutting down OT components without a sudden failure,  resulting in human injury or infrastructure damage.

And don’t forget redundancy in the supply chain. Upstream services might provide the capabilities needed to continue operations. The article Disruption-Tolerant Supply Chain Planning and OperationOpens a new window by Cyrus Hadavi is a good overview of how to build resiliency into your supply chain.

The key takeaways from this section are to never build single points of failure into your network or industrial processes, ensure that any failures result in a controlled takedown of infrastructure (if needed), ensure human safety, and ensure quick recovery of service/product delivery.

Approaches to OT Security

Restrict network access

Access between the OT network and other network segments, including the internet, must be strictly controlled. Air gapping is not an option with the growth of IIoT. Consequently, network segmentation control design, up to and including microsegmentation, should be part of any OT architecture, completing a fundamental step in achieving zero-trust networking.

Approaches to OT security have been available for some time, including the Purdue Model and the advent of edge computing. First is the Purdue Model.

Figure 4 is from my article Securing Industrial Control Systems From Modern Cyber Threats. It lists the layers associated with the basic Purdue Model, dividing the OT and business environment into zones, enabling clear security barriers between operational areas.

• Level 0 – The sensors, robotics, and other physical devices that work in the production environment.
• Level 1 – This level contains the proximate devices with direct control over Level 0 devices. A programmable logic controller is an example.
• Level 2 – Systems collects information from Level 1 for automated response or employee interaction via the HMI.
• Level 3 – Level 2 functionality might be restricted to a specific plant zone or area. Level 3 systems collect and manage information from across an entire site.
• Level 4 – Eventually, information from levels 0 through 3 is provided to business systems functions that directly support production, such as logistics. Devices include servers and database servers.
• Level 5 – This level contains the rest of the corporate network, including financial, HR, and customer-facing systems. It is also assumed to include internet access.

One way to look at segregating these levels is shown in Figure 5. This simple example uses firewalls created and configured to manage traffic between the layers. 

• No office personnel are allowed network access to levels 3 and below
• The industrial DMZ enables OT access to the internet and writes management data to the data center; a one-way path, preventing the data center from sending traffic back to the OT systems
• Personnel at level 3 monitor and control the OT devices on the plant floor, managing the OT processes, as shown in Figure 6; the human-machine interface exists in level 3

In Figure 6, the humans at the HMI monitor controlled variables sent from sensors and other OT devices and send manipulated variables back through the controller to adjust performance.

As I wrote in my article Achieve a Zero Trust Network with a Software Defined Perimeter, applying zero trust to a network requires constant monitoring and identity validation. No subject (device or human) should pass any trust boundary, any entry point to a different Purdue Level unless the subject is explicitly allowed access and unless the need for additional authentication is assessed.

Edge computing

The Purdue Model was created before the explosion of IIoT devices. IIoT devices are designed to regularly communicate with on-premise and cloud resources used to manage the OT processes, ensuring expected results but introducing additional risk elements into the OT attack surface.  

Figure 7 shows the Gartner IoT Reference Architecture that adapts the Purdue Model for the use of IIoT in OT, creating an environment in which IIoT can be controlled and monitored from the cloud and providing for gateway segmentation. I added the Purdue Model application to the architecture.

IIoT gateways provide connecting, operating, and security capabilities, including 

• Protocol translation translates different protocols used by a large variety of IIoT devices that might exist in a single OT environment.
• Edge computing includes gateways that direct traffic to where it is needed, moving servers and applications closer to where IIoT data is collected.
• Instead of using traditional firewalls, the Gartner model uses IoT gateway devicesOpens a new window that add additional functionality needed for zero-trust implementation, enabling authentication when trust boundaries are transited.
• Encrypting all traffic.

Final thoughts

The failure of Industroyer2 to destroy Ukraine’s power grid is a good example of how hardening OT can enable resiliency. If Ukraine had simply connected OT devices to an existing network without special care, the outcome would have been much different.

Whether using the Purdue Model, the Gartner reference model, or some other approach, assessing the risk in your existing OT environment is vital and using an accepted OT security model to mitigate that risk. 

Which OT security model have you leveraged to contain harmful malware? Let us know on LinkedInOpens a new window , Facebook,Opens a new window and TwitterOpens a new window . We would love to hear from you!

MORE ON CRITICAL INFRASTRUCTURE SECURITY 

• Russia-Ukraine Conflict: Shining a Spotlight on Critical Infrastructure Security
• Lessons Learned from Cyberattacks on Critical Infrastructure
• Secure the Weak Points in Critical Infrastructure Environments Before It’s Too Late