Information security risks cover any risks that adversely affect the CIA of data. Such risks may be technical in nature (e.g., unpatched or misconfigured systems) or may be caused by management failures (e.g., lack of technical risk ownership, lack of
organizational accountability or failure to find and fix root causes of technical risks). Establishing a consistent and comprehensive risk management methodology based on commonly applied terminology can help information security teams enhance awareness throughout the organization.
Types of Information Security Risks
Practicing information security requires balancing the risks associated with each of those elements, because they may be in tension. For example, the more an enterprise concentrates on protecting the confidentiality of data, the more likely such data
will be less available for use when needed. Conversely, organizations can emphasize availability by giving a lot of people access to data, but that increases the risk of loss of confidentiality. (Cybersecurity is information security applied to data
in electronic form. Information security is the broader term – it covers data even in paper form.)
Risk involves two elements: the probability of an event, and the consequences if the event were to occur. A very high risk usually means the probability of the event is high and the consequences are severe.
There are three types of information security risks:
- Absolute risk, which is determined without considering the effects of mitigating measures.
- Residual risk, which is the same as absolute risk, but it does take into consideration any mitigations that reduce the risk. For example, a mitigating measure may be the use of full-drive encryption. The absolute risk of having a laptop stolen may be
high, but the residual risk is low, because the data on the laptop is encrypted (assuming, of course, proper encryption is done, and the laptop is shut down at the time of the theft).
- Exposure risk, which is determined by assuming the probability of occurrence is 1. In other words, what is the worst-case situation if the event occurs?
Understanding Threats and Vulnerabilities
Threats and vulnerabilities must also be fully understood.
- A threat is something posed by a miscreant who wishes to do harm to the enterprise. Examples of threats include criminal organizations, malicious insiders, disgruntled former employees, intelligence services of hostile nations, etc. Sometimes these are
called “threat actors” instead of threats; in that case, threats are usually defined as mechanisms of attack (such as SQL injection) used by the actors. Either way, a threat is the source of malicious action.
- A vulnerability is a weakness in the cyber defenses of the enterprise. Examples of vulnerabilities include unpatched systems, old legacy systems that do not meet current cybersecurity standards, improperly configured systems exposing weaknesses that can
be exploited, etc.
Usually threats and vulnerabilities go hand in hand. If there is a threat but no vulnerability to exploit, the threat may not be a problem. This may be the case if external hackers are trying to attack, but all your systems are fully patched, leaving
no easy avenue for them to use.
In general, the presence of threats or vulnerabilities increases risks (i.e., increases the probability of an event and/or the consequences if the event were to occur). If both exist, the risk increase is greatest.
Information Security Risk Management
Common misconceptions regarding information security risk management include:
- Spending to reduce risk is like buying insurance. When you buy insurance, you do so to “make yourself whole” in the event of an accident. But the insurance does not reduce the likelihood or severity of having an accident. Spending to reduce
information security risks usually reduces both the likelihood and severity of a security incident.
- Security risks are owned by the information security group. Risk ownership must align with the authority to act on the risks, which means such ownership belongs with the business process owners whose processes create or are affected by the risks. It is
they who decide what to do – when to bring systems down for patching, who should be granted what privileges for data access, who should authorize what actions, and so on. And they should decide which risks are to be mitigated, accepted (without
mitigation), rejected or transferred.
- Security risks are static. There is no such thing as a “steady state” when it comes to information security risks – risks are always getting worse over time, albeit at different rates. One cannot just spend resources to mitigate risks
and declare “victory.” Sadly, information security risks increase every day, owing to new or more virulent threats and newly discovered vulnerabilities. Staying at the same level of risk can require spending considerable resources.
A mature information security program recognizes this and requires active risk management, which means it keeps track of the worst risks and how they are being addressed (usually through mitigation). It also keeps track of lesser risks to see if they
have become more serious and warrant action. Additionally, the security program tracks mitigations, because too often, a mitigation is put in place but then later defunded because no adverse event occurred. The act of defunding the mitigation may
increase the risk it mitigated from a tolerable to intolerable level.
Elements of a Risk Management Program
Often organizations use a risk management program to help establish where they need to focus their information security resources. A risk management program usually focuses on:
- Identifying and rank-ordering risks. The list of information security risks the enterprise confronts, and most importantly, their rank-order relative to severity is often documented in the form of a risk register. Severity rankings should be premised
on residual risk, which considers any existing mitigation measures. As new mitigation measures are put in place, some risks will move down the list, since they become of lesser severity.
- Aligning executive concerns with the risks. The risks in the risk register must fully reflect input from executive leadership, including (often) the board of directors. This input is usually obtained by asking leadership what they are worried about concerning
the CIA of data and then translating those worries into information security.
- Ensuring each risk is owned. Every risk in the risk register should have an “owner,” a party in the organization responsible for ensuring the risk is properly addressed. Each should also have a “decision-maker,” who determines
what to do about the risk (i.e., accept, reject, transfer, or mitigate). The risk owner often (but not always) is the risk decision-maker for that risk.
Determining Risk Appetite Using the Risk Register
Determining the organization’s risk appetite from the risk register can be useful, and it is relatively straightforward. Specifically, the highest risks from the risk
register represent the risks the enterprise determines warrant the most attention. And, most importantly, those highest risks already reflect substantive input from the executives, so focusing on them is well aligned with what the executives want
to concentrate on. A risk appetite can be discerned by determining whether executive leadership agrees – or not – with the following thought process:
- The full list of our information security risks is captured in the risk register.
- That list already reflects what we, as executives and the board of directors, are most worried about regarding the CIA of data.
- We are averse to agreeing to any proposed action or activity that makes the worst risks even worse or moves lower-level risks into the category of the worst risks – UNLESS there are suitable mitigations put in place to avoid those effects.
Accepting Risks
That approach has an important nuance: It does not fully consider the benefits of accepting a risk, even if it were a high risk. It simply focuses on addressing all the worst risks in the risk register and avoiding any actions that may exacerbate them.
There may be situations where a proposed action has such significant business benefits, it is worth pursuing – even if you must accept very high risk in the process.
The way to address it in a risk appetite statement is to add a fourth paragraph which can be similar, but not necessarily limited to the following:
- Where a proposed action or activity makes the worst risks worse or elevates a lower-level risk to a high-risk category, and suitable mitigations are not available, ineffective, or prohibitively expensive, the impact of accepting the risk shall be measured
against the business benefits expected to result from the proposed action or activity. In rare cases, the latter may outweigh the former, but such a judgment shall only be rendered by senior executive leadership.
Inviolate Risks
Finally, the enterprise may have some risks it declares “inviolate,” i.e., the enterprise is unwilling to accept any actions that may worsen these risks. Examples can include regulatory risks (i.e., risks associated with a regulator citing
the enterprise for things such as quality of care, protection of patient data under the Health Insurance Portability and Accountability Act – HIPAA), and so on. Another example could be risks associated with violating the PCI Data Security Standard
(PCI-DSS), because that could imperil the use of credit cards for payment.
The enterprise should list such risks and include a final paragraph to cover them:
- For the following risk categories, no acceptance of any action that increases the level of risk beyond that captured in the risk register shall be permitted:
- Violation of requirements specified by law or by regulation, including those specified by the Food and Drug Administration (FDA) and under HIPAA, or those specified by the Federal Deposit Insurance Corporation (FDIC), Securities and Exchange Commission
(SEC), Office of the Comptroller of the Currency or state regulators covering financial institutions or insurance companies.
- Violation of requirements captured by contract, including PCI-DSS.
Risk Register Cautions
The enterprise risk register must truly reflect the full input of executive leadership, or the risk appetite statements will have no real effect. Leadership must be fully committed to what the risk register contains, and that can only happen if they have
a key hand in its formulation. You need to be able to trace risk register contents back to the “areas of concern” or “worries” the executives expressed, or the contents can be dismissed as just an academic exercise.
Elements of a Strong Risk Management Foundation
Understanding the scope of information security risks, and the terminology used to describe them, are critical to ensuring such risks are managed properly. The definitions provide the building blocks for identifying and discussing risk. Clearly defining
information security risks allow everyone, from information security professionals and IT professionals to business unit staff and executives to understand and discuss information security risks in a useful way and allow risk owners (typically business
process owners) to decide which risks to accept, reject, transfer or mitigate.
Ultimately, that is what you strive to accomplish: informed decisions by the business leadership on information security risks. Mathematically, the definitions are a
necessary, but not a sufficient, condition for that to happen. The final ingredient for success is a willingness by business leadership to engage in the risk management process – using the definitions to guide the discussion.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.