Automation World has a great article, Security and Safety Follow Parallel Paths, which compares and contrasts process safety and cyber security, from a risk management perspective. In an earlier post, I described the ISA99 Working Group 7 (WG7) efforts to look at the best practices in process safety and see what can be applied to functional security around the automation systems.
The article quotes Emerson’s Mike Boudreaux who serves as ISA99 WG7 co chair on similarities:
On the front end of the security lifecycle, where you’re trying to figure out what your risks are, the kind of risk analysis that you do is very similar to the type of risk assessments that you do for safety, where you’re identifying unwanted consequences, evaluating the likelihood that those might occur, and based on that, you have a level of risk that you need to implement safeguards against.
WG7 is taking a similar approach to process safety risk levels with security assurance levels (SALs):
In the safety world, standards such as the International Electrotechnical Commission’s IEC 61508 and IEC 61511 describe methods for assigning Safety Integrity Levels (SILs) to designate different levels of risk reduction provided by a safety function. Similarly, the ISA99 committee is working on a parallel concept for security known as SAL–for Security Assurance Level. Just as Safety Integrity Levels range from SIL 1 at the low end to SIL 4 for the highest integrity level, the SAL approach, as currently contemplated, will cover SAL 1 through SAL 4, designating ascending levels of cyber-security protection.
This helps prioritize security risks and the defenses required for the risk level. The article also explored the differences between process safety and cyber security risk mitigation. A statistical view is taken with process safety. Mike notes:
The focus in the safety world is on designing devices that have predictable hardware failure rates. So when I install a device out there, I can predict how frequently it’s going to fail throughout the life of the process for the next 20 years… But the concept of predictable, random failures doesn’t apply as well to security… With security, when you put a protective measure in place, you can’t predict what its useful life is going to be.
Safety is somewhat of a fixed process. Once you’ve got the risks figured out and the processes in place and you put the safety system in, it doesn’t change… You put in antivirus software and its life is measured in days, because there’s always something new–the next conflict, or the next Sasser worm… So it’s constantly evolving, and the management on the security side is much more complex and onerous, in my opinion, than it is on the safety side.
It sounds like the working group is quickly identifying the parts of the process safety lifecycle that make sense to borrow and apply for process automation cyber-security. I tend to agree with Mike’s prediction that the pace of the ISA99 standards effort will move more quickly than the ISA84 process safety effort, because they are borrowing what they can and developing the rest.