Tackling the Security Challenge

To help setting the scene it will be required to have a more holistic view of the security sphere. We seek to provide guidance on what and where to address by whom to achieve a sound security setup. To achieve this, it will be essential to assess several dimensions in parallel. Unfortunately our mind is not designed to cope with such a complexity at once. That is why our brain has established the unique capability of abstraction, which allows to tailor a task into smaller pieces. To help our customers, we were researching for some abstraction giving better orientation, but we were not able to find a suitable model, which allows to cope with the subject „security“ in a reliable and practical manner. That’s why we propose the following, two dimensional approach, which combines a static view with a time perspective to identify the complete setup.

We were researching for some abstraction To help our customers gaining better orientation, but we were not able to find a suitable model, which allows to cope with the subject „security“ in a reliable and practical manner. That’s why we propose the following, two dimensional approach, which combines a static view with a time perspective to identify the complete setup.

The subject to an attack shall be the first dimension to look at. If we do not know, what to protect, it will be difficult to get a grip on a sound protection. Please note: We are seeking a model for orientation in the security tech area, not setting up a particular security concept. In this abstract case, we may not choose a threat based approach because it would lead us nowhere. We suggest the following aspects:
Why do we suggest aspects? Well, software in general is assembled form different layers. But modern software engineering as well as the embedded world are not always following a structured layered approach. Thus talking about layers and therefor implicating a stack might lead to wrong assumptions. To prevent such misassumptions, we decided to call the differentiator „aspect“. It has more the connotation of looking at the same object, but from a different angle.

A bit of security or partial security is no security!

Especially in IoT-scenarios, it all starts with some hardware. In a device case, the hardware might be exposed publicly or, at least, will not only reside in a protected data centre environment. This is what we call the Device aspect. Events like the discovery of Meltdown (7, 8, 9) shows, that even hardware may have flaws that might be misused by a malicious attackers. Especially due to the massively growing spread of IoT, devices increase the attack surface of every organisation using or applying them.

Recently (summer 2019) Fraunhofer SIT researchers found in almost all VoIP telephones available on the market opportunities to remotely take control of the device and misuse this base for further malicious activities (10).

Further on the device will be somehow connected, either over the air or by a network cable or power cord to some kind of network allowing it to „call home”. The existence of such a media and the physical connectivity as well as the signalling shall be covered with the Physical and Data flow aspect. Here, as with all communication, the confidentiality as well as the authentication of the communication could be threatened.

Through this medium, the communication packets will be routed. The older readers might remember the OSI -model (5), and that is correct: Our Network Aspect addresses the packet routing and addressing, comparable to OSI Layer 3. But you will recognise that will not stick with the OSI-definition for long.

Next aspect to address is Transportation, as in OSI Level 4, where a communication will be assembled from the package streams. We stay with this differentiation as protection mechanisms differ between these layers.

But then we step away from OSI and define a Communications aspect, which represents the session oriented communication using a transportation, e.g. a particular REST call over HTTP/S, a FTP/S session or the DNS resolution. This covers all network stack typical responsibilities and thus is much wider scoped than the typical OSI layer 5.

Getting higher in the stack clarifies why it does not make sense anymore talking in layers. The next levels may vary depending on the approach used. Whether a bare metal hypervisor, e.g. Xen, is used or a level 2 hypervisor like VMware Workstation or VirtualBox on top of an operating system, makes a difference. However, in both cases it will be relevant to secure both worlds. So we suggested to introduce the two aspects Operating System and Abstraction.

All data is transferred to be processed by applications. The applications themselves are a major aspect as well. Authentication of users and their authorisation typically is handled here. So we have added a Software aspect.

Behind the application we find users, which make another perspective worth looking at. According to many studies, an overwhelming portion of incidents is caused by insiders. Whether by intent (very small portion) or accidentally, using too lax permissions, weak passwords, stale accounts left open or helpful cause the majority of breaches to happen(11,12). When designing security, the Organisational aspect should not be missing.

From a security perspective, it must be clear, that each of the aspects bears a risk of specific attacks. Thus your security concept will be required to monitor, protect and identify incidents for all of the perspectives.

Finally there are not only the cases of processing and communicating. We already touched this aspect with the device: Wherever data is stored, there is the opportunity of data access. Whether in memory or on disc. Persisting data opens the opportunity to copy, delete, manipulate or encrypt data. So adding the Persistence aspect adds the „data at rest“ perspective to the potential attack surface.

Putting all this together the security battle ground takes its shape. Following diagram outlines the dimension and gives examples for each aspect.

This might seem fairly complex. But not enough! Security is not a matter for a specific point in time. It will be relevant and changing over the complete lifecycle of an application, solution or product. When looking at the lifecycle of an application, steps such like DESIGN, DEVELOP, TEST, DEPLOY and RUN are common and do not require much of explanation. To include packaged software the second step shall be extended with the „customise“ action.

A bit more exotic might be the retirement step (RETIRE). Despite a growing acceptance that even software solutions are ageing and thus will need replacements a sound retirement planning is rarely seen (13). However, from a security aspect we highly recommend not to forget about it.

Finally the RUN phase is of particular interest to us, as most of attacks will happen while systems are in this phase. So we suggest to differentiate the RUN phase according the incident lifecycle into the following subphrases:
PROTECT:
This phase represents the default when entering the run stage. Systems are operational and will be protected. Several services and tools are dedicated to protect the running systems.

• IDENTIFY:
  Probably the most critical aspect of all is incident detection. Distinguishing the Controlling activity to collect some financial Excels across the company from a malicious attempt to steal financial data and alert only in the latter case is one of the most challenging aspects. Monitoring systems, identifying fraudulent oder malicious activity and triggering the next step is a key step in security.
• INSPECT:
  Whenever something is happening or has happened, the systems need to be isolated and examined thoroughly to identify the attack, probably intensions or even originator of the incident. It is crucial to learn about what has happened, why it has been possible and what has been targeted to protect from further attempts.
• RESTORE:
  Depending on the impact of the incident, probably impacted data needs to be restored or infected systems need to be replaced with sober ones to ensure business continuity. Whatever is required to return to operational state comes in this step.

Altogether these thoughts lead to the phases shown in the following diagram:

The “Security Matrix”

Combining the asset dimension as y-axis with the time dimension as x-axis, our now proposed Security Matrix appears. The matrix gives orientation to plan, arrange and prioritize all your security efforts. Make sure you have an answer for each of the fields or decide not care or cover explicitly. You may identify and derive KPIs per matrix field and you can be sure, you will ramp up a sound security management.

In addition to your own orientation, you may use the matrix to ask providers to assign themselves to the cells they cover. In our model we have a detailed functional overview for each of the cells that could and that should be covered. Comparing this matrix with your demand, will guide you through the marketing blabla and help to focus on the real differentiating aspects.