Asset owners want DCS and SCADA security to be at least straightforward and preferably easy, especially when safety and security guys get together. Safety systems have a Safety Integrity Levels (SIL) that specifies the expected dangerous failure rate. So if a system must always work continuously, you may select components and design an architecture that leads to an expected dangerous failure rate of 0.00000001-0.000000001 for the system, SIL 4 . If it is less critical, you may select a components and design an architecture that leads to an expected dangerous failure rate of 0.00001-0.000001 for the system, SIL 1.
It is easy to see why this is so attractive to security professionals. Imagine having a Security Assurance Level (SAL) for a component that indicated the expected compromise rate, and then calculating a system wide expected compromise rate. Unfortunately it is a bit harder with security because the motivation of threat agent can vary by target system, not to mention the lack of threat data, vulnerability likelihood data, and compromise rates of control system components.
Enter to the discussion Security Assurance Levels – A Vector Approach To Describing Security Requirements, a paper by James Gilsin of NIST and Ragnar Schierholz of ABB, two sharp guys. Their paper comes largely from efforts in ISA99 to define and use SAL’s. In fact, the paper provides a useful quick read on how ISA99 is approaching security with zones and conduits and the seven foundational requirements of security.
ISA99 has qualitatively defined four SAL’s:
- SAL1 – protection against casual or coincidental violation
- SAL2 – protection against intentional violation using simple means
- SAL3 – protection against intentional violation using sophisticated means
- SAL4 – protection against intentional violation using sophisticated means with extended resources
Sounds good; reasonable qualitative definition of the SAL’s, but still the hard work of determining what security controls will achieve protection against each of these four threat levels remains.
The authors then suggest that rather than having one SAL per zone or conduit, perhaps a vector approach with a SAL assigned for each of the seven foundational requirements for security is appropriate. For example, there would be a SAL for access control and a SAL for data integrity. This recognizes that control systems implementation vary, and one system may be concerned more with data integrity while another would be concerned more with timely response to an event.
The question remains, how do you define, and reach consensus on, the controls required for each SAL. The paper kicks this question down the road by simply extending the qualitative definitions, i.e. Data Integrity SAL 2: Protect the integrity of information in the system against manipulation by someone using simple means.
SAL’s are an ambitious effort that would be a great help to the community if achieved and generally accepted. The paper does a good job of explaining the approach, but stops short of the hard work of saying how individual security controls or combination of controls are determined to be at one level or another. In fact, the vector approach adds complexity. This may be required, but it moves further away from the simple SAL number that owner/operators really desire.
I’m sure ISA99 would welcome more active contributions to this tough problem.