[Ingo Rolle is the Secretary of the German National Committee responsible for matters concerning IEC 61508 as well as the German National Committee responsible for matters concerning IEC 62443. This is an invited essay. PBL]

IEC 61508:2010 is the international standard for functional safety of electrical, electronic and programmable electronic systems. It applies to the digital subsystems of any industrial system, such as process plants, sensors in safety-critical environments, and even electric toasters. It has specialised derivatives for each branch of engineering, for example IEC 61511 for industrial process plants and EN 50128 for railway systems (for example, train control and signalling).

In recent years, penetration and subversion of computer systems has increased, as has the damage caused by such activities. Engineers are now well aware that their digital-electronic subsystems are open to penetration and subversion of their intended function by unauthorised persons, and these include industrial control systems not necessarily with any network connections with the “outside world” (e.g., not connected to the Internet). One famous example from 2010 is the “Stuxnet” malware which affected the operations of a Iranian uranium processing plant, as well as other sites. “Security” is the general term for measures intended to protect against unauthorised penetration and subversion of function of systems; for digital systems this is often called “IT Security” or “cybersecurity” ,to distinguish it from the physical security which has long been part of the design of industrial plants.

Cybersecurity for industrial control systems (control systems in industrial plant) is being standardised in the series IEC 62443. It defines a notion of Security Level (SL), to indicate the extent to which security analysis and measures must take place for a given subsystem with given function and with respect to one of seven Foundational Requirements (FR). SLs are defined as follows:

• SL 1: There is to be protection against causal or coincidental violation of function
• SL 2: … protection against intentional violation using simple means
• SL 3: … protection against intentional violation using sophisticated means
• SL 4: … protection against intentional violation using sophisticated means with extended resources

and the FRs are:

• IAC Identification and authentication control
• UC Use control
• SI System integrity
• DC Data confidentiality
• RDF Restricted data flow
• TRE Timely response to events
• RA Resource availability

The notion of SL is further subdivided into:

• SL Target : the target Security Level resulting from the risk analysis;
• SL Achieved: what Security Level has actually been achieved in the real application;
• SL Capability: what Security Level a specific device attains if properly installed and configured.

So, for example, Preliminary Hazard/Threat Analysis of system S may result in a risk assessment which assigns SL 2 to functional component C with respect to Foundational Requirement DC. Company XYZ has a device which can be used as component C , and they have developed and demonstrated it to SL 4 for FR DC. However, there is a specific “extended resource” R (say, a specific computer system powerful enough to break some sophisticated encryption) which may have access to component C through its environment in S and it is not known whether the encryption of information in C is sufficient to resist persistent use of R in all cases. So in its use in S, the engineers assess component C as attaining SL 3, but not necessarily SL 4. Here, we have SL Target 2, SL Achieved 3, and SL Capability 4 for FR DC. We should mention that, to achieve SL 3 for FR DC, some specific capabilities of the organization which operates component C should be demonstrated.

IEC 61508 has a notion of Safety Integrity Level (SIL). The SIL is applied to so-called “safety functions”, functions which are meant to keep operation of a system acceptably safe. It is a measure of the reliability of a safety function. If the safety function is implemented largely in software, the Software SIL translates into how carefully the system must be developed (and it is assumed that care in development correlates with trustworthiness of the resulting software).

We can compare the approach to Foundational Requirements roughly with the approach to Safety Functions. While the first FRs are defined in common by IEC 62443 for all systems, Safety Functions are determined individually for each system by means of the Preliminary Hazard Analysis.

The differentiation between “target”, “achieved” and “capability” for SILs is not present in IEC 61508. We suggest it is a useful distinction and may be interpreted thus. On the one hand, IEC 61508 states that a SIL is a measure how much a safety function shall reduce a risk. The risk is assessed as one of the first steps in IEC 61508-conformant system development and the SIL assigned as a result of this analysis. This would resemble “target” SIL. On the other hand, SIL is literally defined as an integrity level, which would seem to be the reliability with which the safety function is actually performed in a running system. This would resemble “achieved” SIL. It is common for device manufacturers to state in a product data sheet that their device is appropriate for “SIL 4 applications”. This is something like a statement of SIL “capability”.

IEC 61508 (first version 1998) was written much earlier than IEC 62443 (ISA99), and this differentiation of different notions of SIL obviously did not occur to the original authors. Now, after decades of companies adapting to IEC 61508 as written, it seems to be difficult to bring such notions in to a new version. Nevertheless, the differentiation is obviously helpful, as indicated above. So it seems we may have to add a “virtual index” to each SIL statement in the manner in which IEC 62443 does.

Ingo Rolle