Programmable Logic Controllers (PLCs) are often seen as one of the major reasons Industrial Control Systems are insecure. These devices -even today- are indeed crippled with critical vulnerabilities. Even worse, they have by design vulnerabilities, also known as forever-days.
While securing ICS is definitively possible even though we use very insecure devices, it is a legitimate worry and manufacturers need to step up their product security game.
French CSPN security certification process
The French National Cybersecurity Agency (ANSSI), amongst its activities, “is helping companies and government authorities make a choice, by qualifying and certifying security solutions.“. The goal is to make public or private companies make the right choice regarding cybersecurity when choosing a product or service provider (audits, incident detection, incident response).
I will focus on CSPN, which is a France-specific “first level” of cybersecurity, more simple to obtain than Common Criteria certification.
This process for products certification & qualification is detailed on the ANSSI website and is available for ICS protection, which includes PLCs:
I will not detail the qualification process here, but highlight a few points:
- The idea is not to evaluate the product in general, but to evaluate some of its features in specific conditions
- The qualification is based on two topics: the results of the technical evaluation of the product AND the trust in the manufacturer’s ability to maintain compliance with a set of requirements from ANSSI (confidential data management, management of vulnerabilities, …)
The importance of the ToE –Target of Evaluation
The ToE describes under which circumstances the product is certified. For example, it would not make sense to feel secure because you use a qualified firewall if you expose the management interface to the Internet and use a weak password.
Unfortunately, this topic is rarely correctly understood by clients and asset owners, as people frequently make the following shortcut: using a certified/qualified product means being secure. And this is totally understandable as it is a marketing strategy, and it carries an authoritative argument, from the ANSSI.
ANSSI also published some validated protection profiles, to serve as a basis to define the ToE. The protection profiles are defined for short-term and mid-term. The Protection Profile for PLC at short term is here: https://www.ssi.gouv.fr/uploads/2015/03/20150713_NP_ANSSI_SDE_plc_short_term_v1.1-en.pdf
Let’s take a quick look at the ToE for the two PLC ranges that have a CSPN certification: Siemens S7-1500 & Schneider M580.
Siemens
Siemens S7-1500 is CSPN certified since the end of 2017. The qualification was renewed for newer versions.
The ToE can be found here: https://www.ssi.gouv.fr/uploads/2017/10/anssi-cible-cspn-2017_26en.pdf. It complies with the “short term” protection profile published by the ANSSI.
The high-level network architecture is a basic one, and doesn’t take into account redundancy for example.
Moreover, only attacks coming from the supervision network are taken into consideration:
A very interesting point is that a new Siemens S7-1500, out of the box, is compliant with the Target of Evaluation. This doesn’t mean that it will always be secure, but a least you need to perform a configuration change to make it less secure.
Schneider
The Schneider M580 ToE can be found here: https://www.ssi.gouv.fr/uploads/2020/07/anssi-cible-cspn-2020_20en.pdf
The ToE refers to additional documents regarding the configuration of the PLC: https://www.se.com/us/en/download/document/EIO0000001999/
The target architecture relies on a CPU module, and 2 communications modules, each dedicated to a network: administration and SCADA.
A redundant architecture is also part of the possible target architectures, but attacks via the remote I/O network or the hot standby networks are out of scope.
The field network is also out of the scope of the ToE:
My understanding is that, contrary to Siemens, hardening actions need to be performed so that the M580 can comply with the ToE.
The way Schneider complied to the ToE was by adding IPSEC capabilities to the network modules for the M580. This solution is interesting because it probably has a limited impact on the codebase, since the IPSEC processing is probably done on the network cards. Moreover, IPSEC is a standard well integrated into Windows environments, so implementing it also has limited impact (if not none) on the codebase of the programming software and the SCADA applications. IPSEC can also provide authentication and integrity of the communications without encryption, which may improve detection capabilities in some environments.
IEC 62443 product certification
The international standard for ICS cybersecurity IEC 62443 includes a part dedicated to components security: EC 62443-4-2 Security for industrial automation and control systems Part 4-2: Technical security requirements for IACS components, as well as product development security: IEC 62443-4-1 Security for industrial automation and control systems Part 4-1: Secure product development requirements.
ISASecure CSA certification seems similar to the CSPN approach, but of course dedicated to IACS devices, while CSPN certification can be obtained for more types of devices or software.
Their goal is to provide a certification similar to SIL levels, but for cybersecurity. Let’s note that, as for cybersecurity, using a SIL-X capable device does not mean that the system using it is SIL-X.
The prerequisite to obtain the CSA certification is to have certification regarding the development lifecycle (SDLPA-C). In addition to this, the security of the product is assessed through:
Security Development Artifacts for components (SDA-C)
SDA-C
ensures a component was developed following a robust, secure development process compliant that standard, by examining development artifacts
To pass this requirement, you need to provide evidence (artifacts) that the secure development lifecycle was indeed applied for the specific component to be certified.
This includes quite technical artifacts, such as network load testing as well as fuzzing.
Functional Security Assessment for components (FSA-C)
This assessment verifies that the device has the right security features to comply with the Capability Security Level (SL-C) it is targeting. The SL-C define levels on 7 topics:
- FR1 – Identification and Authentication Control
- FR2 – Use Control
- FR3 – System Integrity
- FR4 – Data Confidentiality
- FR5 – Restricted Data Flow
- FR6 – Timely Response to Events
- FR7 – Resource Availability
This is very similar to the Protection Profile from the CSPN and Common Criteria certifications.
It is my understanding that the assessment is, as the name suggests, functional. It means that one verifies that the feature is available, but not if the feature could be defeated by an attacker.
Vulnerability Identification testing for components (VIT-C)
This is basically a Nessus scan on all available interfaces, and depending on the Capability Security Level (SL-C) you try to reach, the test must not reveal any critical, high or medium finding.
Good thing is that the vulnerability feed must be recent, and the scan must be performed with valid credentials if it makes sense for the product (which will go a bit deeper than just a vulnerability scan).
CSPN vs ISASecure CSA
The two certification schemes are quite different. Having a string SDLC is absolutely paramount to have secure products, this is why SDLPA-C & SDA-C are really interesting.
However, the technical part is limited to a Nessus scan, which will not be able to identify much vulnerabilities specific to the product assessed. In this area, the CSPN methodology is really more thorough: starts by clearly defining what you will evaluate (the ToE) then have highly skilled auditors test the product, as hackers and not checking boxes for security capabilities of the product. However, the CSPN qualification lacks public information on the SDLC evaluation, and is closely tied to the government, which might add subjects not related to cybersecurity into the decision.
In an ideal world, ISASecure evaluation with a clear ToE for the products and the technical tests performed in the CSPN certification would be a winning combo.
So, should I care about certifications for PLCs?
Security is often hard to sell. Certifications like CSPN & ISASecure CSA allow secure products to have a competitive advantage over insecure products. It is especially true for CSPN, as the process is oversight by a government agency.
While choosing a certified product will absolutely not ensure that it will have no vulnerabilities, it should give additional confidence in the product security. Getting a CSPN is a long process and requires commitment from the manufacturer.
When choosing a product, challenge the Target of Evaluation / tests conditions and understand the additional risks of the product in your environment:
Some possible attacks not considered in the Schneider & Siemens ToEs
– Could the attacker leverage UMAS/S7 requests from the field network to attack the PLC ?
– What is the real security level if you use remote I/Os and you cannot guarantee that the network is dedicated and secure?
Also, consider the limited technical testing of CSA:
Some possible vulnerabilities difficult to identify in CSA certification
– Using a proprietary, insecure protocol will not be detected by Nessus
– An undocumented, trivial admin password will probably not be identified by Nessus as it doesn’t know the product
Finally, as mentioned at the very beginning of this article, the security of Industrial Control Systems does not only rely on the security level of individual components. Improving the cybersecurity of your ICS is a long journey, that should probably not start with replacing the PLCs with newer, certified ones.
ICS cybersecurity academy 