Secure By Design – Part 2 Praying To False Certifications

Insecure By DesignMany 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

12 comments to Secure By Design – Part 2 Praying To False Certifications

  • Bryan Owen

    Another certification pitfall from ENISA’s recent report “Window of exposure… a real problem for SCADA systems?”

    Good practice recommendations “Section C Testing Patches”
    d. Certified systems should be re-certified after a patch is applied. This is an extremely important point. Technically speaking, any system that has been certified from a security perspective (e.g. a cryptographic device that is FIPS 140-2 certified) should be re-certified following a software patch. This is something that the industry tends to ignore because it costs time and money.

    Corollary: Free and lightweight certification tools are a practical necessity. Just ‘say no’ to heavy certification regimes.

  • Praying To False Headlines

    Nowhere in ISASecure’s literature does it claim the program certifies a system or component to be “secure by design.” Nor does ISASecure promise devices are “certified as secure”. Those are your words, not ISASecure’s.

    This is like first claiming that the FAA certifies that airplanes demonstrating compliance with the crashworthiness requirements are crash-proof and then saying that, since planes do crash and people do die, all FAA requirements are worthless.

    What is true is that ISASecure follows the ISO/IEC-17025 and 17011 standards for certification and is an ANSI ACLASS accredited program. If you read the ANSI documentation on the ACLASS process ( you will see this is not a “false” or trivial accreditation. It is a program that ensures “formal recognition to competent organizations.” Clearly ANSI believes that ISASecure is a competent organization or it would not hold the ACLASS accreditation.

    Furthermore, controls professionals are not two-year old children who need to be protected from the world. Before making a product selection, the controls professional should understand the implications of a given certification level (or hire someone who does to advise them). Anyone relying on the ISASecure certification can freely download all the requirements from the ISASecure website and see exactly what a company must do in order to get a product certified. To blindly assume that a certification at any level is some sort of guarantee of security is silly.

    This is no different than safety certification of control products. Just because you purchase a SIL 1 controller doesn’t mean it is safe no matter how it is used. Nor does it imply that it will never Fail on Demand. In fact, it means just the opposite – the Probability of Failure on Demand (PFD) for SIL 1 is 0.1-0.01 for low demand systems.

    ISASecure is worlds better than other so-called ICS security test programs where certifications are given out without clear publicly available requirements specifications. It’s also better than security certifications where products are allowed to pass when a firewall is installed in front of the controller (and this inconvenient fact is relegated to a footnote in the company literature).

    Your trashing of a valid program only sets the cause of ICS security back. Why should any vendor (especially a smaller vendor like RTP) bother to spend considerable time and money to create and then certify a software development lifecycle process, if respected experts like you call it a “false certification?” Why not do nothing for another decade and spend the money on a better marketing program? Let’s all do nothing until all the PLC and DCS are replaced.

    I was sad to read that you want to discredit the only ICS standard that is attempting to drive a security lifecycle process into the ICS/SCADA vendors. That you should try to do it with such misleading statements is doubly sad. Certainly you can push for replacing the current ICS architectures and protocols. But let’s not throw the baby out with the bath water – companies and organizations trying to deploy a SDL program deserve credit, not blame.


  • Brian Proctor

    Couldn’t agree more with Eric on this matter, I think ISASecure’s work is great for ICS/SCADA industry. Is it perfect? No of course not, but what framework/accreditation/compliance/standard is these days? It’s a huge step in the right direction and I applaud all those you worked on it and those who continue to work on improving it.

  • Dale Peterson

    Eric – The best way I can respond to your comment is with the picture added in the bottom half of the post. A reasonable person would assume that a product that is insecure by design could not get the ISASecure registration logo.

    You continue to misunderstand, or at least misrepresent, insecure by design. It is not simply a lack of secure by design. It is intentionally including “features” (not bugs) that allow an attacker with network access to compromise the availability and integrity of the device or application.

    There is much to like about the ISASecure process, but they need to require more to get the ISASecure logo.

  • Dale – I see two components on the logo for certified devices. The name of the organziation (ISASecure) and “Certified Device” What do you propose they change?

    Or would you propose that ISASecure just stop issuing certifications all together? Then companies that invest millions of dollars to deploy SDL process and companies that do absolutely nothing to improve their security can all be considered equal?

  • I believe what is important here is understanding both the requirements for compliance and auditing criteria. ISCI provides this information as part of the ISASecure program. Other certification programs do not (at least one I am aware of does not, anyway).

    As Eric alluded, it is always caveat emptor. It is the responsibility of the control system professional to do his own research. What ISASecure certification does is allow a professional to quickly assess a baseline for what should be considered important considerations as part of a procurement process. It is not complete as it stands today, but it is quite rigorous. It is also a work in progress, which will become more comprehensive as it continues to grow.

  • Dale Peterson

    Eric – I propose they stop issuing certifications labeled ISASecure to devices that are insecure by design. Ditch the Level 1 certification. The criteria they have in the FSA and SDL are not bad, just need to require a lot more of the criteria be met to get the ISASecure stamp. CRT needs to cover all network accessible protocols.

    I’m not sure what the security benefit is to investing millions of dollars in an SDL if the integrity and availability of the end product can be compromised using documented features.

  • Bryan Owen

    “Security Certification – A Critical Review” by Ragnar Schierholz and Kevin McGrath of ABB is an excellent resource for this topic.

    For example here is an analysis of a market failure scenario:
    [Certifications with] …’Limited meaningfulness may lead vendors who take security serious to engage in other signaling mechanisms.’

    The paper also covers the danger of a false sense of security and race to the bottom issues with a balanced tone:
    …’At the same time the value of these [security certification] programs should be acknowledged. The programs have raised awareness of security.’

    Contrary to discrediting ISAsecure, commentary on Secure by Design could help prevent market failure.

    PS> URL from ICSJWG is 404 but ICS-CERT will send the paper on request.

  • Ragnar Schierholz

    Bryan, I’m glad you liked our analysis and found it to be a balanced review of the issue.

    For other readers, the paper is still available for free download without any registration or e-mail inquiry:

  • John Cusimano


    I’m looking forward to your expose on the recent announcement that “Siemens AG, Industry Automation Division, has obtained the Achilles® Practices Certification for its SIMATIC PCS 7 process control system”. I’m very curious how a product can obtain a “practices” certification.

  • Dale Peterson

    John – Interesting point. I’d would say it was unfortunate wording, but it appears twice in the release.

    There was a place for the Wurldtech cert when nothing else existed, and they were leading edge. That time has likely passed, and despite its flaws the ISASecure effort is structured much better as an open and independent certification body.

    We do need to bow down to the marketplace though. There are very large oil companies that are demanding vendors get the Wurldtech certs. Even with a skeptics eye, there is almost surely some increase in security for going through this process.

    I wouldn’t go as far as the release and say “By passing these stringent certification requirements, Siemens customers are assured that SIMATIC PCS 7 processes meet or exceed best practice benchmarks.”

    Siemens has made a lot of progress over the last three year in their CERT and beginning to face insecure by design issues in that product line. They still have a substantial way to go, and it will be interesting to see how these new security features released this year hold up to some serious testing.

  • Sihoko

    There seems to be a mix up here. The Achilles Practices Certification is a certification for the vendor’s capabilities to engineer and maintain a system for a particular product. It was created by Wurldtech together with Shell and later reveiwed and issued by WIB. This is in IEC terminology the IEC 62443-2-4 document, for which there is no ISA 99 equivalent. This is the certificate Siemens mentions, and this is about practices! Engineering and service practices during the lifecycle of the product. APC has become a mandatory requirement because several European companies require vendors to certify to either bronze/silver/gold inorder to be able to sell their products. Also this certification is linked to product and release. The certificaion requires periodic renewal and renewal after a new release. To my knowledge only Wurldtech can perform the audits, there are no other auditing companies.

    This is a different certification than the older Wurldtech certification for embedded devices. This certification can be compared with ISASecure, and anyone taken the time to compare the two will have to admit that the ISASecure certification is the better one.

    But let’s not mix up the two certifications ….. Siemens either passed or renewed its Simatic PCS 7 APC certification … nothing to do with the embedded device certification.

Leave a Reply