Wait, I Needed That: Criticality Analysis

Know What You Need

At the heart of both the Risk Management Framework and Zero Trust Architecture concepts is one essential question: What is important to your business? The answer for most of us is typically whatever is critical to our business objectives. Determining degrees of criticality for internal and external resources provides the basis for writing your plans, prioritizing your risk, and determining where to spend your limited money and time.

Behold, the Mysterious “Criticality Analysis”

A criticality analysis is effectively just asking questions about what is important to an organization; starting at the enterprise level and then applying the analysis deeper and deeper. It’s not always the easiest process but it is an up front investment that pays off in the long term. But what does this mysterious “criticality analysis” entail? It starts with finding the answer to, “What is important to the system?” To do this, you need to start by asking stakeholders what matters to them and what is absolutely necessary for that “thing” to function. Once you have answers from all of the respective stakeholders, you can start utilizing the system documentation to map what components actually matter.

But What Does That All Mean?

Let’s apply this methodology to a simplified real-world scenario. We (the security team) requested an architecture diagram from the IT team we are working with. That diagram shows a self-contained environment with a development server, administrative and support servers, a database, and a web frontend. Starting with this type of high-level view gives us a way to start taking small bites of your analysis loop for determining criticality.

Next, in this example system, we will interview the following groups and obtain the following information about their relevant priorities:

• Program Management - Our business objective is for people to pay for and use our web app.
• Information Technology - Our objective is to maintain the availability of the app for users.
• Software Engineering - Our objective is to improve the user experience of the app.

Using this information, we can determine that, from a very high level, the most critical aspect of our system is the application and what is necessary to keep the application operating. We identified two conditional truths about the application: The application depends on the app database. The app database does not depend on anything else

Criticality Analysis: The Old-School Approach

Based on these findings, our first-level analysis would produce the following diagram of critical systems (with systems shaded red as “critical”):

By determining which systems are truly critical (in our example, the Web Server and Application Database, both indicated in red), we can confidently prioritize budget and time toward protecting those resources. This obviously doesn’t mean that our less critical systems can be totally ignored, as their connections could impact your critical systems (consider the Admin Server in this example, which plays an important role, but is not absolutely required for the Web Server and App Database to function). Because the critical systems in this example are not dependent on the less critical systems to continue running, we can triage the efforts of our team, such that we get maximum return on our investments. This type of criticality mapping is a useful but more traditional approach to managing your priorities.

Criticality Analysis: The Zero Trust Approach

Now let’s consider a zero trust approach to criticality analysis. Because zero trust security is premised on the ideas of least privilege and constant authentication and authorization, we look at the environment a bit differently than we previously have. In a zero trust criticality analysis, you break your system down into data, assets, application, and services (“DAAS”) and create independent “protect surfaces” for each of those systems based on their criticality. Utilizing the same example as above, one of the critical protect surfaces that we define looks as follows:

With the information that we’ve already gathered from the group interviews and architecture reviews, we know that customer data is one of the system’s most critical assets. In this diagram of the protect surface for customer data, we have listed the different aspects of the system that would have access to that data: Database Application, Database Application Programming Interface (API), and Database System. A main differentiator between this zero trust example and a traditional criticality analysis approach, is that “system” in this example can indicate any process that accesses customer data, as opposed to the previous example where “system” represents a physical or virtual computing environment. Using this zero trust criticality analysis, we can identify that systems with direct access to customer data are critical and of the highest priority; thus, we are able to allocate resources accordingly.

Keeping It Focused

Ultimately, the goal of both of these approaches is the same: to focus security attention on the resources with the most value to the enterprise.

In order to keep this article to a shorter length than the average young adult novel, we have only gone through two very simplified examples. Using the processes depicted in these examples should get you started in your journey of finding your own critical systems. As you practice and demonstrate value, you can apply the process more and more granularly, and with more efficiency thus increasing system security with less friction from other business groups.

If you want to talk more about criticality analysis, and all the things Aquia is doing to help our customers address Zero Trust Security, reach out to us at LinkedIn and LinkedIn

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.