Blog

In a couple of weeks, we’ll be at the Digital Bond S4 Conference in Miami. Here’s the agenda.

I have the privilege this year of presenting two papers. The first of which Dr. Nate Kube and I created, where we take an analytical look at Safety Integrity Levels (SIL), and make comparative analysis on what a Security Assurance Level (SAL) might look like. It’s a think piece, and we certainly have a ways to go, but a number of us in industry have started to question what a security level system would look like. The second paper is one that Ralph Langer (http://www.langner.com) developed, and it addresses the concept of a risk based threat modeling approach that starts with scenario modeling. This is largely based on earlier work that both he and I created independently; coming together for the S4 conference to present what we hope will be an effective way for folks to start developing a better mindset towards security.

The subject for this blog, however, is on the security level concept. I will introduce the premise of the paper here, some conjecture upon various problems, and then follow this article up based on feedback received at S4 and other places. This is a complex subject that requires a lot of attention to adequately address the subject.

Or paper focuses on the limitations of SIL, namely that SIL deals primarily with a system running nominally, where one component or a series of components experiences an entropic event (failure). The SIL concept focuses largely on the functionality of the safety systems in place to be able to maintain or preserve a safe state during such a failure. The basic assumption, everything but the device or system under failures works the way it is supposed to when the event occurs. This model is largely adequate for safety, but falls short in security in many ways. One of the key differences: we cannot expect nominal system behavior for related systems during a security event.

SIL does not deal with the intentional attack, and an intentional attack by its very nature violates design constraints of a system. Think about driving a newer model car with all of the anti-skid, airbags, anti-collision systems, etc. All the safety systems in that car will do no good if someone drives the car at 120MPH and intentionally yanks the steering wheel to send the car into a telephone pole.

Security is the latter, where attackers can disable or deny functionality of key systems to maximize system damage. A more appropriate example comes recently from Poland where a teen used a modified TV remote (allegedly) to interrupt train switches, sending engines off in different directions, causing derailments, and some damage. Safety controls aren’t even a factor when such constraints are violated.

One similarly exists in rating for compliance. Components are not SIL rated, they are rated to exist in a SIL environment, and there is still a very rigorous process required for design and implementation (or historical trending for existing systems), and security will follow many of the same lines.

The paper goes in to much more detail, but our basic argument follows that security levels (i.e. the need for a certainly level of security), will be assessed based upon the controllability of the process and the risk for greater impact during a security incident. Components must be rated upon their resilience of attack and overall capability to handle events in order to maintain the desired level of control. In this manner, a chemical plant with a dangerous process requiring specific cycles and times in blending chemicals, or a high speed turbine would require much higher levels of protection than a low speed filling line. Components must be appropriate designed and implemented to assure this level of control. This is sure to be a complicated piece of work, but one we hope to spend more time and effort in developing and working with standards to see implemented.