Rebuttal – Part 1 Features and Functionality

Insecure By DesignJake Brodsky and Joel Langill had comments in a blog post late last year, CoDeSys IDS Signatures Easily Avoided, stating that is unfair or wrong to focus on an insecure by design PLC issue. They believe we should be focusing on the overall system security and insuring this reduces risk to an acceptable level (my hopefully fair¬†synopsis, read their comments). This approach is terribly wrong for two reasons, and I’ll address the first today.

Key Point: Do you want the insecure by design feature? then the attacker gets it too.

The crux of Project Basecamp is that almost all PLCs/controllers are insecure by design. The most important deficiency that needs to be addressed is they lack source and data authentication for even the most important requests or commands. An attacker with logical access can upload new firmware, modify ladder or application logic, issue write commands to modify the process. An attacker that can reach a PLC can completely compromise the availability and integrity of the process being monitored and controlled.

Reid’s CoDeSys “attacks” are a good example, but only one of many in Project Basecamp that showed similar issues with GE, Koyo, Schneider Electric, Rockwell Automation (see the S4 video), … Reid simply monitored legitimate commands from the HMI/Engineering Workstation and put those into a script. These commands could upload and download files to the PLC, amongst a wide variety of other things.

The only way to stop these attacks is to prevent legitimate use of the insecure by design feature, and most owner/operators will not accept. In fact taking away these insecure by design features introduces risk related to responding to operational issues, especially in geographically dispersed SCADA networks.

There is a simple and practical example of this. Most PLCs used to, and many still have, a physical key with a variety of position such as Run, Rem (Remote), and Prog (Program) as seen in the picture. The generic idea is when the keyswitch is Run mode the ladder or application logic cannot be changed. However it is very helpful to be able to change the logic in a remote PLC for troubleshooting a problem, and it costs $ and may be logistically difficult to send an employee out to insert and turn the physical key to a position that allows remote logic changes.

The owner/operator must make a decision.

  1. He can leave the PLC physical key switch in Run mode (even removing the physical key) and prevent remote changes in logic from good guys and bad guys.
  2. He can leave the PLC physical key switch in Remote mode (or other mode that allows remote programming) and allow good guys and bad guys that can access the device to be able to change the logic.

This issue extends to even basic items like write requests that cause things to turn on/off, increase speed, raise temperature, … Today you either allow everyone with logical access to issue these commands (good guys and bad guys) or block these requests for everyone with something like a Tofino Read Only Firewall.

Compensating Controls and Overall System Security

It is a common misconception that Digital Bond’s focus on the insecure by design protocols and field devices means we are anti-compensating controls or implementing any administrative and technical security controls. Most of our consulting involves analyzing just that. We even provide a prioritized list of what actions to take in the next 0-6 months and 6-18 months to most efficiently reduce risk. My guess is a lot of this is very similar to what Joel teaches in his class — that I hear is quite good.

Unfortunately we also have to tell owner/operator clients that if an attacker gets to the PLC’s it’s game over. It’s a staple in every report along with a recommendation to plan to replace these devices in the next 1-3 years. We selected the 1-3 year time frame because it is the average time frame, not expedited, for PLC replacement projects to roll out to the field sites in our experience.

The real crime is many owner/operators who are leaders in ICS security have replaced their PLCs in the last ten years with brand new, insecure by design models. Our first SCADA client we worked with in 2000, replaced their PLC’s in 2009. Much to their chagrin they were stuck choosing between insecure by design models. The ICS community keeps digging ourselves deeper into ICS insecure by design pit. The first step is to admit and get consensus that it actually is a problem that needs to be addressed by the critical infrastructure SCADA and DCS in the near term.

6 comments to Rebuttal – Part 1 Features and Functionality

  • I can tell you that most people on the plant floor are not IT security experts. If you talk about digital signatures or permissions for this or that I/O, you will get a dirty look and a question of “how can we disable this in an emergency?” If you don’t have an answer handy, that gear will not see service. And of course, as soon as you tell them how to do this, you will find the gear configured like that all the time. It’s human nature.

    I have difficulty selling this even within our own staff, even with support from three levels of management.

    The problem is that we can’t validate our I/O enough to keep a malicious person from doing damage. For example, we might consider limiting the number of pumps running at once in a water pumping station. But sometimes, during a pipe break, we might actually need to run everything we’ve got full tilt. If the operator has to play 21 questions with the PLC to get everything running, I will be doing a carpet dance in front of the Directors of Production and Engineering.

    There are some very basic things that we can do that will make things safer, but knowledgeable malice will win every time.

    The reason for “Insecure by design” is because there really aren’t any alternatives. If someone is on the PLC network, game over. There is some latitude with SCADA, because it is not nearly as “real time” as a PLC. Yet even there it is not easy and denial of service is still potentially dangerous if done with appropriate coordination.

  • Sihoko

    @Jake fully agree with your and Joel’s statements and position, I have followed this same principle for years and addressed it several times in my comments at Digitalbond blogs.

    @Dale, the very essence of security is to protect the vulnerable and there is nothing wrong with this. This doesn’t mean that we shouldn’t improve the security capabilities of control systems, of course this is required but takes time. But even vulnerable equipment can be integrated into a secure overall system.

    All the time invested on finding vulnerabilities in equipment, which we know is vulnerable, is a waste of time if not driven by the goal to improve this equipment. It leads to a false picture of vulnerable equipment because the results are primarily determined by the accessibility of this equipment for testing. So far the majority of cases has only been used for business growth purposes frequently at the cost of ICS security. This site often followed a course of confrontation with vendors instead of recognizing that cooperation would be more beneficial to Digitalbond’s clients.

  • Darrell R. pitzer

    Can you list vendors and/or specific products that are secure by design?

  • Sihoko

    You find a list of ISAsecure tested / certified devices at their website.

  • Dale Peterson

    Darrell – I have not had any luck getting vendors to crow when they actually are authenticating source and data as well as other basic security measures. Still working on it, but there are a couple.

    Sihoko – The ISASecure Level 1 certified devices are still insecure by design. Main benefit of Level 1 is the protocol stack can withstand fuzzing. Level 2 is where the real functional security begins.

  • Sihoko

    @Dale, you are right but ISA secure certification also requires important changes to the design process, activities that were abset previously. So yes it doesn’t include all security functions yet, however the product design incorporates security from the very initial design steps.

Leave a Reply