What is being done to protect the malware-vulnerable programmable memory of the PLCs of critical facilities? Anything?
It is possible to program a PLC memory and then program a lockdown so the memory becomes write-once rather than write-always, and thus would be immune to malware attacks.
Because, for example, nuclear power plants, hydroelectric dams and pipeline systems, are essentially steady-state in operation, then a write-once memory would have to be differently programmed to effect a change in the operation of the machinery controlled by the PLC. Thus, a technician from the control room would take the new memory down to the PLC.
The PLC could, for security, have a locked, hinged cover over its memory socket. There would be a programmed shutdown of the PLC's controlled machinery and the first memory would be removed, to be taken back to the control room for storage for possible future use. The new memory would be inserted into the socket, checksummed for identity by the control Rroom operator, and the machinery would be restarted, now operated by the new memory in the PLC.
Protections must be twofold:
- Protect the physical access port for programming. This means placing the PLC is a locked cabinet or location, with control over who can access the programming port. This doesn't prevent all errors, for example, the programming PC may itself be compromised, as with the Stuxnet attack. If you are worried about that level of threat (considered the highest level of threat), then only allow dedicated PCs to be used for programming.
- Protect the network access to the PLC. Most programming packages have network access, and many PLCs allow network access to change values in programmable memory (through OPC, OPC-UA, ProfiNet, DeviceNet, etc.). To protect against outside network access (assuming you have taken the steps to protect the programming and HMI devices), you must set up a layered defense on zones and conduits. (See ISA/IEC 64223, Requirements for IACS Security Management.) Only allow direct access to the PLC from a secure zone. The security rules on the conduits should not allow direct access to the PLC, but should go through a proxy that checks that the access is valid and within limits. There are also physical devices that you can place on the PLC network port that act as an individualized firewall for the PLC. However, remember that sophisticated threats will appear as valid commands, so the primary protection is to use only approved devices within a zone, setup a DMZ between your externally available business network and your control networks, use the best practices for patch management, and setup a canary system in the zone to check if it is compromised.
You can lock the code using a password on many PLCs (Simatic S7, Rockwell,...). However, this can be bypassed if the password is known. You can even uncode the program code so it can't be read and reverse engineered. It sounds to me like you need a non-networked PLC, or one that only publishes information and does not allow any writes at all. The other elements would require a very specific PLC and additional hardware.
If you use the same protection on everything, then on average you are providing either too much protection or too little. To determine what to protect, you should inventory the systems to determine what needs to be protected, inventory the data to determine what needs to be protected, and determine the value of the process, product or information (actual “accountable” value).
Lastly, remember that engaged employees are the best protection. Employees are the weakest link in industrial security, so they need to be trained, tested and engaged to protect their systems.
I call this gross overkill. I suppose that the NRC might ask for something like this, but I say, just don't connect to the Internet. From what event is this cumbersome procedure protecting?
Many PLCs no longer have removable program memory boards. What then?
I know of nothing being done to protect real PLCs from malware or any other security attack. These PLCs do not use commercial operating systems and attack from Internet sources is extremely unlikely. Rarely are real PLCs connected to the Internet in any way. However, there are two situations in which such attack is possible for PLCs:
- PLCs may be implemented on industrial PCs using commercial PLC software to implement IEC 61131-3 programming languages. These PC/PLCs may be connected to the Internet and are subject to malware attack, but can be protected using conventional PC antimalware, antivirus software, and the use of firewall protection from any unauthorized access via the plant network.
- As was proven by the Stuxnet attack on the centrifuge controllers at the uranium enrichment process in Iran, malware was installed at the Siemens PLC manufacturing plant by covert means without Internet connection. Deep knowledge of the Siemens software was required to create and install this malware as well as covert access to the Siemens plant in Karlsruhe, Germany.
The material listed below is recommended for further reading concerning both the attack mechanisms and the potential safeguards. These recommendations were made by Alex (Alejandro) Varga, Dennis Brandl, Hiten A. Dalal and myself:
- Creating a weapon of mass disruption: Attacking Programmable Logic Controllers
- On dynamic malware payloads aimed at Programmable Logic Controllers
- GE's approach to cybersecurity
- Process Explorer + VirusTotal (to check all processes with 50+ AV's)
- If you cannot afford an Einstein to protect the network, try a canary
- How can you activate the protection level with a password in the HW Config for an S7 CPU?
- www.bedrockautomation.com offers a very secure controller (but also very expensive), designed from the ground up to be secure.