Question – Can a PLC or other field device be certified as secure if lack of basic authentication allows an attacker to control a process and compromise the integrity of the PLC?
Between Dillon’s S7 work, Ruben’s recent Modicon post and all the effort around our Basecamp project, I’ve been thinking a lot about PLC and field device security. “Everyone knows” these devices are insecure by design and a large percentage of them have quite embarrassing vulnerabilities.
On the other hand we have a worthy effort by ISASecure to certify field devices with their Embedded Device Security Assurance (EDSA) certification. If you are not familiar with this you can read our reviews and news on the certification and listen to a podcast we had on the topic. An embedded device must pass three different testing regimes to be certified:
- Functional Security Assessment (FSA) – A list of security controls in the embedded device
- Software Development Security Assurance (SDSA) – An audit of the vendors software development lifecycle at various levels of rigor
- Communication Robustness Testing (CRT) – Essentially fuzzing the device to insure the protocol stack works properly
The CRT is a follow on to the earlier Wurldtech Achilles testing and is quite valuable because many embedded devices still crash when unexpected data is sent to the interface. This is where the classic advice, “don’t scan an ICS because it can crash” comes from. A robust protocol stack will prevent outages unrelated to an attack.
The FSA is the key document to read to understand exactly what security controls an EDSA certified device has, and it is important to understand that certification is available at three levels of rigor. Level 1, the lowest level of certification, does not require any “Integrity of Data in Transit”. So write commands to change the process are accepted from anyone, including an attacker, who can send them to the PLC. Many PLC’s have function codes that upload logic and make PLC configuration changes. These could be accepted without source or data authentication in a Level 1 certified device.
Level 1 certification does require the capability for at least one account and a reasonable password protection policy, but it does not have requirements for what actions require a login. We will show in Basecamp examples where an account actually offers little protection because it is not needed to cause significant damage to the process or PLC integrity.
To its credit, FSA Levels 2 and 3 do require data integrity security measures for data in transit and at rest, and they introduce requirements for Role Based Access Control and Least Privilege. However as I read it there still is no requirement for security on ICS protocol authentication, and this seems to be confirmed by a Modbus TCP device receiving Level 2 Certification.
Eric Byres and others have been saying that owner/operators must demand security for vendors to see the business case for adding the cost of security into products. We concur, … but consider the information sources and information that owner/operators are getting. The number one information source is the vendor themselves, and many if not most are doing a security tap dance (proactive holistic response). The number two information source is the automation press who has chosen self interest to not offend their advertisers. A third source would be an industry standards and certification body such as ISASecure. A reasonable owner/operator hearing that a PLC has achieved ISASecure EDSA certification would be inclined to think they are buying a device with at least basic security.
The perfect should not be the enemy of the good, which is why I’m conflicted on ISASecure’s EDSA. A device that has passed even Level 1 CRT is much more robust than a typical field device. But the last thing that should happen is owner/operators believe a Level 1 certified PLC provides even basic protection against an attacker who has logical access to the PLC. Should there be a big red stamp on the each Level 1 certificate that says: Device Has No Security To Prevent Misuse Or Attacks On The Process or something similar?
ISASecure should continue their good work on this program, but they need more and better information on their site about what products are certified, to what level, and what this means and doesn’t mean. It is not that ISASecure is hiding this info; the detail and specs are all there in technical specifications. Time for ISASecure to focus on marketing and education with some of the sponsors’ dollars.
Image by -Tripp-