The recently updated process sector safety instrumented system (SIS) standard IEC 61511 now requires that a "security risk assessment is carried out to identify security vulnerabilities of the SIS" . But how should such an assessment be approached*, and what can you do to prepare for it?
There have been well publicized examples of cyber-security breaches in the public domain, including the 2017 National Health Service (NHS) "Wannacry" ransomware as an example. Perhaps less well known by the general public was the 2017 "Triton" attack on Schneider Electric's Tricon TMR safety systems on a Saudi Arabian Petrochemical plant. That led to an unplanned shutdown of the process rather than any major hazard, but it could easily have been a very different outcome.
I hope I'm not guilty of jumping on some scare-mongering band wagon as I write this blog, but I do feel it is important to help deliver the message that safety instrumented systems can be compromised by not paying attention to security. Cyber attacks are clearly not the only threat to modern control and safety systems. However, there are enough real-life examples now that burying your head in the sand and hoping the problem might never affect you is probably not a sound strategy.
From a practical stand-point, I have come across this issue mostly when conducting independent functional safety assessments (FSA) since edition 2 of IEC 61511 was published in 2016. It is fair to say that when I ask questions during an FSA about measures to assess security risks of a new or modified SIS, I usually get my answer in the form of shrugs and blank faces.
Here are the new parts of IEC 61511 that should be coming up during any FSA activity:
Firstly, IEC 61511 now requires a "security risk assessment" according to new clause 8.2.4. This section of the standard is about process hazard and risk assessment, so it is applicable to a process industry end user who is doing an exercise like a HAZOP - a Hazard and Operability study.
Secondly, the standard requires that "the design of the SIS shall be such that it provides the necessary resilience against the identified security risks" in new clause 11.2.12. Clause 11 is all about SIS design and engineering, so typically this will be in multiple hands if a new or modified system is being designed. For an existing system, the design stage may have been many years ago, but vulnerability could be much higher than a new system.
Thirdly, the new Application Program Implementation requirements of IEC 61511 software clause 12.4 require that "communications are made secure (e.g. cyber security measures)". Again, this task could be in several different hands for a new system, but more than likely a system supplier responsible for implementing the software and control and instrumentation network between the basic process control and safety instrumented system(s).
The summary from this brief review of IEC 61511 is that security / cyber-security must be considered in the early phases of hazard and risk assessment, in the equipment selection, in the detailed system hardware design and in the application program software implementation.
IEC 61511 itself does not give detailed security risk assessment advice, but instead points users to other standards that do - namely the IEC 62443 series. This blog is not going to get into the 13 parts of that standard. Suffice it to say that although not all parts of IEC 62443 will be applicable to an end user, there are still several hundred pages to read!
Given the complex and developing nature of IEC 62443* on first viewing, it is fair to ask what an end user on a high hazard process site should do right now about possible cyber threats to their existing control and SIS layers? As international standards are notoriously slow-moving, it's probably not a good idea to wait until they fully stabilize before doing something pro-active.
*Read more about security standards at this link
As international standards are notoriously slow-moving, it's probably not a good idea to wait until they fully stabilize before doing something pro-active.
How to meet the challenge for existing plant?
Meeting the challenge of possible security vulnerabilities of an existing control and safety system is not necessarily going to be trivial. In my opinion it should start with deciding on priorities and "quick wins". The best way of approaching this is to begin with a period of fact-finding about the as-built systems and the way they are connected and operated.
Going beyond the fact-finding stage, a more detailed security risk assessment could be timed to start after the next significant HAZOP. As the goal of HAZOP is really aimed at process hazard and operability issues, it makes sense to me that we call it something different and distinguish the different goals. Having had previous personal experience with conducting and facilitating Control-HAZOP or CHAZOP, I believe that security risk assessment fits neatly with this form of study.
One possible method - Security CHAZOP
Before conducting any form of detailed team study, it is critical for all concerned to have the correct facts at hand. In a traditional process HAZOP the piping and instrumentation diagrams (P&ID's) are one of the key reference sources that must be up to date before starting.
For a CHAZOP exercise, having accurate and up to date reference sources is just as critical, albeit the reference information will need to be expanded to include network diagrams, physical equipment locations and more. It is important to know exactly what equipment exists and how it is connected before starting to look at security vulnerabilities.
A CHAZOP can be approached in several different ways. In many cases companies keep their proprietary methods private. However, it will typically involve a form of systematic "What-if / checklist" approach coupled with a risk matrix to rank and prioritise scenarios and related actions.
Want to know more?
We already have a CHAZOP procedure that we have applied successfully on many projects. We are now actively working on extending this to include the advice provided in some of the above-mentioned security standards.