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).