Throughout my whole life I was fascinated by industrial machines, automated production and process technology. In 2017 a customer asked whether we could "program a machine" for him, which I definitely confirmed. After discussing which technology to use for the main control system inside this machine, we agreed on a Siemens Simatic S7 PLC. I preferred to use an embedded system instead of a PLC but the customer insisted on Siemens products for his machine, so we implemented a "Siemens". (PLC programming was completely new for me at this time, but still now, I prefer embedded systems or embedded controllers over PLCs because they are not limited in their functionality.)
Anyhow, this article should not be about discussing weird programming-approaches of PLCs, it is about enhancing the security in your PLC programs and projects. The main advantage in PLC programming is, that it is quite easy to do. You can learn it relatively fast (it took me about 14 days from zero PLC knowledge until I started my first project) and you do not need any (advanced) knowledge in computer programming or network technology. This advantage is the main drawback as well, because by neglecting some fundamentals you normally learn from e.g. network security, you may put in some large security leaks into your PLC program. REMEMBER: The PLC will be used inside a machine which is most likely connected mechanically, physically, electronically (or in any other way) to other machines inside a production plant which can lead to severe consequences when a malicious attacker exploits or captures your PLC.
Therefore, I made a list with some recommendations I followed throughout my projects. The list is made and illustrated for Siemens Simatic PLCs and the TIA Portal but follows rather general recommendations and can therefore be used with other PLCs, IDEs and also non-PLC based projects:
- Sanitize and validate your sensor values, if the values are not in the given bound described by the physical process, notify the user:
- This is related to safety and security, sensors which are directly connected through analog inputs are less affected to be attacked.
- This rather addresses sensors which are connected via Ethernet (e.g. Profinet). Malicious data packets which are sent on Ethernet based bus systems can pretend to be sent from sensors which were actually replaced by a jamming transmitter.
Sanitize and validate values from communication partners, such as HMI Panels / partners on the same fieldbus / data requested from a ReST API, MQTT or OPC UA
- This basically addresses the same risk as described above: always sanitize data and check whether the received value is in bound described by the physical specification. Notify the user or throw an alarm if a given value is not inside a range given by the process specification.
- For example: Your PLC is used to control the speed of a motor, the set point is given from a communication partner, e.g. another PLC which is connected on the same Ethernet network. According to the process specification, the motor's speed has to stay between 350 rpm and 1000 rpm, less than 350 rpm and more than 1000 rpm is forbidden. Assume, your PLC now receives a set point which drives the motor at 1200 rpm. This puts the complete installation at risk, because the specification allows values between 350 and 1000 rpm only. The faulty value can have several reasons:
- a wrong implementation in your communication partner
- an attacker which pretends to be your communication partner, but sends wrong set points to induce a physical instable machine
- To prevent such scenarios, validate all externally given set points by checking them against the specification and notify the user if the set points are not in the given bound.
Define read/write protection for variables and data blocks in your project, do not expose internal variables to external read/write access
- The TIA portal allows to define the accessibility for every tag or variable inside a data block. You can decide whether this variable is readable from an OPC UA client (the Simatic S7-1500 has a build in OPC UA server), visible in the HMI engineering view or whether it is writable from the HMI or OPC UA client.
- Defining the variables appropriately can help to reduce the amount of data and therefore the "knowledge" which can be read from your PLC.
- Preventing write access to variables prevents (malicious) users from modifying set points or other values inside your PLC and during program execution.
Force authentication by username and password over SSL/TLS or authentication by X.509 certificates
- This is important if you enable for example the OPC UA server inside the S7-1500 CPU. OPC UA is often used to read process related data from the PLC. User authentication, data encryption and message signing is always important to keep the trust level high and to be compliant with the core pillars of information security: Confidentiality, Integrity, Availability (compare: https://www.owasp.org/index.php/Security_by_Design_Principles)
- If you collect process data from your PLC you want to ensure that nobody modified the values on its way into your data storage and you want to ensure that the data is from the PLC you requested. These aims can be ensured using cryptographic means, such as encryption and message signatures.
- User authentication ensures that only users with the appropriate permission can access your PLC.
Password protect your PLC for Online Access and Programming Access (TIA Portal nomenclature), to prevent unauthorized modifications or software versions to be installed on your PLC. Use strong passwords. - Keep as much of the control logic as possible in your PLC, even better: design your program that it can run headless (without a panel). Do not transfer any logic to an HMI or other partners, because they could be compromised or just pretend to be someone trustworthy.
- Log data and events either to a file on a storage media, to a network location or a centralized/decentralized logging server. Do not keep the logging solely in the PLC. This is helpful in case of accidents or forensics when something undesired happened and you need to find the cause of the failure.
As you might see, these principles are not very hard to implement and are also valid for other sectors, not for PLC programming only. I created a checklist which I check every time I release a new version. This ensures myself a reduction of security flaws and satisfies the customer.
