More Project Basecamp modules and tools have been released today. The Basecamp reaction has been predictable and disappointing at the same time. The initial furor is over the disclosure, and there continues to be very little anger over the fragility and insecurity that has been allowed to live in the critical infrastructure for more than a decade — and for the foreseeable future if nothing changes.
Almost all of the guidance from SCADA security guru’s has been focused on compensating security controls. The same controls that have been preached over the last five years, including on our site. It’s not wrong, but it’s not what is needed to finally make some progress of PLC security and robustness. Here are our recommendations:
SCADA and DCS Owner / Operators
ICS have lifetimes measured in decades, so don’t make a huge mistake that will leave you with a fragile and insecure system for the next twenty years.
Stop. Demand the vendor provide you with a secure PLC/RTU or a clear upgrade path to a secure PLC/RTU. What is a secure PLC/RTU? Well there are a few sources for this such as our Field Device Protection Profile that we wrote under contract for NIST or the ISASecure Functional Security Assessment (at least level 2). We will have more on this later because it is an important question, but if you need something today you should focus on these two requirements:
- Authentication of the source and content for functions that could affect the process. This is required to provide process integrity and availability. Items like session initiation, changing ladder logic, changing firmware, stop cpu, change IP address, add user, change authorization, etc. need to authenticate the source and that the data has not been modified in transit before implementing the function or request. Add write commands to this list as a requirement and consider the performance impact of implementing this feature.
- Protocol stack robustness – A test similar to Achilles or the ISASecure EDSA to insure the PLC/RTU does not fail when scanned, fuzzed or receives unexpected data. This is required to provide process availability.
Very few PLC/RTU vendors offer this today, as seen in the Project Basecamp results. So you need to get the vendor committed to fixing protocol stack robustness issues and adding the authentication features. The upgrade path should be clearly defined in terms of when it will be available, the upgrade process (such as a software upgrade or replacing the Ethernet card), and the cost.
With this information the organization can decide if it can continue with the project or if it needs to be modified or even halted. I can hear the engineers and project managers out their groaning that this is unrealistic and would not be accepted by senior management. But this is a risk decision that you need to put in front of senior management. Let’s look at this with some Basecamp examples.
This is an easy decision. The device is a dead end with 80’s/90’s technology that can’t be fixed. You are looking at a major upgrade and probably total replacement of the RTU to achieve even the basic availability and integrity requirements. Full stop on this project.
I’m not saying don’t buy from GE. Go back and ask them what else they have because you can’t deploy a fragile and insecure RTU with obsolete software and hardware on a new project with a planned lifetime of 20 years.
Rockwell Automation ControlLogix
A more interesting case because the product is potentially upgradeable. Time to have a forthright discussion with the vendor. When are they going to fix the Basecamp problems, prove protocol stack robustness, and offer source and content authentication?
This is not necessarily easy for the vendor because some of the issues, such as unauthenticated commands like CPU Stop, are part of the EtherNet/IP protocol under control of the ODVA (yet another post that needs to be written on delinquency of protocol organizations to begin adding security ten years after 9/11). There are solutions like tunnels and wrappers that can be vendor specific, but don’t try to solve the problem for the vendor. Instead, evaluate their solution.
Again, what is the timeframe, upgrade process, and cost when this basic PLC security will be available in the product you are planning to deploy? If there is not an acceptable answer to this question, stop.
Senior Management Decision
Put this information before the appropriate level of senior management and get their decision. Too often engineers and security professionals accept risk that they have no business accepting. This is not only wrong for the organization, but its a terrible career risk when something bad happens. Accepting this fragility and insecurity puts the entire process at risk. This is a huge financial, safety and company reputation risk. Who in your organization can say the company will accept that risk?
There’s no excuse anymore for not understanding the risk. If your project has a ControlLogix in the design, you now have a Metasploit module that will show how easy it is for an attacker with logical access to take the system offline. If you have a Koyo, GE D20 or Modicon Quantum you now have a Metasploit module that shows how easy it is for an attacker to gain the credentials that allow them to affect the integrity of the process in a dumb or intelligent manner. And Siemens and most, but not all, of the other field devices or controllers have the same problem.
Make sure that senior management understands that if an attacker is able to gain logical access to the field device they will take the controller and process down or worse modify it in a more clever manner (a la Stuxnet). And I would caution engineers and security professionals against professing that this access is not possible even if you are following defense in depth recommendations. There are too many examples and paths to gain logical access.
At the risk of repetition, how can an engineer, security professional or senior manager accept this level of fragility and insecurity in a new system for the next twenty years? Don’t do it. At a minimum demand a committed upgrade path before you lock in these problems.
Coming Up: Part II – Existing Projects and Vendors and Part III – Government and Standards Organizations
Image by K. Reid Wightman