Members of the Top 20 Secure PLC Coding Practices project recently joined Claroty's Aperture podcast to discuss the group's list of top 20 secure coding practices for programmable logic controllers (PLCs). What follows is an edited transcript of our discussion with Martin Scheu of SWITCH-CERT and Dirk Rotermund of gefeba Engineering GmbH.
Claroty:
The list fills a real gap around cybersecurity for PLCs. I'm wondering what feedback has been like since the list was released in June?
Scheu:
I think the echo is spreading around the world. Last week, we met with some OT security [professionals] in New Zealand, and they are picking it up too. I think it's slowly spreading throughout. OT engineers like [the list], because security is innovative and missing in PLC programming.
Rotermund:
The top 20, for some people it's, it's like "fasten your seatbelt!" You drive your car and you [say], "I will not have an accident, so why shall I fasten my seatbelt." That's the problem with the Top 20 sometimes. Sometimes, you have to convince some people it's a good idea. We have a long way to go to establish in the minds of the people that secure coding is not given. It's not a gift. And so we have to learn it or you have to get that bias out of such a community project.
Claroty:
What prompted the project in the first place?
Scheu:
Jake Brodsky brought it up at S4 2020 for the first time that PLC programmers are kind of thrown into programming and are not really taught how they should program a PLC. With that initiative, the coding practices are a way to improve coding quality. Also, how PLC programming is taught might be different from country to country.
Claroty:
Who do you envision this list for? Is it for engineers on the shop floor? Is it for vendors? Who is a typical user of the list?
Scheu:
All [of those], plus the suppliers as well. Some parts could be integrated from the PLC suppliers or put in a function block, for example, and you can use it later on in your program. But of course, system integrators play a big role, because they are mostly the one programming it. Also the end user, the engineer running a PLC, needs to understand, because they might have a lot of PLCs already on the shop floor. So [engineers] could adopt some of these practices over time.
Rotermund:
[The list is] not only for the programmers. Years ago, PLC vendors didn't have the need to provide security, because nobody needed or wanted to pay for security. An exponential growth has happened in the last few years. But [vendors] started at zero, so now they have to provide many [cybersecurity] features. And we still have the older PLCs running on the market, and [securing them] is not the job of the vendors. This is the job of the asset owners to get these machines secure. And you only can do it by coding. This list is for everyone I think.
Claroty:
What has changed to elevate cybersecurity for PLCs as a priority?
Scheu:
Process control systems were connected all the time, but now they are connected to the business side of a factory. These connections went very fast. The OT asset lifecycle is 10-15 years, maybe longer, so everyone is thinking in these timeframes. What happened in the IT world with all the ransomware just came too fast. Now we're trying to catch up on the vendor side, the system integrator, and now the end user.
Claroty:
How much of an upheaval is it for a typical engineer on the shop floor to now have to consider cybersecurity?
Rotermund:
Some of our clients have no idea; they don't say they want [security]. You have to sell it to them. It's unbelievable. Asset owners don't ask for secure coding or security. I'm working with German water plants, and the government is telling them you have to do this. Other producing industries like steel don't really want it. It costs a lot, and they don't want to do this. You have to sell it, and that's a problem.
Claroty:
Do asset owners assume PLCs are already secure by design? Is that why they're not asking for security?
Rotermund:
I think the PLC is often a black box. The first thing the auditor asks: 'Is there Windows running on this box?' And if you say no, it's perhaps a Siemens or Rockwell or Honeywell machine, so there is no Windows, they say 'Okay, then we are not interested in this.' And there, you can see what way we have to go to get it in the minds of the people where the problems lie.
It's not only a Windows machine or Windows, PC, or network or internet connection or something, but we have the problems in the OT networks outside and in the PLCs, and you have to get it in the minds of the people.
Scheu:
Security was never really a requirement from the end user. Now maybe it's slowly starting to get there, but still in most purchase contracts, security is still not in. Or if you ask, based on IEC 62443, can you tell me something about open ports, the supplier has to check. It's still not there, it's still not in the everyday thinking of people involved in the industry, from purchasing to engineering services to end of life.
Claroty:
Are PLCs too dumb for security, and how would that contribute to them being insecure by design?
Scheu:
PLCs are not dumb, they're just different. If you have the black-box way of thinking, you might think, 'okay, the PLC is just doing one job,' but if you look closer, it is doing four jobs. It reads data from sensors, physical values, it has a processor, it has memory. And then, of course, it writes something to the output, to a motor, a pump, or whatever. And It also communicates with external components. So it does that in a deterministic way.
It's not as simple as one might think. It is a microprocessor, similar to a PC. And nowadays, you can have the PLC run on standard PC hardware as a soft PLC. So the differences are not that big anymore. If it's a soft PLC, [it would be easier to add security features]. Some PLCs run Linux and things like Docker on these devices; that might see a security increase, and also open new possibilities to use standard Linux software to do something bad.
Claroty:
What does a secure PLC look like? How do you securely program one?
Scheu:
The end result I would like is that the PLC is doing what I expect it to be doing, and it gives me the correct values of the process. Nowadays, there are [security] improvements. You can do a hash of your PLC program to check whether there was a change. Also, communication can be encrypted. The whole program can be encrypted, so you cannot just upload it, do some change, and download it again. But it all requires extra work.
Rotermund:
Turn off ports you don't need. Turn off a webserver on the CPU. Do clear and good programming. All those things together make it better and secure. But you can't do just one; it's like locking your door and leaving your window open. You have firewalls, switches, HMI encryption perhaps, but the PLC was completely open. And this is not working.
Claroty:
How can people use the list; it's structured in a certain way. Perhaps describe what's included in terms of detail and information.
Scheu:
There is a title and description of each practice, and the security objective and target group, whether it's the product supplier or asset owner. And then guidance examples, such as how to implement a practice. Also, why you should do it; it gives you more context. There is also how each practice [maps] to MITRE ATT&CK or ISA 62443. You have the top 20, but No. 1 is not more important than No. 20. Some of the practices are purely coding for the PLC engineer, but some also go more into quality control. For example, hashing the PLC program to check for changes.
Claroty:
What's missing from this one that should be on the next top 20?
Rotermund:
I think this list has to work now. We need help with the community, with people who have different points of use and give power to the community project then find new topics that are important for the community. It is not my list, it's our list and we have to see where we can get better.
Scheu:
What is important for me is local adoption and translation into local languages. For example, we translated in German, which makes it easier and accessible for engineers here who would have had to read the English document and while they might be able to read it, it's still not the same.
Also, I think each industry has a bit of a different way of programming. If you program a single PLC, you do it a different way than if you have a large refinery with thousands of input-outputs, from hundreds of PLCs.
Like Dirk said, let's start to use them and implement them, and when we have all 20 implemented, we will do the next list.
