Maintaining the highest level of system security results in significant increase in cost and duration of the development process. How to evaluate the security standards – explains Maciej, our expert in life-saving software systems.
Maintaining the highest level of system security results in significant increase in cost and duration of the development process. On the other hand, not all systems are equally critical and even within one system several sub-systems requiring different security standards can be distinguished. Take a car as an example – a brake system failure will have much more dire consequences than a radio malfunction. Clearly, developing all systems under the same requirement set would be unnecessary and counterproductive.
That is why the IE61508 standard, which lays out the rules for production of safety related electronic devices, defines four Security Integrity Levels:
For each level the acceptable probability of an accident occurring have been defined under two categories: PFH – Probability of dangerous failure per hour, and Probability of dangerous failure on demand.
What the numbers say is that for the SIL4 if we assume 1000 devices operating for 10 years constantly, one critical failure can occur. Of course, it does not mean that the failure must necessarily lead to an accident.
The rules stated in the IEC61508 standard have become the basis for other regulation sets for various industry fields. Example being the railroad standard DO-178 defining the Design Assurance Level:
In the automotive industry there are Automotive Safety Integrity Levels defined by the ISO26262 standard, where ASIL A and SIL D are counterparts of the previously mentioned SIL1 and SIL4 respectively.
In the field of Medicine the levels have been defined in a different way by the EN62304 norm:
The level of a given system’s security should be decided after a thorough analysis of security related requirements and when a risk analysis has been performed.
If several sub-systems are distinguished within the project, it needs to be proven that the failure of a lower-level component does not influence any components of higher security levels. For example, it is not possible to assign two different security levels to two separate parts of a program when they are executed by the same processor.
In order to guarantee proper separation in this case virtualisation techniques need to be utilised or the less critical modules should be moved to a different processor.
Check out the case study about safety critical system which equired compliance with CENELEC SIL-3 and SIL-4 standards for one of our clients: -> Read more!
