Handling cybersecurity with SOTIF – A question of luck?

Nowadays almost everything is interconnected. The so-called “Internet of Things” or IoT for short. Your fridge sends a shopping order to the supermarket when it is empty, your car drives itself while you are watching your goldfish via webcam – communication is everywhere.

Of course, this encourages criminal elements who want to interact and benefit from those connections. Highly sophisticated, well-trained individuals, hacking on their computers right into your private sphere. No one knows them, they live in the dark web and you cannot do anything against them.

The only good thing is, that most developers know exactly how to deal with them … don’t they?

I assume that this is the general understanding of cybersecurity. And in my humble opinion, this is a misunderstanding.

First a short reminder: Security is freedom from, or defined resilience against, potential harm (or other unwanted coercive change) caused by others. And Cybersecurity is the protection of computer systems …

To get a better overview, these are the definitions from different standards:

General (NIST – Framework for Improving Critical Infrastructure Cybersecurity):
Cybersecurity: The process of protecting information by preventing, detecting, and responding to attacks.

Medical Products (AAMI TIR57):
Data and systems security: Operational state of a medical device in which information assets (data and systems) are reasonably protected from degradation of confidentiality, integrity, and availability.

Automotive (ISO SAE 21434):
Cybersecurity: Condition in which assets (something for which the compromise of its cybersecurity properties can lead to damage to an item’s stakeholder) are sufficiently protected against threat scenarios to electrical or electronic components of road vehicles and their functions.

Industry (IEC 62443-1-1):
Cybersecurity: Actions required to prelude unauthorized use of, denial of service to, modifications to, disclosure of, loss of revenue from, or destruction of critical systems or informational assets.

Misunderstanding #1: Form of attack

As can be seen in the definition of cybersecurity it is the protection of the system. Nowhere it is defined what the system is to be protected against. And that is the crux – it is just defined as protection against the outside world.

Therefore, the attacks can happen in any form that the system can perceive. For example, a self-driving car works with cameras and monitors the street ahead. If there is a 3D painting revealing or – even worse -obfuscating an obstacle the car will react – or in case of obfuscating not react. In Austria, artificial cops have been placed alongside the road   to encourage drivers to reduce their speed. A self-driving car can identify this cop as a pedestrian intending to cross the street and hits the brakes …

This leads to the next misunderstanding:

Misunderstanding #2: Only criminal organizations are hackers

A street artist is no criminal mastermind nor is the police of Austria. And this is all well explained in the standards for cybersecurity (ISO/SAE 21434 “Road vehicles – Cybersecurity Engineering”) in the threat and risk analysis (TARA) at the beginning of every project with the question “Who might corrupt or manipulate your system?” And the different options are of course criminal elements, terror organizations, or even hostile countries – but also people fiddling around with your system, destabilizing it intentionally or even unintentionally.

One good example of intentional fiddling and manipulation is the Tesla orange. With this “hack” the system of the autopilot was and still is corrupted … even without any software or years of studying electronics.

The main problem

When defining your intended functionality, you should be a clairvoyant to foresee all potential hacks. The creativity to fiddle is overwhelming. And most of the time the reasons for it are “I do not like that feature, how can I get a workaround?” and “Am I able to manipulate it and start something funny or cause havoc?”.

First, the bad news: you will never be able to foresee all of these intrusions or misuses.

Second, the good news: nobody expects you to. What is expected is that you think of the actual threats (in your TARA at the beginning of your project) and monitor your product during its lifetime and react to new threats.

And it is essential, that the TARA will be performed by people with different backgrounds and experience. The ISO/DIS 21448 (Road vehicles — Safety of the intended functionality/ SOTIF) describes it very well: To reduce the unknown hazards and turn them into known hazards. How can your intended functions be influenced or changed – unintended, by misuse, or on purpose?

So, the bottom line is: Know your system and its intended functionality.