SCADA Security Requires Software Security Assurance

The publication of numerous SCADA vulnerabilities by L. Auriemma last month, on top of the game-changing Stuxnet malware revealed last year, has exposed many security weaknesses in Industrial Control Systems (ICS). The weaknesses occur on two fronts: technology and human factors.

Technology weaknesses exist in the communications technology, devices, and software applications used in the automation industry. Weak security cultures in organizations, inadequate security processes and difficult to configure and manage security products are some of the human factors involved (for a further discussion on the human factors, see the White Paper “How Stuxnet Spreads”).

All of these factors need to be addressed and improved (or compensated for) to ensure the safety of industrial facilities going forward.  In this blog, I am going to address one of the factors: software security assurance.

In the automation industry, suppliers undoubtedly strive to meet the expectation of high security.  However, achieving it has become increasingly difficult as even the simplest of products have evolved to rely on sophisticated software – software which often times isn’t even written by the supplier.  As owners and operators of industrial facilities, how can you be assured that the products you use have high security standards?

What is Software Security Assurance (SSA)?

The starting point is to understand what Software Security Assurance (SSA) is.  According to Wikipedia, it is the process of ensuring that software is designed to operate at a level of security that is consistent with the potential harm that could result from the loss, inaccuracy, alteration, unavailability, or misuse of the data and resources that it uses, controls, and protects.

SSA is best achieved by integrating security into the software development life cycle (SDLC).  Excellent guidance on how to integrate security into the software development lifecycle has been available for many years.  For example, Microsoft published the Security Development Lifecycle (SDL) in May 2006.

The good news is that many high-quality automation system suppliers have already modified their SDLC processes to incorporate security into their standard development lifecycle.  However, the level of integration and rigor with which it is applied can vary dramatically leaving you with questions, such as:

• “How well has my supplier integrated security into their software development lifecycle?”
• “How well has my supplier followed their process on the products I use?”  
• “How dependable, trustworthy and resilient is the software my supplier is producing?”

Standard Security Conformance Criteria

To ensure that the products you use have high security standards you can look to the certification program of the ISA Security Compliance Institute (ISCI)ⁱ. Since 2007 this group has worked to establish a set of well-engineered specifications and processes for the security testing and certification of critical control systems products.  It developed the ISASecure Program based on the security lifecycle concept for automation controls certifications using the framework of the ISA99 Standards Roadmap.

One of the three elements of certification is organizational Software Development Security Assessment (SDSA) (the others are a device Functional Security Assessment (FSA), and a device Communication Robustness Test (CRT).

The purpose of the SDSA is to provide verification and validation that software for the device or system under test was developed following appropriate engineering practices to minimize software errors that could lead to security vulnerabilities.  The SDSA consists of 170 requirements organized into 12 development lifecycle phases.

An auditor from an accredited certification laboratoryⁱⁱ performs an SDSA audit based upon both documented evidence submitted for the certification and a site visit including interviews of development personnel and managers.  Full details of the ISASecure EDSA program and the SDSA specification can be found at www.isasecure.org.

ISASecure Certification is the Key

The ISASecure program has been available since late 2010.  While there are currently no certified products, there are several certifications in process at this moment.  If you are concerned about the security assurance of your vendor’s software, you should be asking them if they are working on certification.  And, be sure to ask them what you should be doing to counteract any vulnerabilities that may exist in their products right now.

The ISASecure EDSA program deserves the support of industry end users and suppliers, and will ultimately ensure a high level of software security for ICS and SCADA owners and operators.

For a full discussion of this topic, see the exida article “Demanding Software Security Assurance from Industrial Automation Suppliers.”

Note from Eric Byres re: Devices covered by ISASecure

All Tofino Security products are developed using a version of the Security Development Lifecycle (SDL). They are also internally tested using a very extensive Communications Robustness Test.

Unfortunately, ISCI certification is not possible, since the ISASecure Program currently only covers certification of edge devices such as PLCs.  It does not cover network devices. It is our understanding that certification programs for devices like the Tofino Security Appliance are several years away. 

I believe that it is in the best interest of industry for these programs to be developed as soon as possible and I encourage end users and vendors to work with ISA to achieve this.

ⁱ www.isasecure.org
ⁱⁱ exida is an Accredited ISASecure Test Lab

This article is a special guest contribution by:

John Cusimano, CFSE, CISSP Director of security services exida jcusimano@exida.com www.exida.com

Practical SCADA Security thanks John for his contribution.

Related Links

Honeywell Leads ICS and SCADA World with First ISASecure Certification

Subscribe to the "Practical SCADA Security" news feed