This post shall give you an overview of methods to assess the cybersecurity risks of your products or services. We will go through the development of risk analysis and try to understand why every part is there and what you need it for.
Before we start, please be aware, this will not give you a one fits all approach or will cover the complete research from this field. Rather the goal is to make you understand what it takes to assess your IT security risks as well as prepare you to conduct basic risk assessments in the fastest and easiest way possible. So let’s directly jump in.

In the following Sections, I introduce and give examples for different approaches on how to get an overview of possible IT security threats to your systems.

Directly assessing risks

Throughout this post we will use and come back to one very specific use case. This will serve us as an example to better understand the single steps.

A developer uses his own laptop running the Ubuntu operating system to develop a web application for a company.
For this, he uses Visual Studio Code as a development environment and a mariadb database (SQL database) as part of his backend. The web application itself uses HTML, CSS, and JS on the frontend and PHP on the backend. For testing and the later deployment he uses an apache web server. Finally, the developer already knows about IT security and employs only secured connections using TLS1.2 and server-side certificates.

Web development use case

For a direct risk assessment, we could now try and start to come up with possible problems. Just by looking at the example description several problems come to mind:

  • A public exposure of the database may allow for unallowed data access.
  • A misconfigured web server may leak (confidential) data.
  • If the web application gets input from an end user to build up database queries, there is a risk of SQL injections.
  • etc.

After establishing that list, we can now rate the associated risk with each threat, e.g. on a scale from low to high.

This approach has a quite obvious problem. Because you can only come up with an extensive list of possible risks if you bring a lot of experience. Therefore, the risk analyst must have already a feeling on what might go wrong given this setup. This method, hence, can only be useful as a first guess in a very brief discussion of the overall system. For other settings, a more methodological approach is needed.

Asset-based assessment

As first step, many risk assessment methods consider the establishment of a list of assets which are worth protecting.
In our example from above such a list could be:

  • the developed code of the web application (may be intellectual property)
  • the private keys of the web server (during development and production use)
  • data stored in the database
  • data stored on the web server (machine)

STRIDE

Given this list, we could now think about possible threats to these assets. The probably most common tool to do so is STRIDE developed by Microsoft. STRIDE stands for

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege

With this information, we can start out our first basic method. Let’s put the assets in a formatted table.

IDNameDescription
A1CodeDeveloped code of the web application
A2DKeyPrivate key of the web server (development)
A3PKeyPrivate key of the web server (production)
A4DBData stored in the database
A5WSData stored on the web server (machine)
Assets in our example.

Threats

For each of these assets, we can now evaluate whether the STRIDE threats apply. Let’s do this.

AssetThreatDescriptionRealistic?
A1SSpoofing of codeHow would you spoof this? — not really…
A1TTampering with codeCould be possible with a manipulated compiler, operating system or development IDE.
A1RRepudiation of the codeAs the code in our example is not signed or anything comparable by the developer — yes.
A1IInformation disclosure of the codeA manipulated IDE might upload (parts of) the code to untrusted repositories.
A1DDenial of service of the codeThis would assume that there is no backup of the development code. With current versioning systems most of the times being used, this is rather unlikely.
A1EElevation of privilege of the codeWell, that does not make sense.
A2SSpoofing of the DKeyYou cannot spoof the private key. It’s unique and a different key would not match the server certificate.
A2TTampering with DKeyA manipulated private key would not work.
A2RRepudiation of DKeyMakes no sense.
A2IInformation Disclosure of DKeyYes, then all development tests could potentially run against a wrong test server.
A2DDenial of Service of DKeyThis might only delay testing of the web application. Not dramatic.
A2EElevation of Privilege of DKeyMakes no sense.
Threats to the system.

With this list of threats we can now once again rate the risk associated with each threat qualitatively on a scale. Like in the previous example, we still need to assess this with our experts’ knowledge.

Cumbersome threat lists

Well, ok. I cheated a bit. After only two assets I got exhausted with writing up the threats. When reading through them, you might have noticed a lot of them actually do not really make sense. This is because some of the threats, like Elevation of Privilege of a private key, simply do not make sense. So, if we want to get through this faster we need a better filtering on where to apply which of these threats. I must notice, a lot of people also use violated security goals instead of STRIDE. Then, we would have

  • violation of confidentiality (information disclosure)
  • violation of integrity (tampering)
  • and violation of availability (denial of service)

Meaningful threats

