If your business relies on computer technology or the internet, the question is not if/ whether you have cybersecurity risk, but how much risk you have and how well it's addressed.
First, Let's Define Risk
In everyday life, we understand risk to mean "potential loss". For instance, the risk to our home due to a flood or a robbery, the risk to our kids if they're in the park alone at night, or the risk to a cyclist who's more exposed on a busy road frequented by cars. In those examples and many others which you've likely thought of, we think of two things. One is the probability of harm and the second is the impact of that harm. With the cyclist for example, there's a greater chance of harm on a busy road frequented by cars, and that harm is also likely to be severe.
Risk in the cyber world is no different, the same principles apply, and are simply described and addressed in the cyber (or computer tech/ internet) context. As such...
Cybersecurity Risk for a Business can be defined as the potential for loss of operations, trust, reputation, or profit due to a cyber attack.
We also include two similar definitions from Brook S.E. Schoenfield (Advisor to Resilient Software Security)* and Jack Jones** at the end of this post.
Why You Should Care
Any business that relies on computer technology or the internet has cybersecurity risk. And considering our definition of cybersecurity risk above, it becomes evident that the handling of cybersecurity risk can be critical to the success or failure of a business.
How You Can Assess Your Cybersecurity Risk
Assessing cybersecurity risk is really about taking a good look at your tech. This includes your software, hardware, networks, data... and never forget this, your people!
There is a holistic process of evaluating your technology, people, and environment to identify threats (described in prior post) and measure their risk. That process is called a Threat Model (i.e. a model of the cyber threats to an organization and its systems). Threat modeling is a service offered by Resilient Software Security, and we'll cover it in a future blog post. For now though, let's explore the process of measuring the risk of the threats that would be identified in a threat model.
As we described at the beginning, there are two primary things we usually consider regarding risk in our every day life, the likelihood and the severity. Similarly, for each threat or potential area of cyber attack to our business, we consider two things:
Probability: of a successful attack, considering the type of technology we are using, the weaknesses it has, the protections we have put in place already, the training or lack of training of our people etc.
Impact: of a successful attack to our ability to operate, our reputation, trust, and profit.
Risk then becomes = Probability * Impact, for each potential threat.
To quantify probability and impact, you can use a simple scheme like High (H), Medium (M), and Low (L). You can that too for quantifying the resulting risk. The matrix below gives an example of mapping probability to impact to measure the risk.
Probability: H M L
M L L L
H M L M
H H M H
Impact
Let's take some sample reads through the matrix:
If one of probability or impact is High and the other is High, the risk is High
If one of probability or impact is is High and the other is Medium, the risk is High
If one of probability or impact is is High and the other is Low, the risk is Medium
As you've probably noticed, this can be subjective and requires technical and organization understanding to measure probability, as well as business insight to measure impact.
An Example - Photo Sharing Mobile App
Let's assume you run a photo-sharing mobile app that allows your users to share photos with restrictions on who can access those photos. You app has a backend server which exposes an API that allows your mobile app to authenticate your users with your backend system to establish a new user session.
A threat that should be considered in your system is the potential for a cyberattacker to use automation to send username and password combinations to your API in an attempt to use brute forcing to discover and compromise your users' accounts.
In this example:
The probability of the attack happening is High.
The impact of a user account compromise on your app is likely to be HI
And so the resulting Risk is High.
A Framework for More Consistent Risk Rating
As I mentioned earlier, the risk rating method described in the preceding sections has a high degree of subjectivity, which means the score can vary depending on the perspective (or experience) of the person doing the assessment.
In attempt to address that, Microsoft introduced the DREAD Risk Rating method a few years ago. It means:
Damage Potential: How much are the prized information assets or computing resources of your system or organization affected?
Reproducibility: How easily can the attack be reproduced, recreated, or copied??
Exploitability: How easily can the attack be launched?
Affected Users: What's the number of affected users?
Discoverability: How easily will the weakness in your system be discovered by a potential attacker.
Similar to the approach previously described, you a simple scheme like High (3), Medium (2), and Low (3) to provide your response to each of the DREAD questions.
Afterwards, count the values (1-3) for a given threat. The results can fall in the range of 5-15. Then you can treat threats with an overall rating of 12-15 as High risk, 8-11 as medium risk, and 5-7 as low risk.***
It's important to call out that DREAD also has subjectivity, but the questions asked allow for better consistency across various uses and scenarios. Also, some users of DREAD use it without the Discoverability component since that can be abused to ignore real issues that are supposedly harder to discover by attackers.
How To Address Risk
There are three primary ways to address cybersecurity risk, as described below ****:
Accept the risk: This means that nothing is done to counter the threat; these become weaknesses in the system that should be disclosed to customers or other stakeholders. Typically, risk is accepted when the relevant threats are extremely unlikely to occur or when the cost of the attacks are expensive to perform and to mount the attack on the system would be more costly than the benefit achieved by the attacker.
Transfer the risk: Document and transfer the risk to some other party in the system, for example, the system integrator, the customer, or the end user. An example of a transferred risk could be a power loss that shuts down a consumer/customer operated system. This risk is transferred can be transferred to a customer, by recommending that they add a battery backup to prevent sudden power loss.
Mitigate the risk: Add a technical or process feature to your system(s) that completely prevent the relevant threat from being executed by the attacker.
The choice of those three and how that choice is implemented is highly dependent on your context, that is your business, your technologies, and the threats that are relevant to both.
Finally, Automation Helps, But Is Not A Holy Grail
There are many tools on the market that are designed and "pitched" to bring some automation to different areas of cybersecurity risk assessment and mitigation. For example, there are some tools that help with risk assessment and mitigation for software, and there are some for networks. However, no tool will be the Holy Grail that magically does all the work for your organization. Interestingly, such tools when acquired, become additional parts of your cyber systems that should considered for your overall cybersecurity risk.
Yes, automation tools can help with cybersecurity risk assessment and mitigation, but they will have gaps and even in their areas of strength, the purchasers, deployers, and users of such tools must understand cybersecurity risk to stand a chance of benefiting from their investment.
Extra Content for Interested Readers
What Risk Is Not
Given the overloaded terms that are often encountered around cybersecurity, it's important to clarify what risk is not.
Threats which we define in another post are components of understanding risk, but are not in themselves risk. Likewise, vulnerabilities which are the weaknesses in a system are also used to understand risk, but are not risk.
Other Definitions of Risk and Our References
*"Risk is an event with the ability to impact (inhibit, enhance, or cause doubt about) the mission, strategy, projects, routine operations, objectives, core processes, key dependencies and/or the delivery of stakeholder expectations."
(Schoenfield, B. (2015). Securing Systems: Applied Security Architecture and Threat Models, p.101. CRC Press)
**"Risk is the loss exposure associated with the system".
(Jones, J.A. (2005). An introduction to Factor Analysis of Information Risk (FAIR). Risk Management Insight LLC)
*** DREAD Introduction
(Mier, J.D., Mackman A., Dunner, M. Vasireddy,S., Escamilla, R., and Murukan, A. - 2003. Microsoft Corporation)
**** How to Address Risk
(Fagbemi, D.D., Wheeler D.M., and Wheeler J.C. (2019). The IoT Architect's Guide to IoT Attainable Security and Privacy. CRC Press)