top of page

Securing your Critical IT Assets, Part 2

By Alissa Burch

In Part 1 of this two-part series, we addressed the challenges of securing critical assets and defined how critical functions are comprised of systems and assets. In Part 2, we outline four steps to identify, define, and secure your critical IT assets.

When preparing to identify and protect your organization’s critical IT assets, you and your teams may already have preconceived ideas around the following questions:

  • What activities are essential to your business operations?

  • What are your critical assets, and how do you define critical?

However, until all stakeholders are engaged, these are only starting points for your IT Risk Owner (ITRO) or Information Security (InfoSec) teams as they facilitate information-gathering activities. The answers to these two questions can only be answered for your organization after these discussions take place.

We break down how to do so in the following four steps.

Step 1: Define What “Critical” Means to Your Entire Business

Before defining critical functions, systems, or assets, begin by examining what critical means to your business.

The National Institute of Standards and Technology (NIST) defines criticality in terms of the impact of the “function or component failure on the ability of the component [system] to complete the organizational missions supported by the information system.”[1]

Another way to think about criticality is to consider the level of risk stemming from business or operational impacts when the ability to perform a specific function is lost. If the loss of that function equates to a high level of business, safety, or operational risk, that is what makes the supporting systems and assets “critical.”

In most organizations, the ITRO is responsible for identifying, defining, and securing critical assets. And frequently, the ITRO role falls to the CISO, who directs the Information Security (InfoSec) team to drive the effort. However, regardless of which team is leading the charge, they cannot make this determination in a vacuum. The team must engage Business, Operations, and Leadership Risk Owners to prioritize which business and operational activities fall into the highest criticality or severity levels.

The assessment team begins identifying initial Business or Operational criticality assumptions. The output of this activity is a preliminary list of critical activities intended to jumpstart discussions with stakeholders. These representatives then need to help identify and confirm what activities significantly impact the business.

In the Airline industry, for example, discussion topics should include:

  • Life and safety impacts

  • Significant loss of revenue

  • Disruption of workflow

  • Reputational and brand risks

  • What potential scenarios keep each stakeholder up at night?

This dialogue may either validate the team’s initial assumptions or uncover both impacts and associated activities that had not previously surfaced. These discoveries may also lead to an adjustment of already identified criticality or severity levels.

Step 2: Translate Key Activities into Critical Functions

Now that there is agreement on what activities are imperative to the business and how “critical” is defined, Information Technology (IT) and Information Security teams have the expertise to determine how critical activities translate into critical functions.

For example, a stakeholder states, “We will lose significant profits if we cannot accept orders from our customers for more than four days.” That stakeholder may or may not understand the various functions that enable this activity. However, the IT and InfoSec teams know that order intake (activity) is processed over the phone, and the company website (systems). They also know that the underlying telecommunications and web hosting services are critical functions.

In many cases, function, system, or asset criticality has been partially defined in a Business Continuity Plan (BCP) or an Incident Response Plan (IRP). If you have them, these documents are an excellent place to start when trying to identify functions. This starting point is particularly true if your IRP includes criticality or severity levels that directly tie back to loss or interruption of a business or operational function.

Step 3: Identify and Prioritize Critical Systems and Assets

With a drafted list of critical functions and rationale identified by stakeholders, the IT and InfoSec teams can move to the next step: drill-down and identify the systems and assets that support those functions.

Disaster Recovery Plans may identify some critical functions, systems, and assets. At this stage, prior audits, assessments, gap analysis, or PEN testing results will come in handy. These artifacts may focus on technical gaps and vulnerabilities that will be gibberish to anyone outside of IT. Therefore, IT teams must describe technology gaps in terms of previously identified critical activities, functions, and associated business risks.

To organize critical systems and assets, create a spreadsheet matrix identifying functions, systems, associated assets, and business and operational risks if these systems are impacted. Each asset entry should also include both an asset and a risk owner. You may also find additional guidance and context by reviewing the ISO 27001:2013 recommendations regarding the development of an Asset Register. As a result of this work, shared infrastructure dependencies should surface and garner special attention. At some point, certain critical assets will float up to the top as priorities for protection.

At this point, you may want to consider transitioning this information into a Threat Matrix, or a Risk Register, depending on your organization’s preference or compliance requirements. Or, if those artifacts do not already exist, consider adding sections to the original matrix. Regardless of the artifact chosen, ensure that descriptions of key risks, probability, and impacts are captured. Also, frame the risk statements to describe the potential effects to critical functions the assets support versus focusing on the assets themselves. It may be helpful to leverage the CIA Triad (Confidentiality, Integrity, and Availability) as you develop these descriptions.

For example, in the following scenario, the IT department discovered that, based on current threat intelligence, they need to upgrade the boundary firewall protecting the web hosting servers from threats associated with connecting to the public internet.  And since these servers enable customers to place orders – now the team has tied a critical activity (order intake) to a function (web presence), systems (the web hosting infrastructure), and a critical asset (the boundary firewall).

Rather than focusing the risk statement on only the boundary firewall and the application servers it protects, reframe the risk statement to describe how a probable compromise to the boundary firewall may impact the confidentiality, integrity, and availability of the order and customer data it transports.

Once you’ve identified critical assets and associated risks, and have taken the first pass at prioritizing them, reengage your initial stakeholders with the critical asset and risk matrix. Ensure that each item ties back to a critical function. Ask them, “Did we get this correct?” Push for a discussion, rather than mere yes or no responses. Your stakeholders may be willing to help refine the articulation of business risks, ownership, and priorities. Expect to adjust the list and possibly receive recommendations for more stakeholders to interview.

Step 4: Secure Critical Assets

Once you have an agreed-upon matrix of prioritized risks, assets, and their respective owners, it is time to begin mapping those assets to recommended security controls. Now we have returned to familiar territory for most Information Security teams. If additional guidance is needed, organizations that are new to selecting security controls may want to begin with the NIST Cybersecurity Framework or the CIS Top 20. Both approaches leverage cybersecurity best practices and are comprised of risk-focused guidelines to help organizations identify, implement, and improve cybersecurity practices. The usage of industry frameworks also creates a common language for internal and external communication of cybersecurity issues.

If your organization’s cybersecurity needs are more advanced, NIST 800-53 provides granular guidance around security and privacy controls for information systems and organizations. Additionally, it describes processes for selecting controls protecting organizational operations and critical assets. The security and privacy controls are customizable and should be implemented as part of an organization-wide process that manages information security and privacy risk.

By helping build your stakeholders’ technology savvy, you have also established additional trust and reciprocity. Moving forward, you can engage these same stakeholders for assistance with efforts like prioritization and funding. More importantly, you have built a foundation for the practical identification and management of critical assets.

So, No- Don’t Secure All of the Things

Instead, first, begin by securing the assets supporting your most critical functions. Then you can work through the remaining risks as time and resources allow.

And congratulations- you’ve made it this far! As a key business enabler for your organization, you’ve done something more valuable than merely developing a prioritized list of assets and checking off a compliance item. Instead, you’ve led your organization through developing a shared understanding of what “critical” means, bringing a common language to help describe functions and systems, identified vital business functions, and then ultimately prioritized which assets to protect with the limited resources you have. You have proven that cybersecurity is a team sport. You involved stakeholders from all facets of your business in these decisions as part of your team. You successfully showed them the “why” as well as the “what” and “how.”

And you have indeed addressed the initial, less than complimentary, stakeholder commentary by helping everyone answer these key questions: What are your critical assets? How committed are you to protect them?”

bottom of page