How to perform a cybersecurity risk assessment in 5 steps
When assessing cybersecurity risk, be sure to consider the scope of the project, your organization's specific assets and leadership's tolerance for risk.
Because security decisions are made based on risk analysis, risk assessment remains an essential element of a cybersecurity professional's toolbox.
The goal is to provide a realistic, comprehensive picture of an organization's presence that extends beyond the IP addresses to all the factors around that, including processes and personnel. The result should be a plan that guides the organization into a thoroughly understood view of their risks and priorities.
Risk is a function of threat and vulnerability. For risk to exist, both threat and vulnerability must concurrently exist. Risk assessment implicitly implies this existence and assumes that something of value must be protected.
The protection of assets -- both tangible and not -- is key in driving the risk assessment process. Thus, an asset inventory analysis should precede a risk assessment.
Scope of risk assessment
Scoping the cybersecurity risk assessment is key to having a meaningful outcome. Where to draw the boundaries varies depending on the nature of the environment. Some key items to consider when scoping the work include the organization's public face and how far it reaches, thinking of connections that extend outside the organization. Depending on the company's attractiveness to adversaries, the scope of the assessment can grow to include infrastructure and supply chains.
Asset values and locations will drive much of the scoping and assumptions. For example, financial assets stored in an insured financial institution can be placed out of scope, since that institution manages the risk and liability. The path into the account for deposits and withdrawals, however, is clearly in scope. When setting the project scope, the boundaries and assumptions must both be clearly set and annotated.
And don't overlook the importance of time. Risk assessments are snapshots of a specific moment. While the validity time window for risk assessments is longer than the window for vulnerability assessments, the risk assessment also requires periodic refreshes. Procedures and personnel will change, as will technologies. All can change the risk profile.
How to identify cybersecurity risks
Once the assets have been identified and the scope has been set, the stage is set to start examining risks. Here is where a good security architect or the architectural report can come in handy. A top-level architecture view can provide the vision of how an organization ties assets and procedures into the mission. Understanding the organization's mission early in the process pays off in the ranking of findings.
A focus on the risks requires a full-scope examination, from the physical to the personnel and everything in between. When identifying risks, be as thorough with the physical and procedural risk factors as with the procedural and technologic risk factors. When determining physical risks, for example, consider the role of natural disasters as well as the human-made disasters sometimes associated with construction. Remember to consider access to the site and assets.
Technology might be the easiest part of the assessment. Security auditing products, such as the open source network-mapping tool Nmap, can quickly return results.
As for humans, it's fair to acknowledge that they make costly mistakes, but it is wrong to label them the weakest link, as is common in IT conversations. It would be more accurate to describe humans as the least-understood link.
People range from bold defender to willing saboteur to inadvertent helper. We all know that person who clicks the link, but we also need to consider the individual whose seemingly harmless social media post makes them an inviting target for an attacker. That person can be blamed, but, if no procedures are in place advising on social media behavior, the problem is also procedural. Thus, the risk assessment, much like the architectural planning, requires a much more holistic view of the organization.
Beginning with the mission statement, a risk analysis should consider which risks -- physical and virtual -- exist. Consider the functions, procedures, data and personnel that contribute to the mission and how each of these offers support. What risks exist at this level?
At this point, assets are being mapped to functions. This is also an opportunity to identify assets that might have been previously overlooked. Going deeper, which technologies provide support, and how is that support provided? How are they connected into the overall system? Which risks exist in the object, functions and interconnections? This scrutiny results in the application of a systems approach to risk analysis.
As the process of understanding the network continues, the risk assessor should also consider the overall footprint. Identify partner access, remote access and, when necessary, cloud connection points or endpoints. Know which tenants share the physical space and which cloud services are being used. IaaS should be of most significant concern, followed by PaaS and then SaaS.
If the service is managed by the cloud service provider (CSP), the service is out of scope. Even so, the cloud service-level agreement should be reviewed, and risks in the agreement should be addressed. An example of this is when a CSP has many self-managed tenants, in which case the client organization will want assurances based on fellow tenant vulnerabilities. A vulnerability in one tenant space that goes unaddressed can result in a compromise, in certain cases, of the hypervisor. Most CSPs run a tight ship. Still, in a what-if risk assessment, all situations involving data protection in the cloud should be considered.
In addition to the cloud, what other resources are shared? How are those resources attained? What about the supply chains to those resources? Which resources are unique or irreplaceable? How are they separated and backed up? NIST has compiled a comprehensive list of similar questions to ask about risk management.
Analyze risks and their potential danger
The process of tying risk to potential danger involves both technical and organizational knowledge. Each discovered vulnerability must be traced to every corporate function that it touches. In effect, the risk assessor creates a dependency model, typically depicted as a diagram, showing the path taken and where the vulnerability is invoked.
This risk analysis phase is another departure point of discussion. Determining the impact value can be subjective, objective or a hybrid of both. Objective impacts are typically mapped to dollar amounts, so risks to inventory can easily fit into this group. Subjective values, however, typically cover the intangibles, such as loss of trust, loss of personnel and even loss of intellectual property. These assets are typically more difficult to measure objectively.
In addition to asset value, workflow value should also be considered. An example of workflow valuation occurs when a vulnerability might not be associated with a high-cost event but is so frequent that numerous events are associated with the vulnerability. As a result, the remediation of that problem might result in extensive downtime or other lost availability.
Prioritize risks
Risk prioritization is an area of discussion in many cybersecurity circles. Some risk analysis, especially when a vulnerability scan reveals a problem, relies on predefined values provided by the software. This is a mistake. Risk analyses are unique to each organization, as is leadership's risk tolerance.
There's also the overselling of fear, uncertainty and doubt (FUD) in cybersecurity. Scare tactics can result in a quick buying decision, with the buyer needing constant reassurance. On the other end of this spectrum is the customer who might acknowledge problems and then ask, "But what's the chance it will happen to me?" This results in a discussion of threat actors, their methods and how they operate in specific industries. Even though this information is a part of the assessment, it does little to answer the question about the odds of the event occurring.
Don't put too much credence in the risk values that vulnerability software assigns based on usage. For example, a bug in a frequently used library might be assigned a high-risk score due to the library's frequent use by many software modules. This is problematic. Even a frequently used, error-prone library might never reach a critical asset. So, is the risk from that vulnerability a priority, or should the risk be downgraded?
It can be tricky to prioritize risk. The task will be based on the customer's and assessor's understanding of risk. The assessor can serve the customer well by offering a cost-benefit analysis where appropriate. When assets are more subjective, consider mapping those assets to revenue and determine the portion of revenue that the asset contributes. In short, find meaningful metrics and apply them appropriately.
Document risks
Creating a final report is an important but time-consuming step. Do not use an AI tool to assist with the writing of the report. Much of the data collected in a risk assessment is proprietary. AI not only generates results based on the proprietary data but also adds that information to its training data set, essentially scooping up and claiming the proprietary data. Proceed without AI.
When it is complete, the cybersecurity risk assessment should identify the vulnerabilities and threat actors. Perhaps you'll have those vulnerabilities and threats sorted into a matrix and quantitatively prioritized.
Remember to document both risks and relationships. Relationships were likely attained from your dependency model. A good report will also contain the mitigation plan and path, discussing both near-term tactical actions and long-term strategic goals.
Char Sample is a cybersecurity research fellow at ICF International.
