Safety and security critical software. Chalk and cheese? Or peas in a pod?

Safety critical and security critical software have long been regarded as two different genres, with their own standards and their own requirements.

In some circumstances, that is entirely reasonable. For example, in most safety critical applications such as a steer-by-wire system in a car, it is imperative that a level of functionality is retained even when things are failing.

Conversely, if a hacker is found to be accessing a bank’s databases then the preferred immediate response is likely to completely deny all access. The inconvenience of other bank users can wait if the integrity of the data is at stake.

Any system providing an interface to the outside world has the potential to contain security vulnerabilities. In particular, any accessibility via the Internet requires a strategy to deal not only with a few malicious specialists, but with a whole world of hackers.

In the field of safety critical embedded software, such security concerns are often perceived to be a separate domain from the core business of functional safety. Yet when security researcher Barnaby Jack used a modified antenna and software in 2011 to wirelessly attack and take control of Medtronic’s implantable insulin pumps , he demonstrated how such a pump could be commanded to release a fatal dose of insulin. Clearly this security vulnerability puts the safety of dependent diabetics at risk, and in this situation safety and security are indistinguishable.

Similar examples of this synergy between security and safety can be found throughout the world of safety critical software. When a security breach can interfere with the running of any critical infrastructure such as a train, industrial plant, public utility, or a car, the distinction between safety and security becomes meaningless.

This situation is implicitly acknowledged by the safety related process standards. As soon as there is potential for security vulnerabilities to threaten safety, standards such as IEC 61508 / EN 61508 (Process), ISO 26262 (Automotive), IEC 62304 / EN 62304 (Medical), IEC 62278 / EN 50128 (Railways) and DO-178 (Aerospace) demand functional safety requirements to deal with them.

Perhaps then, we can say that if a threat to an application has safety AND security implications, then the safety consideration has to take priority.

Cross fertilising security and safety best practice

This commonality of purpose where safety meets security is evident in many other ways. For example, the Automation Standards Compliance Institute recommend the implementation of a Software Development Security Assessment by referring to existing safety focused process standards such as IEC 61508, and superimposing best practice security measures on them. It is easy to envisage a safe AND secure application developed in this way.

Further evidence of the overlap between safety and security best practise can be found by comparing IEC 61508 with ISO 15408 (“Common Criteria”). Reference to this security focused, process-oriented standard underlines the similarity between security and safety related software development, with the seven Evaluation Testing Assurance Levels (EALs) of ISO 15408 being highly analogous to the concept of Safety Integrity Levels adopted in ISO 61508.

Applying Least Privilege Separation Kernel principles to fulfill functional safety requirements

If functional safety requirements demand a defence against security vulnerabilities, then it makes sense to apply established security best practice to provide that defence. Where a safety critical application is required to be accessible via the Internet, then a least privilege separation kernel represents an example of that best practice.

A traditional separation kernel is designed to ensure that the different blocks of a partitioned system are not visible to other blocks, except perhaps for certain specified and tightly controlled flows of information. The least privilege model extends that principle by subdividing the contents of the blocks so that such visibility is minimised to provide only that access which is absolutely necessary.


Applied to an example “real world” scenario, in practise this means that the separation kernel closely regulates the communication paths between the operational technology (OT) on the plant side, and the information technology (IT) on the Internet side. If there is a successful denial of service attack on the Internet facing windows partition, then the external operator may well be denied access to the information he is seeking. But the safety critical plant control will be protected by the separation kernel, and will continue to function normally.

In short, the safety function is fulfilled by the application of best practise security focused development.