This is the fourth in a series of articles on security features in the next generation of PLC’s that will mark the end of Insecure By Design. A panel at S4xEurope will highlight Secure PLC’s, and the event includes other sessions on PLC integrity and ICS secure protocols. It’s time to plan for your next ICS, or even accelerating upgrade plans, to be securable.
This final set of security controls are less novel in the ICS world than code signing or secure ICS protocols, but they demonstrate that a major vendor like Schneider Electric is considering attack paths and goals via threat modeling or other elements in a Security Development Lifecycle (SDL).
In fact all of the ICS vendors we talked to stressed the progress they have made over at least the last three years in their SDL. This includes fuzz testing (the Modicon M580 is Achilles Level 2 certified), secure coding practices, secure development training, threat modeling and more. This is very important, but hard to verify through interview and document review. If you are making a major purchase of PLC’s you should include some SDL requirements in your Factory Acceptance Test (FAT). It does not take much time or technical skill to determine if the SDL is just talk or real.
Running Services / Listening Ports
Secure by default is not a concept that the ICS community is ready to adopt. That said, the Modicon M580 has taken a small step in this direction and ships with FTP, TFTP and HTTP disabled.
There is an “Enforce Security Setting” that will disable FTP, TFTP, HTTP, EtherNet/IP, SNMP, and DHCP/BOOTP. The good security practice is to turn Enforce Security Setting on, and then make any necessary exceptions in further configuration. The Modbus/TCP service can also be disabled separately.
There are still compromises for legacy systems and features. For example, the Faulty Device Replacement (FDR) user/password FTP credentials are still in the M580 PLC. Schneider has limited FDR account access to the configuration files, but this is still a problem. These are the kind of things that can and should be fixed in future firmware releases.
Basic Firewall / Access Control List (ACL)
The Modicon M580 has a basic ACL capability, much like a router. You can implement a least privilege ruleset that restricts access by IP Address and TCP/UDP Port. They have made it slightly easier by identifying the listening ports and having a simple user interface to create the rules.
So if you need to allow a specific Unity Pro EWS to make application changes via FTP, you can allow this from a single or small number of IP addresses. If you want to allow the PLC to communicate with a SNMP server, you can restrict communications to that single server.
Look for a future article comparing the benefits of this basic capability vs an industrial firewall like Tofino, mGuard or Schneider’s Connexium. Depending on the industrial firewall ruleset the benefits can be trivial or substantial.
Disabling Unused Ethernet Ports
This is not a new feature, but the security aspects are being emphasized. Shutting down ports doesn’t stop attackers, but it helps stop employees from doing something that could introduce a security problem. There is also a USB port, but no information on whether this can be disabled.
Security Logging
Longtime readers will remember our Department of Energy funded Porteledge Project where we were trying to get ICS security logs into a SIEM or ICS SIEM. There are a couple challenges to doing this that are at least partially met by the Modicon M580
- Security Events Need to be Logged and Documented – The pictures below are from the M580 manual and show some important security events are available. They are also in a standard format that makes it easy for a SIEM to parse. Hopefully this list of security events will grow, and it would be good if a security flag was in the log format.
- Security Events Need to be Exported – The Modicon M580 supports syslog so they can be sent and accepted by any log management/archive server or SIEM.
Below are some of the useful security events available for detection and after incident analysis.
