We will have a series of articles coming soon on the new Siemens S7 PLC security features, and I’m pleased to announce that Oliver Narr of Siemens will join representatives from GE, Rockwell Automation and Schneider Electric on our NextGen PLC Security panel at S4xEurope, June 9-10 in Vienna.
Consider this a bit of appetizer as last week Siemens announced their S7-1500 had been certified to meet the short term security requirements for a PLC as written in a French Protection Profile from l’Agence nationale de la sécurité des systèmes d’information (ANSSI). This is not a Protection Profile in the Common Criteria format, but it is the same principle. An organization writes a Security Target indicating how they meet the requirements of the Protection Profile. A third party, in this case Amossys, tests that the Security Target is accurate and complete.
The brief threat model importantly includes “Attacker on the supervision network: the attacker controls a device plugged on the supervision network of the TOE.” So the threat agent is inside the cyber security perimeter.
The amount of detail in the Protection Profile and Security Target is minimal and leaves a number of questions. For example,
Execution mode alteration: the attacker manages to modify the execution mode of the TOE without being authorized (a stop command for instance).
Integrity and authenticity of commands and PLC mode: The TOE must ensure that the execution mode of the TOE can only be modified by authorized users. This implies, in particular, that they are authenticated.
I believe this means that a user, which the Security Target also states “may be a device or a third-party software”, must have authenticated to the PLC before these commands are accepted. This is not the same rigor as authenticating the source and integrity of the command, and it’s potentially vulnerable to spoofing and man-in-the-middle attacks. Which relates to another security claim:
Secure authentication on administration interface: Session tokens are protected against hijack and replay. They have a short lifespan. The identity and the permissions of the user account are systematically checked before any privileged action.
The rigor of the security controls and the rigor of third party analysis is unclear from the documentation, but it may be well specified somewhere I have yet to see.
Still this is a positive step forward as the documents highlight key security controls for a PLC that are met to some degree. Some of the important security requirements in this Protection Profile include:
- Signed firmware and secure boot
- Proper handling of malformed input
- Secure credential and key storage on the PLC
You may have noticed the “short term” in the previous paragraph. There is another Protection Profile with medium term security requirements. This added features such as log and alarm integrity. Hopefully there will be a long term security requirements Protection Profile with an even more rigorous set of controls, particularly around authentication and recovery.
A number of other Level 1 device vendors participated in the Protection Profile development, e.g. Belden, Phoenix Contact, Schneider Electric, so it is likely other certifications will be coming shortly.