Many asset owners would like a check box approach to security, where some independent, reputable organization certifies the system or component is secure by design. There are a growing number of security certifications that are trying to meet this need. Even if every ICS is a semi-custom system, a security certification could eliminate the need for each asset owner to assess the same security basics such as technical security controls, security development lifecycle and fuzz testing.
The problem today is insecure by design ICS software and devices can actually be certified as secure. ICS suffers from, in the words of the great orator President George W Bush, “the soft bigotry of low expectations”.
The best example is the ISASecure embedded device security assurance (EDSA) certification. ISASecure/ISCI was created by ISA originally to have a certification capability for ISA99 security standards. When the ISA99 standards that could serve as the basis for certification were delayed, ISASecure certification criteria were independently developed by the member companies (Chevron, ExxonMobil, Honeywell, Invensys, Siemens, Yokogawa). There are a lot of positives to this effort, but currently the overwhelming problem is the false sense of security an ISASecure Certification provides.
There are three parts to the certification testing:
- Functional Security Assessment. This is where the technical security controls in the PLC/RTU are defined, and there are no data integrity requirements for Level 1 ISASecure Certification. A PLC can be certified as ISASecure and have no authentication of the source or data related to critical request packets. Look through the document and you will see that Level 1 has minimal required security controls. Even the nine controls with the word basic in the title are not required to be certified as ISASecure
- Communication Robustness Testing (fuzz testing). The devices protocol stack is subjected to positive and negative testing … well, sort of. There are tests for Ethernet, IP, ICMP, TCP and UDP, but no tests for fuzzing of the control system protocols. The control system protocols are where the protocol stack bugs are most likely to be found.
- Security Development Security Assessment. The SDL portion of the ISASecure certification. This section actually has stringent SDL requirements, even in Level 1. It is hard to see how a product developed under these requirements could have such weak technical security controls or vulnerable protocol stacks. The escape clause is usually related to the environment assumptions. If you assume this is running on a secure network that cannot be accessed by an adversary the security requirements melt away.
ISASecure would likely respond to these issues with the Levels concept. Certifications begin at Level 1 and gets tougher at Levels 2 and 3. And to be fair, Level 2 adds a substantial amount of required technical security controls. That said, would you ever assume any PLC that received an ISASecure Certification is insecure by design? Isn’t this terribly misleading? When you read the press releases from ISASecure and the vendor you would assume that purchasing an ISASecure certified PLC or RTU meant it had basic security controls.
And ISASecure may be the best ICS certification available today.
UPDATE: Added ISASecure picture to address Byres comment.
We can argue about how long it should take to replace existing insecure by design components and protocols in the critical infrastructure, but there should be no argument about new purchases and deployments. We need to request and expect more.
At this point in time, be very careful about accepting an industry created security certification as evidence of a product or system being secure by design.
Image by ptthread1981