Security Basics: Securing a PLC
Wednesday, March 9, 2016 @ 12:03 PM gHale
By Erik Schweigert
As a software engineer who creates industrial security technologies I am often asked “Why are industrial networks so hard to secure?” This is a big topic, so I am going to focus on “Why are PLCs so insecure?”
The answer to this requires a walk down memory lane. If you are a controls engineer you already know some of what I have to say, though maybe not the security considerations this article addresses.
If you have another job function or work in another group such as IT, this could provide you with useful baseline knowledge about industrial control system (ICS) security.
History of PLCs
Historically speaking, PLCs (programmable logic controllers) have been around since the early 1960s. The PLC started to see action shortly after the microprocessor came out, as it allowed companies to replace the racks of relays that had previously performed industrial control. These panels of relays were difficult to modify, were hard to maintain and were a challenge to diagnose if a problem arose. Fixing a set of relays was a difficult task, especially since failures had the annoying tendency to happen at 3 a.m.
As you know, the ICS industry covers a lot of ground: Power generation and transmission, water/wastewater systems, oil and gas pipelines and manufacturing, to name a few. PLCs initially concentrated in the manufacturing sector, but soon they migrated to applications in most industries. For example, they ended up selected as an ideal way to control very sensitive high speed systems, such as the compressors and turbines on natural gas pipelines.
Initially the PLC was a completely isolated device, but by the mid-70s communications capabilities started to be added. Soon companies realized getting data from PLCs was necessary to monitor the efficiency and effectiveness of the plant floor. Furthermore, networking controllers together also helped optimize the safety and reliability of systems.
As companies grew, other systems often added and they required an interface with the existing systems. For example, if a new gas turbine is brought online at a compressor station, then the data from that new turbine needs to be monitored in the same location as the other turbines.
Now PLCs tend to have very long life spans; often 20 years or more. Many of the PLCs in use today have been in operation for at least a decade or more, and back then, memory and CPU horsepower was very limited compared to what is available today. So while the new PLC might have lots of spare CPU power, the original PLCs that control gas turbines noted earlier probably have just enough working memory to perform the control functions and barely enough storage space for their small operating systems. Adding new features, such as security, is a very tight fit.
Security No Concern 25 Years Ago
Twenty-five years ago, who thought of cyber security? At that time, the word security referred to a set of keys to lock or unlock the door to the control room in the oil refinery. There was no Stuxnet back then, in fact, at that time the Internet was just coming online.
The external world has changed immensely since then, but as I noted before, the PLC controlling the gas turbine is at least a decade old and is likely based on a design yet another decade older. And since no one knew about security 20 years ago, security was never designed into that PLC. Security was an afterthought or not even a thought at all.
The goal at the time was to provide the correct functionality to control various systems using that PLC. This goal was achieved and is now an integral cog in any control system. The other goal was to make interconnection as easy as possible. There is, however, a negative impact. This interconnectedness means it provides easier access for a hacker or virus to propagate a network. An unknown entry point in the office network may contain a long forgotten link to the plant floor.
Since I love utopian thought, let us imagine engineers 25 years ago were paranoid. Let us imagine they had envisioned the interconnectedness of their PLCs and had worried about security holes and hackers, and let us imagine they had decided to build security into the PLC as an integral part of its functionality.
This would involve doing things such as:
• Creating a risk analysis of their PLC during the design phase
• Examining all the methods of access to the PLC. These would include HTTP (web service), Telnet, Modbus etc.
• Thinking about “How could an enemy take advantage of this design?”
• In addition, a code review of the network stack used could illuminate memory usage problems or holes in the Modbus server design, for example.
Imagine how many attacks could have been mitigated, how many hours of downtime avoided, how much money saved if this kind of thinking had occurred.
Prepare for Secure Environment
While there is no silver bullet in security, there are at least ways to be prepared and lessen threats.
Flash forward to now. Now we are in the era of Stuxnet, Dragonfly, and the Ukrainian power outage.
What does this mean? It’s well past the time for vendors to take action.
Vendors, start putting code reviews, security analysis and risk assessments into practice. With the large increases in processor power and flash space in the last two decades, there is no excuse to not build a security layer into your current families of PLCs.
This forward thinking should become common place in the SCADA and ICS industry. Interconnectedness is not going away, nor is the threat of outside malware attacks or even inside actions of disgruntled employees.
The good news is automation vendors are taking this to heart, and standards groups, particularly ISA, have developed certifications that provide assurance that products have been securely designed.
Fixing a Device
The question arises then, what do I do with my old devices? These ideas about security are great for the PLCs designed and installed now, but what if I can’t retrofit my entire plant with new PLCs.
Rest assured there are ways to become more secure even with legacy devices. My recommendations are:
1. Become knowledgeable about ICS security and industry standards. You are already doing this as you are reading this article. Keep reading our articles and take advantage of the many presentations, white papers, articles and ideas this site has to offer. In terms of industry standards, no matter what industry you are in, I recommend that you become familiar with the key concepts in the ISA IEC 62443 standards (formerly called ANSI/ISA99 Standards).
2. Use ICS Specific Security Technology
Security technology exists today that:
• Protects legacy devices and systems
• Is installed in live systems without harm to production
• Can be implemented with no configuration required
• Is installable by field maintenance people
• Allows rules to be tested and changed without putting plant operations at risk
Erik Schweigert is a senior software engineer on Belden’s cyber security technology team. He has been a key creator of the Tofino Industrial Security Solution since 2007. Click here to view the entire blog.
Leave a Reply
You must be logged in to post a comment.