Hopefully loyal readers now accept that we need to address the decade old problem of insecure and fragile PLC’s/RTU’s/field devices, and the Basecamp information and tools provide some additional compelling evidence and demonstrations to prove the point to senior management.
So what should you do? Part 1 covered what Owner/Operators should do with new projects. Part 2 covers what Owner/Operators should do with deployed projects.
SCADA and DCS Owner / Operators
Deployed Projects
To be honest, the difficulty and cost of this problem is one of the main reasons that little progress has been made in PLC security over the last decade. These devices control and monitor processes that must run 24 x 7 x 365 so it is difficult to pull one out of service for an hour, day or week. And while servers and workstations in ICS have redundancy that helps with upgrades and patching, there is less redundancy deployed for field devices.
But let’s also be honest that PLC’s can be upgraded or replaced in a critical infrastructure SCADA or DCS. It doesn’t happen often, but there are PLC refresh projects going on right now in most sectors. Engineers know how to do this; it’s only a question of the facing the problem, prioritization, and willingness to spend the time and money to do it — if they can find a vendor who will offer a secure and robust replacement or upgrade.
When are you scheduled to replace your PLC’s?
If your PLC’s have a remaining lifetime of less than three years, you are probably already beginning a project to replace them and focus on that, see Part 1.
If your PLC’s have a remaining lifetime of 3 – 7 years (numbers picked a bit arbitrarily) you should consider accelerating the replacement program to 3 years, see Part 1. This is where senior management should earn their money and make the hard decision as to whether to accept the demonstrated risk or accelerate the replacement and absorb the costs of reducing the expected lifetime. The key here is for the engineer and security professional to not be a hero.
It’s natural to be a problem solver and say “if we put all these security controls, defense in depth, it will be harder for an attacker to reach these vulnerable and fragile PLC’s”. This is true, but be very clear that it only reduces risk and an attacker who can reach the PLC’s will affect the integrity and availability of the PLC with potentially catastrophic results. The defense in depth principle is being abused. It was never meant to result in ignoring the weak link in your security chain. The solution is to strengthen the weak link, not ignore it.
If your PLC’s have a remaining lifetime of seven years or more you should determine if the vendor has an acceptable upgrade plan you can implement in the next 3 years, see below.
Why the focus on three years? Sooner would of course be better, and if your organization can speed the process along than it should be done. However this is a major engineering project and there is risk to the process if the upgrades are done improperly. Engineers can handle this work, but it actually could increase risk if they do not have the time to perform the testing, phased deployment, roll back options, etc. It is fine if the organization says it will take one year, two years or four years rather than three, if the associated risk is accepted by senior management. The important point is to finally start addressing this problem.
What is the upgrade or replacement product?
Start with your existing vendor, if you are happy with their product. It’s time to find out what they are going to do to upgrade the product to a secure and robust PLC. As mentioned in Part 1, focus first on source and content authentication and protocol stack robustness testing, but also query them on their intention to meet the ISASecure or other embedded device security standards that include functional requirements, protocol stack robustness and the vendor’s security development lifecycle. The questions:
- When will you have a security upgrade to the PLC and what does that security upgrade provide?
- How is the security upgrade performed? (eg Ethernet board replacement or firmware upgrade)
- What is the cost?
If the answers are unavailable or unacceptable issue a Request For Information (RFI) to look for alternatives.
Owner/operators should also open up the PLC and look at where it stands in terms of hardware and software obsolescence. It may not make sense to upgrade an ancient system that will be even more obsolete five years from now; in these cases you should accelerate replacement.
Next the owner/operator should look at the level of internal effort to upgrade the PLC and compare that to replacing the PLC? The product cost of the PLC is often actually not the major cost in a deployment.
With all this information the owner/operator needs to determine if the existing product should be upgraded or replaced, and we recommend focusing on a maximum three year window to address the problem.
All the risk and cost information then must be placed in front of senior management. Get the clear decision on the record. One reason the PLC fragility and insecurity problem has not been addressed is senior management has been able to sidestep accepting the risk. Is a senior manager in an owner/operator going to allow a novice hacker or simple malware to bring the entire process down or an advanced attacker to perform a more sophisticated, Stuxnet type attack?
One last thought, Siemens marketing response to Stuxnet has greatly retarded progress. When Siemens lead engineers and C-level executives state that all Stuxnet vulnerabilities have been addressed, then C-level executives in owner/operator companies exhale. Your job as an engineer and security professional is to correct this falsehood and let your C-level executives understand the risk.
If this all seems like common sense advice, it is.