SCADA Security Basics: Why are PLCs so Insecure?
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?”
The History of PLCs
Historically speaking, PLCs (programmable logic controllers) have been around since the early 1960s. The PLC started to be used 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 3am!
Before PLCs racks of relays, like the ones shown above (circa 1965), controlled industrial automation systems. Source: XL Technology Systems.
As you know, the ICS (industrial control system) industry covers a lot 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 applications 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 be added. Soon companies realized that 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 are 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!
A natural gas compressor station like this would have many PLCs controlling and managing the safety of both the prime movers and compressors.
Cyber Security was not a Concern Twenty Years Ago
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.
Imagine if Cyber Security was Addressed Twenty Years Ago
Since I love utopian thought, let us imagine that the engineers twenty 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!
Vendors need to include Security in Product Design and Development
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.
If there are no Silver Bullets, what is an Operator to Do?
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
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 etc. 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/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. Of course I recommend the Tofino Industrial Security Solution, our own product, but you are welcome to look at others.
What is your ideal scenario for ensuring plant security? How much do you expect the vendors to do, and how much do you think needs to be done at the operator’s initiative? I look forward to hearing from you.
|
Erik Schweigert, BSc Erik is the lead embedded systems developer at Tofino Security. |
Practical SCADA Security thanks Erik for this article.
Related Content to Download
|
Case Study
|
Related Links
- Blog: SCADA Security Basics: SCADA vs.ICS Terminology
- Blog: Use Purchasing Decisions to Demand better ICS Security
- Blog: SCADA Security and the Broken Business Model for Software Testing
- Blog: Defense in Depth is Key to SCADA Security – Part 1 of 2
- Blog: Defense in Depth: Layering Multiple Defenses – Part 2 of 2
- Blog: Securing SCADA systems from APTs like Flame and Stuxnet – Part 1 of 2 (Ed. Note: Applicable if you are looking for advanced security practices)
- Blog: Securing SCADA systems from APTs like Flame and Stuxnet – Part 2 of 2
Comments
What About The Last 11 Years?
Erik,
The father of your Tofino firewall was showing that PLC's were insecure by design, and he could turn lights on and off at least 9 years ago at conferences. There really is no excuse for a vendor's state of the art PLC being sold today lacking basic security functionality.
Are we going to accept living with this problem for another ten or twenty years, or until something really bad happens.
I would add to your recommendations for an operator:
- Tell your PLC/RTU/Controller vendor that you are going to upgrade to a secure device in the next 1 - 3 years.
- Ask them what their secure upgrade or new product plan is for that timeframe --- and yes a Tofino card could be part of that solution, but an industrial firewall isn't going to handle the authentication of valid comms allowed through the firewall.
- Start budgeting for a project to do this.
Dale Peterson
Digital Bond
What About The Last 11 Years?
Thank you Dale,
If history is any indication it appears that the industry may be accepting this lack of security. In some cases it may be ‘cheaper’ to accept a security failure than redesign a network and add in security. While I cringe at that thought there have been many indications it is true.
If customers do not care/worry/require security than a PLC vendor is not forced into providing it. If you as a vendor can save time and money to get that PLC to market while trading security because a customer does not require it, then as we have seen, this is what will happen.
If customers begin to realize that security is important and that added costs upfront will save plant downtime or plant failures in the future then I think vendors will be forced into providing security as a core component.
Excellent recommendations as well!
Paranoia and sustainable security
Interesting thought and yes, utopian. While it is entertaining to dream of a perfect world, we don't live in such. And as engineers, a big part of our profession is to account for errors and unforeseen events in our designs by building in resilience. However, that type of thinking is not as rigorously embedded in software engineering education as it is in e.g. civil engineering education.
So let's assume a more realistic case - PLCs developers twenty years back were paranoid and built-in state-of-the-art security when designing PLCs. Where would we be today? Be reminded, 20 years ago the few web servers available were not using SSL - that saw its first public release in 1995. Remote access to computers was basically done on Unix (no, not Linux, in 1992 Linus was still working on version 0.01 of the Linux kernel) and it was done using Telnet. State-of-the-art user password storage would have been the shadow file of Unix (introduced 1988). And let's assume that the PLC developers who followed them in the coming years did the same and built their newer versions and newer generations of products according to the then-current state-of-the-art.
Where would that leave the installed base of those PLCs today? Probably the installed base would be more heterogeneous in terms of security posture. Also, the installed base would be far less interoperable, as the current version most likely would not be able to support the mandatory security features of the next but one version - let alone the next generation.
And of course, not ignoring the economics, somebody would have had to ban the non-paranoid developers from simply going the route that developers actually took and skip the entire effort of security for cost savings, time to market, interoperability, you name it. Otherwise the paranoid developers' companies went bust 19 years ago.
So, what is my take-away here? A well-known mantra, which is quite in-line with your final conclusion. There is a lot to learn from the IT Security industry, but we still need the industrial control system expertise and experience to properly transform the IT Security approaches and technologies to the industrial world. The lifecycle differences are one major topic in that transformation. And I would rather rephrase your second recommendation: it's not only the technology that needs to be ICS specific, it's just as much the approaches and concepts in development, engineering and operations which have to be ICS specific.
Paranoia and sustainable security
Thank you Ragnar,
You make an excellent point about the Engineers using the 'best' security technologies of the time. I suppose a large problem is that the security technologies are constantly improving but the PLC systems do not necessarily evolve at the same pace, especially with so many external forces affecting the PLC development such as the economics, time to market, etc.
I think with the advent of Stuxnet and its children the awareness of security holes and vulnerabilities are finally coming to the forefront of people’s thoughts. The challenge now is to mold the IT security practices, as you mentioned, to that of the ICS world rather than simply copying a paradigm from IT and overlaying it onto the ICS.
looking back doesn't work
My take... if ICS exploits existed 20 years ago you can bet it would have been the ICS industry that lead the way in secure protocols. Secure methods existed, they just weren't wrapped into a product. To try to predict what would have happened if then current IT practices were in place is pointless because the security requirements for IT are and always will be different than those for ICS.
This issue assumes that security can be isolated into a product, that PLCs can be made secure. Security is not like that. It is not bound by a subsystem. No matter how much the need to limit security issues to a manageable size, it is not possible. All you can do is change the probability profile, which if you believe in quantified security, can give you a sense of security -- without actually achieving it.
Targeted exploits exist outside the probability profile and so every system is capable of being exploited. Making PLCs more secure just means they'll be compromised by experts instead of the 12 year old cracker. Whether your ICS is compromised or not is dependant on the value of your system to the attacker.
This is where ICS failed 40 years ago. First of all it didn't foresee who its adversary was and by consequence it did't predict the value of its controlled systems to that adversary. So again it's pointless looking back. This failure was not a mistake of the ICS industry, there simply was no adversary to identify.
ISA/IEC standards
The blog lists it as 62433. It should be 62443.
ISA / IEC standards
Dan, you are right. Thanks for pointing out the typo. We have corrected it to ISA /IEC 62443 now.
What About the EndPoints?
Mr. Schweigert,
I commend you on your analysis, and perhaps more importantly, on your presentation that in my opinion provides your audience clarity and comprehension to what amounts to better-assured secure control communications of industrial infrastrasture, the solution to which involves solving (or at least mitigating) complex industrial, systems, and electrical, as well as computer (i.e., cyber) engineering issues.
But isn't it also the case that, while I heartily/enthusiastically agree with my fellow commenters here, that in order to really get at these problems, that we resolve together at-last that we really aren't dickering with each other over which one of the several engineering -area issues ought to receive more or less attention, but rather instead that, at least with respect to the topic of securing SCADA communications, the heart of the matter that needs to be discussed is really instead this "three-headed Hydra/Monster":
1. Legacy ICS and related SCADA architectural design(s) assumed trusted environment(s) (i.e., “closed trust model”). Meaning that legacy SCADA control devices require no authentication from any device issuing a command proving it is allowed to do so. Therefore such devices "blindly accept" any command from any device (assuming properly-structuring and placement of said-command, etcetera) ;
2. IT and Industrial systems, technology and cyber security standards, protocols and best-practices usually (i.e., mostly/majority) only work with / analyze / protect SCADA Master Control (or HMI) “frontends” ;
3. ...and even assuming resulting-effectiveness of 2., isn't almost the entirety of every given SCADA systems’ functionality/activities, constituted via legacy “endpoint” (usu. PLCs, poss. RTUs) SCADA control devices?
I look forward to your / anyone's response.
Phil Sagle
GMU Graduate Certificate Student, Information Systems Security (Jan 2010)
What About the EndPoints?
You bring up some good points Mr. Sagle. I think your points in #1 and #3 help reiterate my suggestions to upgrade your system(s) and to push vendors with the idea of security as a core feature in new PLCs as well as HMI software. That would, at least, be a step in the right direction.
It is true; there is no one single solution due in part to the various elements that an ICS network consists of. That is why, in part, there are various ways to mitigate attacks and help protect a network, unfortunately, there is no single silver bullet.
PLCs
I've done some work in this field but only on a smaller scale. I can only imagine the headaches involved with trying to deal with some of the concerns that arise here. This dialogue is rich and productive for the industry.
Add new comment