Process control cybersecurity gets serious with IEC 61508 and IEC 62443-4-1 in tandem, asserts Deepu Chandran. Back

Cybersecurity is critical for process industry. Photo credit: ABB

Safety Instrumented Systems (SIS) are part of the process industry as well as control systems, which involve in critical activities in oil refineries, chemical plants, pharmaceutical industry, machineries, power grids, etc. The role of safety instrumented functions is to support for safe operation of the process so that in case of a failure in process, safety instrumented functions can detect, indicate, prevent and control the potential hazard. SIS may consist of inputs, logic solvers and final element, which may be SIL certified as per IEC 61508 to meet the safe failure fraction value of the process complying with IEC 61511. Nowadays these critical systems are connected to the external world for easy management and it brings in additional challenges to deal with potential security issues that can compromise the safety.

Industrial revolutions and IEC 61508 and ISA/IEC 62443

Industrial revolution 3.0 paved the way for microcontrollers and microprocessors to be part of the critical operations and automation. IEC 61508 becomes the standard for adoption in development of electrical, electronic or programmable electronics systems which ensures safe operation of critical process. With Industry 4.0, cyber physical systems are connected and the need of the day is to ensure protection of these systems from any security threats generated internally and externally. ISA/IEC 62443 series of standards has been introduced to address cybersecurity protection methods and techniques at various levels including product manufacturer level, system integrator level and asset owner level. Product suppliers play a major role which is not significantly identified or assessed by the asset owners and system integrators. Product suppliers tend to adhere with functional safety by complying to the IEC 61508 process requirements but may fail to address the fact that end user may be using the product in a networked environment where it is getting exposed. ISA/IEC 62443 4-1 standard extends the scope for addressing the security requirements for a product/device, which is used in a connected world.

Extending the scope of addressing security requirements in OT-IT convergence.

Security measures for Safety Instrumented Systems connected to the external world ISA/IEC 62443 4-1 defines the practices for secure product development lifecycle requirements. The objective here is to defend against negligent and wilful actions to protect devices and facilities. The Secure Development Lifecycle (SDL) process activities include security requirements definition, secure design, secure implementation with application of coding guidelines, verification and validation, defect management, patch management and product end- of-life. These requirements can be applied to new or existing processes for developing, maintaining and retiring hardware, software or firmware for new or existing products. The process activities are initiated by identifying the secure components and performing a risk assessment on it, with respect to security threats while developing and deploying the product. Security requirements will be documented specifying the security capabilities that are required for a product along with the expected product security context. Defence in depth principle will be applied to ensure that the design of the product provides one or more layer of security to mitigate the security threats.

Security verification and validation testing

The processes specified by this practice are used to document the security testing required to ensure that all the security requirements have been met for the product and that security of the product is maintained when it is used in its product security context and configured to employ its defense in depth strategy.

Security testing can be performed at various times by various personnel during the SDL based on the type of testing and the development model used by the vendor. A process shall be employed for verifying that the product security functions meet the security requirements and that the product handles error scenarios and invalid input correctly. Types of testing shall include:
a) Functional testing of security requirements
b) Performance and scalability testing
c) Robustness testing including boundary/edge condition, stress and malformed or unexpected
input tests not specifically targeted at security, and
d) Vulnerability tests to ensure elimination of known weaknesses.

Issues uncovered by testing will be addressed as per Security Defect Management Practices.


The process will help ensure that the security capabilities are implemented correctly in the product and that any known security vulnerabilities in the product are eliminated or mitigated. So a few questions come to mind which include:
a) Is it enough?
b) How much it costs?
c) How do I do it? (Do I need additional manpower and tools?)

As far as we are looking from the perspective of minimising the risk originated from a security threat, we have done the job and we can assure a level of confidence in the product. So, it is always a lean process activity incorporated in the existing product development lifecycle.

Costs, of course minimal because it is not entirely a new process. You can use the same tools and process. The rigour may be diversified and high. Expertise involvement is required in security risk assessments and reviews, but the life cycle activities can be performed by current roles. Automated, integrated and certified tools are the best choice to perform the process activities for safe and secure product development. The use of certified tools helps generate evidence that can be used for an easy claim for certification of product. This ensures that in a single shot with few additional activities in your development lifecycle you can certify the product for safety and security standards.

Deepu Chandran

Deepu Chandran, Technical Manager, LDRA India, is an ISO 26262 CFSP (Certified Functional Safety Professional) with experience in the automotive, aerospace and industrial domains. At his current position, Deepu supports the embedded community as Technical Manager with LDRA’s India office. LDRA focuses on providing automated Test, Verification and Validations tools and services for Safety, Security and Mission critical markets, including that of industrial. With over 12 years of professional experience, he started his career as an embedded developer at Quest Innovative Solutions after completing his engineering degree in Electronics and Computing at the Visvesvaraya Technological University. He has been instrumental in supporting clients with selection, integration, and maintenance of embedded systems from requirements, through design and development, to certification.