To simplify it, risk is the probability of something bad happening. The more serious the impact (or consequence) when it happens, the more serious the risk.
In the world of information security, the general accepted definition of risk is the following equation:
Risk = Threat x Vulnerability
So, let’s stay with this definition, for now; there is more to risk than this, but we will stay simple. In this equation there are two variables: threat and vulnerability. If we want to get rid of a risk, then, we either need to make a threat non existent, or remove vulnerabilities that can result in the threat becoming a reality.
For example, if there is a threat of a SQL Injection in the login form, and the form doesn’t sanitize and validate its input or you don’t have some further checks in the code before the request hits the database, then the threat is valid because the vulnerability is true, making the risk true. On the other hand, if you apply, for example, OWASP SQL Injection prevention best practices then you begin to handle the vulnerabilities that can lead to a SQL Injection, hence making the risk lower. You removed the things that could lead to the threats being real.
But we can also focus on the threat, in this case if we don’t have an input form, then the threat of SQL Injection is lower or zero, so the risk then becomes a non issue. The threat in this case wouldn’t apply here.
It’s important to note that, generally speaking, it is harder to bring threats to zero; threats are more often out of our hands. Vulnerabilities, however, are easier to work with. Focusing on solving and mitigating vulnerabilities will greatly increase the ability of lowering risk.
Acting with risk is really about reducing your vulnerabilities.”
— Gen. McChrystal, Risk: A User’s Guide.
We need to assume that there is always risk, and that we will be impacted by it. It is critical that we do get in the habit of assessing the probability of risks happening, and their impact. However, it is also important to mention that it is very hard (and costly) to bring all risk to zero. We still need to make decisions, and take actions, even if the risks are not mitigated, but if we know about the risks, and we understand them, then at least we can work on building mitigation, monitoring, and resiliency into our systems and software. Yes, system and software security is more than just lowering vulnerabilities... There is resilience... But that’s a topic for another post.
To keep the definitions simple let me explain a risk assessment as a process used to identify potential security issues and understand what could happen if that issue occurs. This process helps understand and prevent costly security vulnerabilities, information disclosure, and architectural issues, to name a few of the benefits.
As I mentioned above, there will always be risk. We can’t mitigate all risk, either because it’ll bring the business to a standstill, or because there is no solution (or it is too costly, in time or money).
We will likely have to live with risk, so a good way of managing that risk is needed. There are many ways to do this, and frankly it’s beyond the scope of this article, but to keep it short and simple, risk management is essentially understanding the level of risk we are willing to live with, and how, over time, we can make the risk lower and lower.
It’s not a complicated problem, but it is a complex one that has a lot of business input thrown at it.
Phil Venables has a great article about this, if you are interested in reading.
How Do We Assess Risk?
The more experienced you are, the more second nature risk assessments are. You are constantly assessing risk, even if you don’t realize you are doing it. Because of your experience, you know your field, you know what generally speaking can go wrong, and you have the ability to think beyond the usual suspects and go check other things that maybe could go wrong.
Yes, again, this calls for experience and gut feeling. However, there are simple tools to help you discover risks and understand them, if you have less experience.
One of them is the use of micro threat models to assess risk. I call them “micro” because these are light-weight versions of threat modeling. A threat model usually decomposes a system or application, creates diagrams, looks at boundaries, lists possible bad actors, understands the threats, and lists controls to prevent them. It’s a great tool, but it’s heavy when you need to perform fast and light calculations.
A micro threat model, on the other hand, allows you to quickly list the elements of your design or what you are working on, ask “what can go wrong”, and calculate risk based on the chances of that happening.
You can perform micro threat models using a simple text editor, a spreadsheet, or even pen and paper. The format is simple.
Format 1: simple text
List in a text file:
- Asset or the element you want to assess from your system or app
- Answer what can go wrong
- The probability of that
- The impact if it does happen
- The overall risk
What can go wrong?
SQL Injection can extract all the usernames and other information from the database.
High - SQL injection these days are automated attacks that an inexperienced hacker can perform.
Critical - having this will likely enable attackers to have access to other parts of the systems and/or perform other attacks based on the information extracted.
Format 2: table
Create a table with the same elements as the text format:
You can list all risks this way and it’ll give you a prioritized list of what you need to address first.
Another way of assessing risk is using common sense and experience to ask questions and calculate risk based on that.
There are some handy tools and methods that can help here.
Both can be applied to software, and to some degree systems in general, but you need some experience with risk assessment and management in order to use these.
The more we can understand the risks we are dealing with, the better we’ll be able to make better decisions, and address them.
Sometimes leadership will have to live with the risk, sometimes the risk must be addressed before being able to work on the remainder of the application. However, the fact is that, the more we understand the risks, the more we will be able build a more stable products, adding security and resiliency to the mix.
Assess risk, manage it, and always ask “what can go wrong?”