With the appearance of malware and nation state attacks on Industrial Control Systems (ICS), such as the Stuxnet (2010), Industroyer (2016) and TRITON (2017) attacks, the IEC 62433 standards are gaining wider attention.  

While the potential targets to attack in an ICS system are many-fold, one plant asset that could be targeted is the safety system. More and more safety equipment OEMs are seeking to certify their products to both IEC 61508 Functional Safety requirements as well as IEC 62443 Cybersecurity requirements. One way to minimize time and effort is to address overlapping requirements in the two standards with common solutions.

Development requirements concentrate on processes to ensure a good understanding of what is to be built, how it is to be built and that it was built correctly.  IEC 61508 and IEC 62443-4-1 both have development process requirements. Furthermore, these requirements overlap a great deal, so separate assessment efforts would mean repeating assessment of common requirements.  By identifying what process requirements are in common between IEC 61508 and IEC 62443-4-1, and showing that the IEC 61508 process requirements meet the IEC 62443-4-1 process requirements, the cost of developing procedures, and assessing procedures for compliance, can be reduced.

The development process requirements in IEC 61508, while not prescriptive, are more detailed than those in IEC 62443-4-1.  With respect to life-cycle requirements, while the first security management requirement in IEC 62443-4-1, SM-1, does require “A general product development / maintenance / support process” to be “documented and enforced” in such a way as to be “consistent and integrated with commonly accepted product development processes”, it only paints a general picture.  It requires processes for at least:

• Configuration management
• Product description & requirements specification with requirements traceability
• Documented SW and HW design and implementation practices
• Repeatable verification and validation
• Review and approval of development records
• Lifecycle support

Since IEC 61508 process requirements include all these requirements and since they are defined in more detail than in IEC 62443-4-1, any process compliant with IEC 61508 will meet these general life-cycle requirements.

In addition to the general process requirements in IEC 62443-4-1, SM-1, other process requirements generally overlap with IEC 61508 requirements, but may have some additional implications for engineering work products.  For example, SM-12 requires process verification to ensure that all applicable security related processes have been completed properly.  This is an extension of the verification requirements in IEC 61508. So, let’s say your process calls for a functional safety verification checklist to ensure completion of a process step. That checklist could be extended to include security-related items, but the procedures requiring a checklist to be used for phase verifications can be agnostic to whether it is for safety, for security or for both.

Another example is the IEC 62443-4-1 requirement for Defense in Depth design, which is just an extension of the design phase of the functional safety compliant lifecycle.  An existing IEC 61508-compliant lifecycle might be extended by simply adding a section to an architecture design specification template and would not need to change the development procedure at all.

Other examples of procedure-related requirements that overlap include competency management, qualifying sub-suppliers, change management, coding standards and validation testing.

Finally, there will be some functional requirements in IEC 62443-4-1 that are cybersecurity-specific.  Examples of these requirements might be file integrity requirements, requirements on controls for private keys, security update management requirements for security patch updates and threat modeling requirements (though a threat model should meet the IEC 61508 requirement for a security analysis).

So, whether writing new procedures, updating existing procedures or assessing compliance of procedures, it makes sense to think about safety and cyber-security process requirements simultaneously, to avoid covering the same ground twice, saving time and effort.