Skip to main content

Why Do I Need a Cybersecurity Risk Assessment?

DATE: March 02, 2021

TAGS:

Every cybersecurity program I’ve ever seen lists risk assessment as its first step, a foundation upon which all the other security measures will build. But with so many potential fires to fight, why is risk assessment the first place to start? What makes risk assessment such a foundational element to cybersecurity?

Let’s try to get at the answer from the other side. What would cybersecurity management look like if we skipped risk assessment entirely? To put it in more concrete terms, we’ll use the National Institute of Standards and Technology [NIST]’s Cybersecurity Framework (2018). NIST’s framework is all about managing cybersecurity risk in a way that can be explained and justified to all of an organization’s stakeholders; it does so by breaking that management into top-level Functions. Risk Assessment is the core of the Framework’s Identify function; skipping that leaves us with Protect, Detect, Respond, and Recover.

The Protect function consists of developing an organization’s defenses. These could be identity management systems, or training programs, or any of the categories that NIST suggests, and can be as simple as password policies or as complex as third-party identity-as-a-service offerings, to name some examples. Which defenses are the right ones for you? Do you need a simple firewall in your wireless router, or do you need a complex arrangement of border and internal demilitarized zones to isolate various components of your operation based on varying levels of sensitivity? Each defensive component represents both a financial and an opportunity cost for your organization, and sometimes those costs can be astronomical. Can your business afford to make the wrong choice?

The Detect function is about creating the capability to notice cybersecurity events (ideally in a timeframe that will be useful). The ability to detect a power outage is a trivial example—after all, the lights will probably be out. But what about the non-trivial detection challenges? How do you detect when an outsider is making an inference attack on your database? What percentage of the pop-up ads your employees encounter are actually phishing attempts? Is today’s network slowness simple congestion, or is this the first evidence of a denial-of-service attack? Which possibilities are realistic dangers that your organization may face, and which are (in your specific context) just marketing buzzwords? If they are clear and present dangers, how will you know?

The Respond function follows from the detection of an event to the activities that follow, whether you are talking containing an attacker’s actions, or analyzing the impact of the event, or communicating the details of our response to the required stakeholders (or, realistically, an infinite array of other possible responses). Let’s look at those examples one by one. If the attacker is external to the organization, do you sever the Internet connection, totally isolating your network from attack, but potentially interrupting crucial business processes? Do you leave the connection in place to ensure continued operations, but potentially allowing further damage? If your client database may have been compromised, does that constitute a breach that might have regulatory or other legal implications? If so, do your staff know which members of management must be contacted this very instant, and which should be informed on a delayed schedule to prevent the spread of sensitive information?

The Recover function is about getting back to the status quo after an event. It could include restoring affected systems to operation, or after-action reports, or lessons-learned leading to process improvement. But just what lessons did your organization learn? That critical system needs to be returned to service, but has the attacker been eradicated from that system? Are you sure? Are you really sure? What happens if you make the wrong call?

I’ve posed a lot of questions here, and many of you may already have good answers to some or more of them. But for me, the truest answer to each of those questions is I don’t know. I can’t know your circumstances today. I can’t know if your business has two employees or two thousand. I can’t know if you have private, or privileged, or sensitive, or secret information in your possession. I can’t know when an attacker is scanning your firewall or has moved to enumerating your systems. I can’t know what it will take, to not only return to normal operating procedures, but restore reputational damage after a highly-publicized breach.

Without risk assessment, in reality, you can’t know either.

Cybersecurity is about identifying the hard decisions you must make to pair the resources you have available with the true risks that your organization faces. The risk assessment process starts with an analysis of the business context of the organization’s particular situation. The business context of an organization can mean many things, but it should definitely consider the strengths and weaknesses of the organization, threats that it could face (from both external and internal sources), and relationships with external stakeholders, such as customers or government entities.

It is also necessary for an organization to take an honest inventory of its assets. For our purposes, we’ll define an asset as something your organization possesses, that either has positive value in your possession, or has negative value if lost. Money is an example, but from this perspective a client contact database on one of your servers is just as much an asset as the server itself. Assets come in all shapes and sizes, but in the simplest sense they make up the list of potential targets that your organization must protect, and the resources that your organization can put toward defending those targets.

Often overlooked, but no less important than business context or asset management, is the question of governance. Governance refers to the decision-making processes of an organization as they pertain to cybersecurity questions. For a small business, all decisions might come from one owner or manager, while at the enterprise level many stakeholders might need to be involved in any significant decision.

When we have a useful understanding of the business context, assets, and governance, we’re finally ready for risk assessment. From business context, we identify potential threat sources for the assets in play. We consider what particular threat actions that might endanger specific assets, and analyze those threats based on the likelihood of those threats occurring, together with the potential impact to the organization if those threats were to be realized. Based on that analysis, we generate a set of risks for governance to consider. Those risks form a concrete and specific understanding of the true costs of protecting a particular asset, opposed to the value that asset represents. Governance can then use that understanding to develop a strategy to manage those risks.

Why must it all start with risk assessment? Because no organization has infinite resources. Because it isn’t realistic to protect every asset with every defense possible. Because while every defense might be ridiculous, some specific defenses are absolutely required—and which ones will differ wildly according to your situation. And finally, because risk assessment is the only meaningful way to start to answer all these difficult questions.

National Institute of Standards and Technology [NIST]. (2018). Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1 (NIST CSWP 04162018; p. NIST CSWP 04162018). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.CSWP.04162018

About the author

Matthew Crain

Sr. Information Security Analyst

765-496-1519, crainm@purdue.edu

Sign up for the newsletter

Return to main content

Purdue University, 610 Purdue Mall, West Lafayette, IN 47907, (765) 494-4600

© 2021 Purdue University | An equal access/equal opportunity university | Copyright Complaints | Maintained by Technical Assistance Program

Trouble with this page? Disability-related accessibility issue? Please contact Technical Assistance Program at tap@purdue.edu.