Securing Critical IT Assets, Part 1
By Alissa Burch
So, you are the new CISO – Congratulations! Or maybe you’ve been in the role for quite some time, and this year your primary goal is to prevent costly, embarrassing data breaches by focusing on protecting your critical IT assets.
Unfortunately, you and many of your peers might be hearing less than supportive commentary from various stakeholders across your organizations:
“I know that there are horrible things in the news these days, but we seem to be doing OK – our critical data hasn’t been exposed. So why does our Information Security budget skyrocket every year? How do you plan to mitigate our security risks without spending so much money?”
”We are always emergency patching or upgrading something- why can’t IT just get it right the first time and secure everything?”
Critical Assets and the Status Quo
Part of the answer is that the current approach to identifying and securing critical IT assets needs to change. We already know that we cannot secure assets that we are not aware of, nor can we secure every asset in the enterprise at the highest possible level.
Additionally, cybersecurity is a team sport – decisions on what to protect cannot be made in a vacuum. Today’s CISO needs to be a business enabler, so whenever security measures must be implemented that may impact business activities, it is critical to obtain support and buy-in from every level of management.
However, when assessing, maintaining, or upgrading technology infrastructure, companies often start the journey in the middle versus the beginning. And there is often significant pressure to take this approach.
Many regulatory and governance bodies have minimum requirements that focus on specific compliance and patching gaps, so Information Technology leaders often feel compelled to check that box first.
In parallel, Information Security teams may be independently reacting to current threats by running penetration tests or performing ad-hoc assessments and gap analysis.
When these efforts are complete, we rush to buy tools and technology or modify processes. Often we do all of this without first understanding and identifying critical functions, systems, and assets. This process makes it challenging to identify and prioritize what requires protection accurately.
While these are important and appropriate activities, they are compliance-based, reactive, and often disjointed. Besides, they may not address risks unique to an organization. For these reasons, we often feel caught in the gerbil wheel of assessing, purchasing, installing, and maintaining critical assets. We repeat this cycle without understanding whether our actions contribute to the security of those assets, their infrastructure, and the data it hosts.
Focus On The What, Not The Why and How
There is abundant industry guidance explaining why and how to inventory and the follow-on steps to protect systems and assets from threats. However, there is less guidance on how to determine what systems and assets to prioritize. Industry standards, such as NIST, CERT, and ISO 27001:2013, reference the need to “perform an asset inventory” and “identify critical assets” for prioritization.
However, for many organizations, that requirement may be challenging to interpret in a way that translates into action. This difficulty is partly because every stakeholder within an organization has unique, often disparate business needs. And if we aren’t casting our nets wide and involving all those representatives, we miss out on important information.
To secure critical assets and protect against threats, we need to start the journey of securing the enterprise by defining “critical.” Every organization should ensure that decision-makers have the same definition of critical as it pertains to their businesses. Only then can everyone move forward to identify critical functions, systems, and assets.
Why Is This So Difficult?
We often don’t stop to validate what “critical “means to each area of the business. Similarly, IT teams often go it alone and do not involve everyone who can provide validation. For example:
Some organizations may have a Chief Security Officer who oversees corporate risk and defines a corporate risk posture that informs downstream decisions. A potential issue is that this posture can be described at such a high-level that it cannot be translated easily into terms that Risk Owners can consistently apply to their respective areas.
Other organizations may not have a defined corporate Risk posture at all. The accountability for Risk Management may be pinned solely on a single role (CSO, CIO, CISO, etc.) This approach almost guarantees that the view of what is “critical” will be biased based on that individual’s day-to-day responsibilities and not representative of the entire organization.
When stakeholders engage in risk management discussions involving business and operational impacts and priorities, it may become apparent that remarkably diverse definitions of “critical” exist. All too often, however, the dominant stakeholders proceed with the internal assumption that everyone views criticality in the same way.
This lack of shared understanding leads to contrasting strategic and tactical decisions for the enterprise. This often costly disconnect is why reaching a broad, shared understanding of what “critical” means to your organization is vital.
But First Things First – Is Everyone Speaking the Same Language?
It often helps to rethink how you currently identify and describe critical functions and systems. The approach and definitions below are commonly used in the airline industry. However, the concepts can be applied to most industries.
If the loss of activity equates to a high-level of business, safety, or operational risk, that activity is a CRITICAL FUNCTION. Loss of a supporting SYSTEM or ASSET makes those items CRITICAL.
Critical functions, such as internal company communications, are activities the business needs to run successfully.
These functions are comprised of systems like websites or email.
These systems contain assets, like intellectual property, that must be protected.
Where Do We Go From Here?
So, you’ve reframed the way you view your technology and infrastructure and have established consistent terminology. Now, before diving in and expending resources, it is time to ensure you know what critical means to your entire organization.
Often, an IT Risk Owner (ITRO) is responsible for identifying, defining, and securing critical assets. Frequently, the ITRO role falls to the CISO, who directs the Information Security (InfoSec) team to make these determinations. However, without the help of various stakeholders to define what is critical, there is a risk that the team won’t get it right.
Only after you have actively engaged all stakeholders to identify critical functions can you proceed to identify your critical systems and assets. Once those critical assets are defined, you can then begin to assess vulnerabilities and threats.
In our next article, we outline four steps to identify, define, and ultimately secure your critical IT assets. At the end of the journey, you should be able to answer these two questions: What are your critical assets? How committed are you to protect them?
In Part 2 of this two-part series, we outline four steps to identify, define, and secure your critical IT assets.