Interested in linking to "Demanding Software Security Assurance "?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
By John Cusimano, Director, exida Security Services Division
In an October 2010 article at SearchSecurity.com, Mark Weatherford, vice president and chief security officer at NERC, was quoted as saying, "Addressing Stuxnet goes beyond using quality security controls. The industry needs to demand higher quality software that is free from defects. Companies who develop products and write code need to continue to mature their development processes to become more secure."
He went on to say, "This is not an indictment of [the] control system industry; it's an indictment of the IT business in general. We're still seeing products that come out that are susceptible to vulnerabilities that quite frankly have been in the wild for quite some time."
It is refreshing to see a point of view that recognizes that industrial control system security is not just a problem that owners and operators of industrial facilities need to address. Of course, owners/operators are ultimately responsible for the safety and security of their facilities, but that responsibility needs to be shared with their automation equipment suppliers.
These suppliers have a responsibility to ensure that their products are safe, secure and reliable. But, while they undoubtedly all strive to meet this expectation, achieving it has become increasingly difficult, as even the simplest of products have evolved to rely on sophisticated software that often isn't even written by the supplier. Couple the increased vulnerability of automation products due to software complexity with the emerging threat posed by viruses such as Stuxnet, and it is easy to see why Weatherford is calling for suppliers to focus on software security assurance for their customers.
Wikipedia defines software security assurance (SSA) as "the process of ensuring that software is designed to operate at a level of security 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 lifecycle (SDLC). Excellent guidance on how to do that has been available for many years. For example, Microsoft published the Security Development Lifecycle (SDL) in May 2006. SDL is Microsoft's methodology to help reduce the number of security defects in code at every stage of the development process from design to release.
The U.S. Department of Homeland Security and the Department of Defense Data and Analysis Center for Software published "Enhancing the Development Lifecycle to Produce Secure Software: A Reference Guidebook on Software Assurance," (https://www.thedacs.com/techs/enhanced_life_cycles/). Both documents provide software development organizations with a description of the key elements of a secure software lifecycle process and how to apply them.
Many automation system suppliers have already modified their SDLC processes to incorporate security. However, the level of integration and rigor with which they are applied can vary dramatically, leaving users who rely on these products wondering, "How well has my supplier integrated security into its software development lifecycle? How well has it followed its process on the products I use? How dependable, trustworthy and resilient is its software?"
The general IT marketplace attempted to address these types of questions several years ago with the Common Criteria for Information Technology Security Evaluation, better known as simply Common Criteria (CC, www.commoncriteriaportal.org/). CC is an international standard (ISO/IEC 15408: 2005) for computer security certification that provides a framework in which computer system users can specify their security functional and assurance requirements. Suppliers can then implement and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims.
An attempt was made in 2004 by the National Institute of Standards and Technology (NIST) to incorporate industrial control systems into Common Criteria by publication of a System Protection Profile for Industrial Control Systems (www.isd.mel.nist.gov/documents/stouffer/NISTIR_7176.pdf). Unfortunately, this effort was unsuccessful, most likely due to the lack of universal adoption of Common Criteria.
Frustrated by the lack of standard security conformance criteria for industrial control system products, industry leaders formed an organization in 2007 to establish a set of specifications and processes for the security testing and certification of critical control systems products. The organization, the ISA Security Compliance Institute (ISCI, www.isasecure.org), developed the ISASecure Program based on the security lifecycle concept for automation controls certifications using the framework of the ISA99 Standards Roadmap.
Availability of the first ISASecure certification program, called Embedded Device Security Assurance (EDSA). was announced in 2010. EDSA focuses on the security of industrial control system devices such as PLCs, DCSs, SISs and SCADA controllers, and addresses device characteristics and supplier development practices for those devices. The certification consists of three elements: a device functional security assessment (FSA), a device communication robustness test (CRT) and an organizational software development security assessment (SDSA).
All three elements of the EDSA are important and necessary to provide a holistic assessment of the security of a control system product, but we will focus on the SDSA. 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. The SDSA consists of 170 requirements derived from several existing reference standards listed in Table 1 and organized into 12 development lifecycle phases (Table 2).
An auditor from an accredited certification laboratory performs an SDSA audit based on documented evidence submitted for the certification and a site visit including interviews of development personnel and managers. A basic criterion for passing an SDSA applies at all certification levels, and becomes more rigorous at higher certification levels. Full details of the ISASecure EDSA program and the SDSA specification can be found at www.isasecure.org.
In summary, the ISASecure Software Development Security Assessment (SDSA) provides the ability for industrial control system users to determine if their industrial control system suppliers have adequately integrated security into their software development lifecycle. It also provides a mechanism for suppliers to be recognized for the efforts they have made to deliver on Weatherford's call for suppliers to focus on software security assurance.