In some mission-critical scenarios the failure of a system is just too expensive or stakes involving human life or environmental damage are too high. Think of space rockets, an offshore oil-production platform or a car’s braking system. To protect products from this kind of failure, also called functional safety a framework / methodolgy is needed to control failure and test the system under consideration in before. This is called a development lifecycle. In relation to cybersecurity and protection of systems from beeing hacked or otherwise compromised, things are slightly different.
In functional safety, your goal is to find out how likely it is that components or systems will brake or fail. How much torque can my transmission withstand until a gear breaks? Or what is the probability that an electronic component such as a CPU or capacitor will fail within an hour (for the experts among you – this probability determines your safety integrity level)?
With cyber security, however, the probability of “how likely is it that someone will break into my industrial conrol system” or the “average loss of confidential data per hour” cannot be measured quantitatively. The capabilities, resources and tools of attackers are constantly changing and depend not only on technical skills but also on motivation, such as financial or even political goals.
Since security measures are expensive and you should not forget open doors, it is highly recommended to use a risk-based approach. Threat modelling and risk assessments provide guidance in a qualitative manner. In order to perform such an analysis correctly and to ensure security throughout the entire development process, rethinking from a “mechanical adversary” to an intelligent attacker must take place.
The manager of a penetration testing laboratory (the good hackers) recently told how they take things apart and make recommendations on how to close holes and vulnerabilities in the tested systems. However, in some cases it is already too late.
After completing your Fort-Knox building, you don’t want to have the insight that you forgot to install the vault. Some fans of the agile approach may not like it, but especially when it comes to hardware design like CPUs, a lot of thought needs to be put into a waterfall approach. This will save you from costly design mistakes.
The insights gained from threat modeling form the basis for a functional security concept, which is then translated into a technical architecture (HW & SW) – following a defense-in-depth and security-by-design approach. The idea is to close the big holes and the front door first.
In addition, failures and vulnerabilities should be prevented by following secure implementation guidelines and performing appropriate testing during development. Detecting gaps there is much cheaper and less critical there than in production. However, you can never be 100% sure. There is always a way in, if the attacker is willing to invest enough resources and thinking.
In the good old world of offline electronical and even mechanical control systems these were once designed and kept on running for decades. Think of a dusty industrial controller that has been forgotten in a dark corner of a production plant. In cyber security, the attacker landscape, and with it the risk, is constantly evolving, and vulnerabilities could be discovered throughout the operation. This is represented by the extended branch of the V on the right. In functional security, developers are basically out as soon as they hand it over to production.
You need to track the threat landscape and news about recent hacks and vulnerabilities in your systems through to the end of the product lifecycle. Think about the end of Microsoft’s Windows 7 support – a life cycle of 10 years. For products such as cars or industrial machinery, the time periods are much longer, which will certainly pose some operational challenges for the future of manufacturers of these products. Vulnerabilities must be managed and patches must be provided for very long years…
For safe and continuous operation of a gear box, an oil change or other maintenance may be necessary from time to time. From a development point of view, these measures can be covered by an operating manual. From the point of view of cybersecurity, more is involved.
To protect your system from attackers involves usually cryptography and just like in case of a physical vault this included keys. In the development of the system its needs to be defined how the cryptographics keys are managed properly – otherwise doors and gates are open. Additional organizational controls like the protection of source code or design architectures need to considered. You don’t want to equip the bad guys with an exact attack plan.
—
I hope you enjoyed reading this article. If a Secure Development Lifecylce is relevant for your organization – in connection with for example mission critial Industrial IoT and thus the development of automotive (ISO/SAE 21434) or industrial controls units (IEC 62443-4-1) – please don’t hesitate schedule an appointment or write my an E-Mail.
All the best, David!