SCADA Security Basics: Insecure PLCs

Wednesday, September 12, 2012 @ 08:09 PM gHale


Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.

By Erik Schweigert
Last week Eric Byres addressed the difference between SCADA, ICS and other jargon in our industry. This week I am going to address a question I am often asked “Why are industrial networks so hard to secure?” This is a big topic, so today I will address only “Why are PLCs so Insecure?”

Historically speaking, PLCs (programmable logic controllers) have been around since the early 1960s. The PLC started came into play shortly after the microprocessor was invented, 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 is a difficult task, especially since failures had the annoying tendency to happen at 3 a.m.

RELATED STORIES
SCADA Security Basics: Terminology
ISASecure Means More Security
Flaw in Air Gap Philosophy
ICS, SCADA Myth: Protection by Firewalls

The ICS (industrial control system) industry covers quite a bit of ground: Power generation and transmission, water/waste water systems, oil and gas pipelines and manufacturing, to name a few. PLCs were initially concentrated in the manufacturing sector, but soon they migrated to application in most industries. For example, they were quickly 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-70’s communications capabilities started to add in. Soon companies realized getting data from PLCs was necessary to monitor the efficiency and effectiveness of the plant floor. Furthermore, networking controllers together also can optimize the safety and reliability of systems.

And as companies grow, other systems often added and they are required to 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 horse power 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 the 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.

Twenty 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 is 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.

Let us imagine for a moment engineers 20 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.

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, Duqu, and Gauss.

What does this mean? Now is 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 provide 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 question arises then, what do I do with my old devices? These ideas about security are great for the PLCs being designed now, but I cannot retrofit my entire plant with new PLCs.

Rest assured there are ways to become more secure even with legacy devices. My recommendations are:
• Become knowledgeable about ICS security and industry standards. In terms of industry standards, no matter what industry you are in become familiar with the key concepts in the ISA/IEC 62443 standards (formerly called ANSI/ISA-99 Standards).
• Use ICS Specific Security Technology

Security technology exists today that can be installed in live systems without harm to production, with no configuration required, that can be installed by field maintenance people, that allow rules to be tested and changed without putting plant operations at risk etc.
Erik Schweigert, BSc, is an embedded systems developer, at Tofino Security. Click here to read the full version of the Practical SCADA Security blog.



One Response to “SCADA Security Basics: Insecure PLCs”

  1. dgunderud says:

    The ISA/IEC standards should be 62443 (not 62433)


Leave a Reply

You must be logged in to post a comment.