Understanding why risk management is important
In this book, we've going to keep referencing risk. To ensure we're on the same page, it's worthwhile taking the time to define and discuss various risk management topics, and why they're important.
First, we're going to define risk as the potential for loss. The components that make up risk are assets, threats, vulnerabilities, likelihood, and impact, each of which we will define and explore in this section, and continually reference throughout this book.
For the time being, information security risk can be summarized like so:
Imagine that by understanding the likelihood of a threat exploiting a vulnerability, combined with the impact of that threat exploiting that vulnerability, you can measure the level of risk associated with that security event. Your organization faces many risks on a daily basis, and those risks may or may not already have risk scores and annualized costs associated with them, as determined by performing a risk assessment to determine the impact of the threat exploiting a vulnerability, and the likelihood that the threat will exploit that vulnerability.
Consider the following simplified formula:
Risk = Impact x Likelihood
Organizations are interested in minimizing their potential for loss through a process called risk management, by which they identify, evaluate, and prioritize risks, and implement layers of mitigating controls that reduce the impact and likelihood of a loss.
So, why is risk management important for information security? Risk management isn't about removing all the risk an organization faces, or adding bureaucracy for bureaucracy's sake. Risk management provides transparency and accountability into the daily operations of an organization, and aligns the organization's risk with its strategic objectives. Risk management also helps organizations prepare for adverse events that could negatively impact its success.
In the modern context, information systems are central to the ways in which most organizations do business, and so information security risk management is becoming a larger part of every organization's overall risk management focus.
In order to cover risk management effectively, it's important to go into a few key risk topics and definitions first. Let's get started!
Understanding assets
Let's look at that long sentence I wrote out earlier to summarize risk:
Looking at the structure of what comprises a risk, we can see that, first, you cannot have a risk without an asset. Your organization has many assets: digital assets, physical assets, and even reputational assets. For this book, I'm going to use the definition of assets as anything of value to the organization. Different assets have different risks associated with them, because different assets have different threats, different vulnerabilities, and different levels of impact in the event of loss of, exposure of, or making modifications to that asset (or the processing it performs).
Now, there are some company assets that will not have a significant information security risk associated with them, such as a box of T-shirts from a company picnic a couple years ago. Let's focus on documenting your organization's "crown jewel" information assets into an asset register to start; we can always add more assets to the register as we go along.
An asset register or asset inventory is a document that lists the organization's assets. Creating a document like this (and keeping it up to date) is going to help with various aspects of the risk management process, because inside this asset register, you will begin to structure various organizational aspects surrounding how assets are handled, and identify risks based on those assets. The information inside this document could include asset owners, asset classification, asset value, and so on.
Before we get too complex, I believe it's worthwhile to show how we might create an extremely simple asset register for our organization. It might look something like this to begin with:
Essentially, in this document, we're going to give each asset an ID, a short name, a description, and any notes that may be associated with that asset. We could add columns for "asset owners," "asset classification," or "asset value" as required. It depends on your requirements and how you would like to structure the various documents we will cover in this book.
If you're looking for some inspiration for what assets you might put into your asset register, some example information assets could include information systems, such as servers, software, payment terminals, routers, or laptops. However, this can also include information itself, such as datasets, images, blueprints, formulas, or other intellectual property or (IP), for example.
Now that we've covered assets, let's move on to understanding threats.
Understanding threats
Looking back at that one long sentence about risk, we can see that you also cannot have a risk without a threat. Threats and their threat actors (the perpetrators of acts that represent threats) could include malicious hackers gaining access to company records, a rogue employee selling secrets to competitors, severe storms obliterating your office locations, or the nice lady in accounting opening a PDF file that releases ransomware across the entire organization's estate.
Each asset can have multiple threats associated with them, and each threat actor could have different goals and abilities, which means they can utilize different methods of exploitation. With different methods comes different likelihoods and different mitigation controls, so each viable threat should be considered for each asset in an activity called threat modeling, where we document the various threats and threat actors that the assets at our organization face.
To start with a default set of threats, consider the following: malicious outsiders, malicious insiders, and accidental insiders have threat actors, while environmental threats do not.
When thinking about threat actors, consider their ability, their interest, and their tactics. Taking malicious outsiders as an example, you could also get more detailed and split them up further; for example:
- Sole actors could be experienced or inexperienced, but with the public release of sophisticated tools from major hacking groups and governmental organizations, even those actors that used to be called "Script Kiddies" are going to be able to access or change your information, or even make it unavailable.
- Group actors are a potentially distributed team with funding, and could include hacktivists, criminal organizations, or even competitors.
- State-sponsored actors have time, state-sponsored funding, and state-sponsored tools, and are the most sophisticated threat, but they have specific interests that might not be shared with the other two groups.
Let me stress that there is no clear-cut "right way" to do this, so you need to make sure to create something that suits your organization. If state-sponsored actors aren't currently a relevant threat actor for your organization, you could create a placeholder for them in your documentation, and note that they are not currently a relevant threat. In the future, if a previously non-relevant threat does become relevant, you already have the placeholder ready to be changed with new information.
Another thing to mention here is that (obviously) weather patterns such as hurricanes and floods don't have threat actors, and therefore don't have interests or tactics. However, they do have the ability to impact information security, through availability outages or outright data loss. You can understand their likelihood and if your assets are affected by them as a result. Floods cause damage in basements, which means the information assets that are stored in your basement have a higher likelihood of being affected by that threat.
We're going to look deeper into threats, including the various threat actor categories and their motivations, in Chapter 3, Designing Secure Information Systems, so let me get back to discussing the basics around risk.
Understanding vulnerabilities
Now that we've covered assets and threats, the next piece of a risk we must understand is their vulnerability. You can't have a risk without a vulnerability due to the following (as we've mentioned previously):
"Information security risk is the potential for loss, as measured through the combined impact and likelihood of a threat exploiting a vulnerability in one or more information system assets."
So, with vulnerabilities, we're talking about the weakness of an asset that can be exploited by a threat. Vulnerabilities can vary by asset category, with hardware assets being susceptible to overheating or wear and tear, while software assets can be vulnerable through flawed code. We will delve deeper into what constitutes a vulnerability and how to mitigate them throughout this book, so I'm going to stop myself at that simplified definition before going down that rabbit hole.
We have now covered some of the key concepts in risk management, and why risk management is important as an information security professional. The next thing I'd like to cover is how we might actually perform a very basic risk assessment in practice, and how we can use risk assessments to understand the risks that our organization faces.