Repeated cyberattacks on plant and factory infrastructure have been a real wake-up call for the industrial automation industry. For the first time ever, it has been the target of sophisticated cyber-attacks like Stuxnet, Night Dragon and Duqu. The most destructive post-Stuxnet threat is the malicious malware known as Shamoon. As with Stuxnet, Duqu, and Flame,
It targeted organizations in the Middle East, in this case Saudi Aramco, Qatar’s RasGas, and likely other oil and gas concerns in the region. It is a new species, however, because it did not disrupt an industrial process as Stuxnet did, nor did it stealthily steal information as Flame and Duqu did.
Instead it removed and overwrote the information on the hard drives of 30,000 to 55,000 (yes, those numbers are correct!) workstations of Saudi Aramco (and who knows how many more at other firms). It is believed to have been launched by a single disgruntled employee working inside the corporate firewall. What Shamoon and the others teach us is that relying on a single defensive solution (like a single Internet firewall) exposes a system to a single point of failure.
No matter how well-designed or strong that single defense is, either resourceful adversaries or Murphy’s Law eventually results in the defense malfunctioning or being bypassed. When that happens, the entire system is wide open to attack. A far more effective strategy for reliable security is called “Defense in Depth.”
Back to the basics
The Defense in Depth strategy is not something unique to ICS/SCADA security. In fact, it is not even unique to cyber security. It is a military strategy that has been around since days of the Romans. If you search the Internet, the first definition you will find is the military one on Wikipedia: Defense in Depth (also known as deep or elastic defense) is a military strategy; it seeks to delay rather than prevent the advance of an attacker, buying time and causing additional casualties by yielding space. Rather than defeating an attacker with a single, strong defensive line, defense in depth relies on the tendency of an attack to lose momentum over a period of time or as it covers a larger area.
Defense in Depth for banking security
Unfortunately, if you want to secure your control system, the above definition does not help you much. So let us look at security in a bank and see what we can learn. Ever wonder what it is that makes a typical bank so much more secure than a home or convenience store? It is not because banks have stronger steel doors or armed guards. Those help a bit, but are quickly offset by the fact that a bank’s adversaries (i.e., professional bank robbers) are also better armed and more determined than the typical house burglar.
The first answer is that a bank employs multiple security measures to maximize its security. For example, just to name a few defenses, a typical bank has steel doors, bulletproof windows, security guards, room-sized safes, security boxes, alarm systems, cameras, and security-trained tellers. Even more important, not only are there more defensive layers at a bank, but each layer is designed to address a specific type of threat at the point where it is employed. For example, bank doors are effective, but simple, security devices. They are either locked or unlocked.
They either grant or deny access to customers on an all-or-nothing basis—regardless of what a visitor looks like or how the visitor behaves. One layer up is the security guards—they perform access control to “clean” the general flow of people into the bank. They ensure that access to the bank is for people who have a legitimate need to be there and will “behave” within expected norms.
They regard each visitor based on specific criteria, such as wearing a mask, suspicious behavior, acting erratically, etc. At yet another level, the tellers, security box keys, passwords, etc. keep these pre-screened customers from accessing other accounts or information. Rather than worrying if a visitor should or should not be in the bank, the tellers and passwords present a different layer of security: account security. These measures “filter” what account access individual customers are allowed, based on who they are.
Multiple differentiated layers
The bank analogy points out three important aspects of Defense in Depth:
- Multiple layers of defense. Do not rely completely on a single point of security, no matter how good.
- Differentiated layers of defense. Make sure that each of the security layers is slightly different. This ensures that just because an attacker finds a way past the first layer, they do not have the magic key for getting past all the subsequent defenses.
- Context- and threat-specific layers of defense. Each of the defenses should be designed to be context- and threat-specific.
This last point is the most subtle and perhaps the most important. Going back to the bank example, note that banks do not simply have additional security guards at every level. Banks understand that threats come in different flavors, ranging from the desperate drug addict with a gun to the sophisticated fraud artist. Thus for the banks, each defensive layer is optimized to deal with a specific class of threats.
Designing for the threat
So what does this have to do with security on the plant floor? Like the bank, the SCADA/ICS system can be exposed to a variety of different security threats, ranging from disgruntled employees, to computer malware, denial of service attacks, and information theft. Each needs to be considered and defended against. For example, a boundary firewall can act like the bank guard, so that network messages using specified protocols are either permitted or denied access into the control network.
This is ideal for keeping the bulk attacks out, particularly the average IT worm or the common denial of service attack. Deeper into the control system, more sophisticated SCADA-aware firewalls can observe the traffic beyond the obvious protocol types. This allows defenses based on the behavior and context of the systems using these protocols on the control network. For example, if an operator station computer suddenly starts trying to program a PLC, then perhaps a worm like Stuxnet or a disgruntled employee is at work.
These attacks need to be immediately blocked and alarms raised to prevent serious risk to the system. Finally, servers and controllers with a robust security implementation can act like a well-trained bank teller. After a user successfully connects to a server or controller, the security configuration ensures they only get access to the specific applications and data they are supposed to have access to. Attempts to access other services or data should be blocked and logged. As with the steel doors, the bank guard, and the teller example, the perimeter firewall providing the boundary security, the SCADA/ICS firewall providing the internal security, and the server providing the application security are an essential team. For example, a firewall can block millions of randomly malformed messages directed at a control system as part of a Denial of Service (DoS) attack. At the same time, deep packet inspection and user authentication checks can prevent an attacker or worm inside the firewall making changes that might risk property or lives.
Providing reliable security for the plant floor
Depending upon a single defense, such as perimeter firewall, is building a security solution based on a single point of failure. Make sure that your facility has a proper Defense in Depth design where the network, control devices, and systems are collectively hardened-thereby providing reliable security for the plant floor.
ISA offers standards-based industrial cybersecurity training, certificate programs, conformity assessment programs, and technical resources. Please visit the following ISA links for more information:
- ISA Global Cybersecurity Alliance
- Cybersecurity Resources Portal
- Cybersecurity Training
- IEC 62443 Conformance Certification
- Family of Standards
- ISA/IEC 62443 Cybersecurity Certificate Programs
- Suite of Security Standards
A version of this article also was published at InTech magazine.