Honeywell Leads ICS and SCADA World with ISASecure Certifications

Submitted by Eric Byres on Wed, 2012-08-29 13:46

Editor's Note: This is an updated version of this article, which was first published on June 14, 2011.

Honeywell and the ISA Security Compliance Institute last week announced that two more Honeywell products, the Experion® C300 DCS controller and the Experion fieldbus interface module (FIM) joined the Honeywell Safety Manager in achieving its pioneering ISASecure Level 1 certification. Following this announcement Dale Peterson questioned the value of some aspects of ISASecure certification.

Here is why I believe, as I did in June 2011, that ISASecure certification is valuable.

ISASecure Level I is a Better Level of Security

Obtaining ISASecure Level I certification is significantly more difficult than passing a Communications Robustness Test (CRT) like Achilles Level I (or II or III). ISASecure certification is based on a security validation process that is an order of magnitude more rigorous. It indicates a far higher level of security in both the product and its intended use.

For ICS and SCADA equipment end users, understanding the difference is important. It may mean the difference between buying a product riddled with vulnerabilities and buying a product that was designed to be secure.

Mount Sharp on Mars, as captured by the Curiosity rover on Aug 23, 2012. A difficult but successful engineering challenge. Source: NASA/JPL-Caltech/MSSS

The Limitations of Communications Robustness Tests (CRT)

In a CRT, the device under test is sent a variety of malformed network messages to see if it can correctly handle possible bad traffic that an attacker might throw at it. If it ignores the bad messages, it passes the CRT. If it crashes or acts in an unpredictable manner, it fails the CRT.

Now this is a useful test because many industrial controllers cannot survive even the simplest malformed message. For example, one of the 2011 Siemens S7-1200 vulnerabilities was the result of the PLC’s embedded web server crashing when it gets a bad packet. This in turn causes the PLC’s CPU to fault, resulting in a Denial of Service (DoS) attack from a single message.

Unfortunately, a robustness test won’t find security problems like the hard-coded SQL passwords that figured so prominently in Stuxnet. Nor will it discover bad design practices, such as embedding passwords in the products (issues faced by RuggedCom a few months ago) or sending them across the network in clear text (a problem with many PLCs). And it certainly isn’t going to tell you if the control product’s engineering team used secure coding practices when they wrote the software.

Even where robustness testing has potential, it can miss problems because there is no test for a specific protocol. For example, Achilles Level I would not have detected the Siemens S7-1200 web server bug, because it does not send malformed HTTP messages in its tests. So while useful, passing a robustness test is a very small part of good ICS/SCADA security.

Why ISASecure is Better than a CRT Test

This is where the ISASecure program comes in. It starts with a CRT assessment phase similar to Achilles Level I (it actually uses the Achilles tool), but then it adds two more assessment phases:

These assessments are where real progress in ICS and SCADA security will be found, because they consider the underlying design, development practices and vendor recommended deployment of the product, rather than just whether it stands up to some bad traffic.

For example, the tests determine if the product allows the user to correctly manage passwords (FSA-AC-2.1.1) or whether the development team has created and managed a Threat Model (requirement SDSA-SRA-3) during the design process. Tests like this are likely to uncover a large range of security issues, or even better, ensure that companies follow processes that stop vulnerabilities from being created in the first place.

Bill Goble of exida, the company that conducted the certification testing, presents Erik de Groot of Honeywell Process Solutions with the first ISASecure Certificate. Source: Honeywell Process Solutions

ISASecure is the Standard to Demand from Control System Vendors

Don’t get me wrong – ISASecure certification is no guarantee of perfect product security, any more than having a medical certificate guarantees a doctor is top notch. But Achilles Level I CRT is like being admitted to med school – important, but only one step on the way.

ISASecure certification is like the credential that confirms the doctor has passed all the med school exams, survived the hands-on trials of residency and is now approved to practice medicine. Frankly I would prefer to trust my life to the latter, even if the former might be cheaper. The same applies to control systems.

Now Dale Peterson makes some good points in his comments on the limitations of ISASecure Level I. He’s right that it is a “positive trait”, not a guarantee of a product’s security. However, I am glad to see that we are now at the point of talking about more education and better communication of ISASecure’s various levels, rather than where we before, with no independent auditing of a device’s security capabilities.

If we want secure control systems, end users need to start demanding that any system they purchase is ISASecure certified. To accept less is to continue to accept flawed systems that hackers will attack with ease.

Comments

Submitted by Andrew Ashton (not verified) on Wed, 2011-06-15 08:40

ISASecure Certification

While I do not dispute anything that is written here, and indeed support all attempts like ISASecure that will lead to more robust systems, the the bigger problem is "we don't know what we don't know" i.e. Zero-Day holes in the OS or application.

It always seems that given enough motivation / time / money, there are those who have the skills to discover one or more Zero-Day flaws that can be utilized to gain access to target systems.

Submitted by Eric Byres on Thu, 2011-06-16 06:51

RE: ISASecure Certification

I agree that there will always be zero-Day flaws. The trouble is, right now there are too many 0-days in the ICS/SCADA products and they are too easy to find. I believe the only way we will address this is to engineer security into the product in the design phase and not try to bolt it on later.

The ISASecure program tries to enforce this by requiring proof that a company has a proper security life cycle process in its product development. Once a company begins this, it can improve all their products, not just the ISASecure certified ones. To me this is the really important news.

Submitted by Darrell Pitzer (not verified) on Wed, 2012-08-29 13:36

I agree with Eric's comments.

I agree with Eric's comments. Until there is pressure on the vendors from the customers to have more secure design and coding processes/practices, we will continue to get poorly secured products. ISASecure is not a panacea, but it is definitely on the right path.

menu-bar