Safety versus security
There is a certain school of thought that views safety and security as essentially synonymous, and therefore that the principles of safety engineering are directly applicable to that of security, and vice versa. You might caricature this belief as the management idea that all one needs to do to generate a security plan is to take an existing safety plan and replace ‘safety’ with ‘security’ or ‘hazard’ with ‘threat’. A caricature yes, but one that’s not that much removed from reality 🙂
While many of the principles underlying both disciplines do share common core concepts the unfortunate reality is that often the security and safety principles actually conflict in system design. As a large scale example, we’ve subscribed with a greater or lesser degrees of naivety to Postel’s law, in the building of the internet. While Postel’s principle is, in principle, a good thing intended to deliver robustness of behaviour from a security perspective it can be entirely unhelpful as overly liberal acceptance can be exploited, thereby introducing system vulnerabilities. You might have noticed the use of the word ‘naivety’ in the above example, in practice a slightly more sophisticated application would recognise that a trade-off exists and better balance the needs of safety against security.
The take-home from all this? Naieve belief structures that assume either that safety and security are orthogonal, or alternatively that they are essentially synonymous are unable to address these sort of issues effectively. The reality is that to achieve an optimal design requires a nuanced trade-off amongst various system attributes including safety and security.