The critical importance of Sicherheit in embedded software

It is no coincidence that the German language has just one word that means both safety and security – 'sicherheit'. 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 acknowledged implicitly by the safety related process standards. As soon as there is potential for security vulnerabilities to threaten safety, standards such as IEC61508/EN61508 (process), ISO26262 (automotive), IEC62304/EN62304 (medical), IEC62278/EN50128 (railways) and DO-178 (aerospace) demand functional safety requirements to deal with them. Without exception, all such safety focused process standards require that software safety functions be identified and specified in system safety requirements, classified with regards to their criticality, designed with due reference to that classification and developed and verified to show to compliance with the system safety requirements. Best practice This commonality of purpose between safety and security is evident in many other ways. For example, in the high integrity markets, safety focused process standards are cited by many authorities as a sound basis for security critical software, provided that security risk considerations supplement safety risk assessment. One such example is highlighted in the recommendations of the Automation Standards Compliance Institute. These suggest a Software Development Security Assessment is implemented with reference to existing safety focused process standards such as IEC61508, with best practice security measures superimposed 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 IEC61508 with ISO15408 (also known as the Common Criteria, with reference to the merged documents from which it was derived). 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 ISO15408 being highly analogous to the concept of Safety Integrity Levels adopted in ISO61508. When the time comes to develop code, both ISO61508 and ISO15408 cite coding standards as a means to achieve high integrity software. Examples of language subsets – such as CERT C, secureC and MISRA C:2012 – again show considerable overlap between the principles of security and safety focused development. Least privilege separation If functional safety requirements demand a defence against security vulnerabilities, then it makes sense to extend this principle of a common safety and security purpose by applying 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 provides an optimal approach to ensuring that such access does not compromise the security – and hence the safety – of the system. A traditional separation kernel is designed to ensure that 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 such that visibility is minimised to provide only that access which is absolutely necessary. Consider fig 1 as an example. The aim here is to provide security for safety critical applications such that they can run in an RTOS or as a 'bare metal' application like the 'trusted app' in the illustration. Applications such as Windows OS can interact freely with the Internet because the partitioning between it and the 'trusted app' means that any successful attack on the Windows OS cannot impact that 'trusted app'. Such an arrangement is only useful if the two partitions can communicate, but the nature of a least privilege separation kernel ensures that such communication is highly regulated and the security risk is therefore minimised. Other significant features include the adoption of full virtualisation within the partitions, rather than the kernel, thus avoiding a potential access point for any threat. This approach also minimises the size of the separation kernel itself and the independence of any device drivers from the kernel means that the separation kernel can be tiny – as little as 25k lines of code. The smaller this footprint is, the smaller the amount of shared code and data space between the partitions and the fewer opportunities for potential attack. Applied to a 'real world' scenario (see fig 2), this means 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. In this example, 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 they are seeking. But the safety critical plant control, protected by the separation kernel, will continue to function normally. In short, the safety function is fulfilled by the application of best practise security focused development. Conclusion Despite the traditional division between safety and security driven application development, there is plenty of evidence within the process and coding standards to suggest that there has always been considerable overlap between safety and security best practice. It is even possible to argue that they are close enough to lend themselves to the development of safe AND secure applications. The current drive towards Internet connectivity for more and more safety critical applications increasingly means that any security vulnerabilities are in fact safety issues too, and in these cases safety and security become indistinguishable – 'sicherheit' – making such an aim ever more desirable. Drawing on best security development practise to further address these functional safety issues is therefore a logical step. By applying least privilege separation kernel technology, remaining exploitable software weaknesses can be minimised, thus fulfilling the demands of security related safety requirements. Author profile Mark Pitchford is technical manager EMEA for Lynx Software Technologies.