Cyber Security Threats - Actions to Take | Automation.com

Cyber Security Threats - Actions to Take

September 262011
Cyber Security Threats - Actions to Take
September 2011
 
Recommendations from Industry Expert
Part 2 of Interview with Eric Byres
 
By: Bill Lydon
 
Cyber Security is a hot topic that has become more intense since the notoriety of the Stuxnet virus. I interviewed Eric Byres, one of world’s leading industrial automation cyber security experts, to gain a greater understanding of the challenges and solutions for industrial cyber security. Byres earned the respect of the automation industry with a unique combination of experience and knowhow.   In addition to experience as a process controls engineer, he has researched and written extensively about Stuxnet and founded the British Columbia Institute of Technology (BCIT) Critical Infrastructure Security Centre, resulting in receipt of the SANS Institute Security Leadership Award in 2006. He is responsible for numerous industrial automation and SCADA cyber security standards and best practices and was formally recognized in Oct 2009 by the International Society of Automation (ISA) as an ISA Fellow. Byres is also chair of the ISA SP-99 Security Technologies Working Group, which is responsible for the standardization of technologies for Industrial Automation and Control System cyber security and the Canadian representative for IEC TC65/WG13, a standards effort focusing on an international framework for the protection of process facilities from cyber attacks.
 
His background is an important qualifier that lets you know what I already know - Eric Byres is a knowledgeable professional committed to the cause of industrial automation and SCADA cyber security. This is serious business.
 
Question: What is a simple definition of “defense-in-depth”?
 
Eric’s Comments: The “defense-in-depth” concept is to manage risk with diverse defensive strategies. It doesn’t just apply to cyber security – for example, banks employ defense-in-depth security measures to maximize their safety and security. Just to name a few defenses, a typical bank has steel doors, bulletproof windows, security guards, security box keys, safes and security-trained tellers.
 
Now layering defenses gives several benefits. The most obvious is that if one layer of defense is compromised, another defense, using a different security method, presents an additional obstacle which can inhibit further penetration. A more subtle, but equally powerful benefit is that attacks come in different flavors and each defensive layer can be optimized to deal with a specific range of threats. For example, defending against a standard computer worm needs different techniques compared to defending against a disgruntled employee.
 
Question: Are there challenges for protecting systems that use OPC?
 
Yes, but they can be overcome by layering defenses that are OPC-aware - high security solutions can be created that meet both the security and access expectations of a company without administrative overload on the network or controls team. I have co-authored a white paper, “Effective OPC Security for Control Systems” that addresses this.
 
Question: Is a defense-in-depth strategy important for all control systems or is it just needed for very critical safety systems?
 
Eric’s Comments: Every control system should use defense-in-depth architectures. Very critical safety systems just need more layers.
 
Consider the office environment. In addition to the corporate firewall, even the most unimportant office PCs will have personal firewalls, automatic patch systems and anti-virus software installed. This is a defense-in-depth strategy for office equipment. Now isn’t the PLC, DCS or the HMI more critical to the success and safety of the company, compared to say an intern’s desktop? Yet in most companies the PLC or DCS will be completely undefended, while the intern’s desktop gets hundreds of dollars (if not thousands) of security software and security resources thrown at it. We have our priorities all mixed up.
 
Specifying Software and Equipment
 
Question: What should users be asking control systems vendors to insure they are protected?
 
Eric’s Comments:  They should be asking that the vendors equipment is ISASecure certified. Obtaining the ISASecure Level I certification is significantly more difficult than passing a Communications Robustness Test (CRT) like Achilles Level I (or II or III). It starts with a CRT assessment phase similar to Achilles Level I (it actually uses the Achilles tool), but then it adds two more assessment phases:
 
  • Functional Security Assessment (FSA)
  • Software Development Security Assessment (SDSA)
This certification indicates a far higher level of security in both the product and its intended use and is what customers should be demanding. I have lots more on this topic at http://www.tofinosecurity.com/blog/honeywell-leads-ics-and-scada-world-first-isasecure-certification
 
Question: Is a switch or router with access control lists (ACL) as secure as a firewall?
 
Eric’s Comments: NO – In the words of BP’s former Chief Security Officer, Dr. Paul Dorey, “A Router is NOT a Firewall”. The reason is that while routers and switches can filter packets, they do not understand the state of the communications traffic flowing through them. Thus they can let inappropriate traffic through. For example, imagine a router that has an access control list (ACL) (i.e. a rule) that allows web traffic in and out.  Now if it receives an unsolicited reply (i.e. a web reply to a message that was never requested in the first place), it will let that packet through. This exposes the protected device to a significant security risk. For example, an attacker could easily bombard a PLC with unsolicited replies, causing a denial of service.
 