While the list of possible threats is then reduced to half the size, for larger systems this still does not solve the problem of a long list to go through.
In order to filter this list even more let’s think about when the different proposed threats are actually relevant.
Spoofing happens during data transmission. Either the sender or the receiver could be spoofed.
Tampering applies to data in transit, data stored at locations, as well as to functions or processes. Here, a function or a process shall be the logical unit which utilizes and possibly transforms data at any location.
Repudiation can happen if data has changed or was transmitted.
In these two cases, also information leakage may occur.
Denial of Service applies to data transmission and functions or processes.
Finally, elevation of privileges does not apply to the system under evaluation but rather to the attacker. It describes an entity carrying out an activity which it was not authorized to. This either requires tampering or spoofing with the system or an authorized user-action combination which becomes unauthorized under certain not modeled constraints.

Goal-based assessments

Before we continue with the next method I want to mention another approach to identify threats to your system which is quite similar to the previous asset-based assessment.
Attack trees are an already long-known method to analyze the steps an attacker must perform to reach a goal. In our example we can define different goals of an attacker, e.g. implementing a backdoor in the web application. So let’s think about how he can achieve this.

attack tree
Part of an attack tree.

Ok… I admit. Once again I cheated and do not provide the full attack tree but only an excerpt so that you get the idea. Except for the topmost branches from the and node all edges indicate alternatives. To implement the backdoor the attacker needs to get access to the code and have some backdoor code available. All other possible steps have several alternatives to reach these to sub-goals. Compared to the asset-based assessment method, this approach yields a much more fine-grained analysis of the system and potentially shows you already the easiest way for an attacker to break your system.
However, it answers a slightly different question. An attack tree explains how an attacker might reach his goal but not what his goal might be. For the identification of possible goals an asset-based assessment is way more suitable. But attack trees are then a perfect companion for your asset-based assessment if you want to better understand how your assets might be attacked, which controls you may introduce and how hard an attack actually is.

Model-based assessments

So, in the previous sections we explored that for a better mapping of threats we can rely on basic assumptions about the STRIDE threats and refine our system model to data exchanges, stored data, senders, receivers, and functions and processes.

With these refinements, our model now looks a bit more detailed.

IDEntityDescription
E1VS CodeDevelopment Environment
E2WebserverApache
E3DBMariaDB
E4UserEnd-user of web application
E5DeveloperDeveloper of the web application
Entities involved in the system.
IDDataDescriptionStored at
D1DKeyPrivate key of the web server (development)E1
D2PKeyPrivate key of the web server (production)E2
D3DBData stored in the databaseE3
D4WSData stored on the webserverE2
D5CodeDeveloped code of the web applicationE1, E2
D6WebsiteWebsite evolving from code and DB content
D7InputUser input to websiteE2
Data stored at different locations in the system.
IDData FlowSenderReceiverData
F1Developer → VS Code: CodeE5E1D5
F2VS Code → Webserver: CodeE1E2D5
F3Webserver → User: WebsiteE2E4D6
F4User → Webserver: InputE4E2D7
F5Webserver → DB: InputE2E3D7
Data flows between entities of the system.
IDDescriptionLocationInputResult
G1Private key generation (development)E1D1
G2Private key generation (production)E2D2
G3Website generationE2D3, D5D6
G4User input ingestionE3D7D3
G5DevelopmentE5D5
Functions and processes generating or manipulating data in the system.

Advantages

While writing up these tables does not take any effort away compared to the asset-based method, it will serve us quite a bit when rating the risks. First of all, we get a way more detailed picture of the system under evaluation and effectively enable others to understand our reasoning about whether and where one of the STRIDE threats applies. Second, we eliminate many of the previous meaningless threats which did not make sense. And most important, our threats automatically become more granular what makes them easier to asses. If you think about it: it does make a difference — concerning a threat’s likelihood — whether you try to manipulate (tampering) the developed web application code (D5) while it is at rest on VS code (E1) compared to when it is transferred to the web server (F2).

Disadvantages

On the other hand, this model-based assessment requires some efforts in advance to construct the needed system model. However, from my experience I strongly suggest you go this route. Often it is this very step which already shows developers and stakeholders their weaknesses. Especially in big companies it is more often the system complexity which introduces IT security threats instead of missing knowledge.

Until now, we covered a lot of state-of-the-art methods. In the next part of this new series we will touch upon more technical details of the approaches and develop a template for assessments.