In contrast, a good firewall provides stateful traffic inspection where it checks not only the packet contents, but also if the packet is appropriate for the sequence of traffic it has seen previously. Some firewalls can also perform deep packet inspection, where they go beyond the simple “Who sent this message” type checks and determine the actual purpose of the message. For example a Modbus TCP DPI firewall will check every Modbus command (and response) against a list of ‘allowed’ commands. Any command that is not on the ‘allowed’ list, or any attempt to access a register or coil that is outside the allowed range, is blocked and reported. It will also look for and block deliberately malformed MODBUS messages that are designed by hackers to corrupt or crash a PLC or DCS.
 
Question: Is a PC with two network cards a good security solution for isolating networks?
 
Eric’s Comments: NO – Computers with two network cards are known as “Dual-homed” and are widely seen as easy targets by the hacking community. For example, the following discussion can be found on the web by searching for the phrase “Dual-Homed Computers”:
 
“How to get around the firewall? The juiciest targets are dual-homed machines -- that is, boxes with two NICs connected both to the DMZ and the internal net. In theory there should be none; in practice, users frequently do this so they can get their work done more quickly.”
 
 
Dual-home machines were also a significant factor with Stuxnet. I strongly recommend against the use of Dual-homed computers as a security mechanism in any control system.
 
Question: If a PLC only uses serial communications is there still a security risk?
 
Eric’s Comments:  Malicious traffic can travel over a serial network just as easily as an Ethernet-based network. For example, the Slammer worm was able to infect a paper machine HMI via a dialup modem. Researchers have also shown how deliberately malformed MODBUS packets over serial can be used to crash PLCs.
 
Question: Aren’t PLC passwords sufficient protection?
 
Eric’s Comments: No – I can show you how to intercept most PLC passwords in under a minute. Dillon Beresford did the same with Siemens PLCs at the recent Black Hat 2011 conference. Most PLC passwords are just a dangerous placebo.
 
Question: Eliminating physical Ethernet connections and routers is a one of the benefits of using virtualization to run multiple applications on one hardware platform. For example, HMI, historian, asset management, and system optimization may all run in virtual machines on one hardware platform.  Does this create cyber security risks?
 
Eric’s Comments:  Virtualization really doesn’t increase or decrease security risks. It can save you money for hardware, management and energy consumption, but for security it is pretty much even. After all, the hackers’ goal is typically to compromise an application on a server. He or she does not care what physical or virtual platform it is running on.
 
IPv6
 
I have been looking at the new IPv6 standard that is replacing IPv4. IPv6 is being mandated by the Untied States government in 2012 and already is the norm in China. IPv6 has a new security model, IP Security (IPSec). These are some questions I have about IPv6 as there networking standard.  (Article reference: Ethernet Infrastructure - Is IPv6 another Y2K?)
 
Question: Does IPv6 offer greater inherent cyber security than IPv4 for industrial automation systems?
 
Eric’s Comments: Yes, but it also offers some risks too. Because it supports native encryption, it can be hard to see what is happening on your network. A friend of mine in the IT world once told me “As soon as I see IPv6 on a network I know that a hacker is in the system and hiding his activities”. This is changing as IPv6 get wider adoption, but it is still a concern in the control system world.
 
Question: Major networking vendors corporate IT departments are starting to use IPv6 for their infrastructure.  In a plant, the industrial networking protocols, controllers, and other devices are IPv4 and the systems will need to connect with IPv6 based enterprise IT systems.   Considering cyber security concerns are there any best practices to best configure these mixed networks?
 
Eric’s Comments: Frankly it is still early days for IPv6 in the corporate network. Many major manufacturing companies I have talked to still have no plans to deploy it internally. Even fewer have plans to push it to the plant floor. So this is very new ground and “best practices” are really limited.
 
What I can say is as you noted, there is little chance that any manufacturing or process operation can do a wholesale IPv4 to IPv6 conversion.  There are just too many legacy control products that will be stuck at IPv4 for decades. So this means any solution must be a coexistence solution and there are three approaches for this:
 
1.  Dual-Stack
2.  Translation
3.  Tunneling
 
Translation in particular can have its issues (just like NAT in IPv4), especially with protocols like FTP or OPC were addresses get embedded in the message. So most of the applications I have seen in the ICS space involve the latter, namely tunneling IPv4 from an ICS network over an IPv6 corporate network.  Standards like Host Identity Protocol (HIP) can be useful for sorting out this.
 
Bottom line is there is an interesting toolbox of IPv6 transition methods, but each is suited to certain scenarios.  There is no single ‘best’ solution at this point.
 
Question: What are the challenges and dangers of configuring an industrial plant with an IPv6 IT network and links to an industrial network that is IPv4?
 
Eric’s Comments:  Not many dangers, but unless you are completely IPv6, there is little benefit. Right now, few vendors really support IPv6 on SCADA and control system equipment.
 
Question: It seems that the use of Ethernet for industrial networking of controllers and sensors is increasing the vulnerability of automation systems to cyber attacks. The analogy might be how Windows-based PCs are significantly more vulnerable to viruses than Apple’s computers. Are cyber security risks lowered if industrial automation controllers and sensors are connected with non-Ethernet industrial networks including DeviceNet, Profibus, Modbus, CANopen, and AS-I Bus?
 
Eric’s Comments: Perhaps a little, but remember that Stuxnet made extensive use of Profibus to both coordinate attacks between infected PLCs and to eventually reprogram the drive controllers to damage the centrifuges. Basically, the improved security benefits are marginal.
 
Question: The cyber security risk can be a bit overwhelming. What should be the first steps companies should take to define a standard and build a program to protect against cyber attacks?
 
Eric’s Comments:  According to the ISA99.02.01 and IEC62443 standards, the first should be a Security Risk Assessment, a belief I share wholeheartedly. Unless you know the risks you are trying to mitigate, you are just throwing your money away.
 
Unfortunately, I see many companies do exactly that – a salesperson says “buy my security technology and all will be secure” and companies believe him or her and throw money at a solution for what might be a minor risk, leaving far more serious risks unaddressed. Companies like exida (www.exida.com) do great work in this area and have sophisticated risk analysis tools and services available.
 
Next, Vulnerability Analysis and High Level Security Requirements Analysis are needed. In other words, now that I understand the risks, what are my vulnerabilities and what must I do to address them at high level. Again, while some companies have the internal skills to do this, most need the help of a specialist team like exida.
 
Then we can start getting into the details and technologies. The first step is to design a security architecture/mitigation strategy and select specific security technologies to achieve their security goals. For example, these technologies might include:
 
This list can get long, but the above covers the main technologies currently used in modern SCADA and ICS systems.
 
Thoughts & Observations
 
It seems logical that cyber security risks for automation systems are growing with the incorporation of mainstream technologies by automation protocols including Modbus TCP, EtherNet/IP, PROFINET, WirelessHART, ISA 100, WIA-PA, and BACnet.   A major enabler for hackers are the IT standards leveraged by these protocols including TCP/IP Ethernet, wireless Ethernet (802.11), Wireless Mesh (802.15.4), and 6LoWPAN. The wider use of these standards outside of automation makes them targets for hackers.
 
IPv6 doesn’t seem to be a factor at this point that will affect automation networking. In fact none of automation network standards are IPv6 ready and in most cases it will require major structural changes in the protocols creating incompatibilities between the IPv4 and IPv6 versions. I still feel that this will become an issue at some point in the future.
 
It is clear that automation groups should have plans to protect systems from cyber threats and Eric Byres recommendations are a good starting point.
 
More IPv6 Information
 
Five ways for IPv6 and IPv4 to peacefully co-exist
By Steven J. Vaughan-Nichols, October 14, 2010
Summary:Ready or not, you’re going to need to use both IPv6 and IPv4 on your corporate intranet and to connect to the Internet for years to come. Here are some ways to do it. http://www.zdnet.com/blog/networking/five-ways-for-ipv6-and-ipv4-to-peacefully-co-exist/244?tag=content;siu-container
 
CISCO IPv6 White Papers
Deploy CGN to Retain IPv4 Addressing While Transitioning to IPv6 (PDF - 490 KB)
IPv6 Addressing at a Glance (PDF - 180 KB)
IPv6 Extension Headers Review and Considerations
IPv6 Headers at a Glance (PDF - 100 KB)
IPv6 Home Networking Message Guide (PDF - 190 KB)
IPv6 Mobility at a Glance (PDF - 70 KB)
IPv6 Multicast at a Glance (PDF - 97 KB)
IPv6 QoS at a Glance (PDF - 58 KB)
IPv6 Routing at a Glance (PDF - 52 KB)
IPv6 Transition Strategies (PDF - 1 MB)
 
Internet Protocol version 6 (IPv6): http://en.wikipedia.org/wiki/IPv6
Did you Enjoy this Article?

Check out our free e-newsletters
to read more great articles.

Subscribe Now

MORE ARTICLES

VIEW ALL

RELATED