...

Prioritizing Cloud Risk Requires Context to be Effective

15 April 2020

Cloud security configuration scanning tools and similar approaches offer great insight at the technical level and are a foundational component of a risk assessment strategy. Prioritizing risk mitigation based on that low level output alone misses something critical (pun intended): organizational context.

Addressing all the “High” severity issues identified is an approach that many organizations choose to follow, but it can actually lead to over-focusing on certain areas attributed to preventing attacks and leaving areas such as detection of malicious behavior and response to incidents under-developed or even neglected.

Cloud Security Scan Tools

Due to the API-driven nature of cloud infrastructure for creating and managing resources, assessing cloud environments for security risk is heavily weighted toward configuration settings. For example:

  1. Does this security group/firewall rule allow access to that port?
  2. Does this user have privileged permission to access a resource?
  3. Does this resource have the configuration set to log events to the cloud provider log stream?

There are several cloud security scan tools available that can review hundreds or thousands of configuration settings for alignment to best practices, and they can offer great insight at reasonable scale. There’s a natural tendency to jump right in and use the “Low”, “Medium”, “High” severity ratings from the tool(s) output directly to begin prioritizating remediation efforts. However, that’s likely not the most effective use of time and resources in terms of reducing the greatest amount of overall risk.

A Balanced Approach

If the goal is to reduce the most overall risk in the organization, it makes sense that deciding which controls and mitigations are most important isn’t just a game of “sort by severity”. It requires balancing the security improvements across a broad range of areas in concert, and that requires a methodology for communicating risk “up” to executive leadership and “down” to the technical implementers.

A Shared Framework

In recent discussions with our partners in the industry, it’s abundantly clear that technical risk assessments cannot be consumed in isolation. Instead, they must fit directly into a broader, organization-wide framework that both executive teams and technical implementers can execute on. That risk assessment framework must therefore be immediately understandable by non-technical business leaders with minimal use of risk jargon, but it also must be descriptive enough to cover the entire domain of risk management at a deep technical level.

We’ve found the NIST Cybersecurity Framework (CSF) to strike a nice balance of completeness and depth, simplicity of terminology, and flexibility for use in a broad range of environments. These benefits also map directly to Cloud-Native and Kubernetes environments. A few examples:

  1. Shared taxonomy/language for measuring organization-wide risk
  2. General language that is broadly applicable to many environments
  3. Maps in the concept of proficiency for each area to support self-improvement
  4. Data fed from live/actual sources simply enhances accuracy of measurement
  5. Supports prioritization efforts with organization level context in mind

The NIST CSF identifies five Core Functions that classify all risk management actions into their basic “buckets” and are not only applicable to cybersecurity risk management but also to risk management at large:

image of core functions

Within each core function, there are one or more categories broken down into one or more subcategories. There are a total of 23 categories and 108 subcategories in the CSF, and each one serves as an outcome-driven statement that provides considerations for creating or improving your cybersecurity program. If your organization needs additional categories or subcategories, the CSF fully intends for you to add them. It’s a framework to guide the process of measuring and managing risk, not a declarative compliance standard to follow.

image of subcategories

While 108 subcategories might seem overwhelming at first, understand that they cover quite a bit of ground and use simple terms that most members of leadership can understand without much additional clarification. Just that fact contributes to its inherent value.

To prove to you how approachable this process can be, our friends at Expel have a published a free whitepaper and self-assessment tool that you can use to quickly measure your organization’s overall risk rating across all functions, categories, and subcategories. Depending on your answers, you can determine where your organization rates itself on the scale of implementation tiers. These tiers are meant to help you measure relative maturity for each subcategory. For example, a rating of “0” or “1” for a subcategory means your organization is not far along its progression in that area and a rating of “4” or “5” means your organization is very advanced in that area and may even be a leader among your industry peer group.

Increasing Accuracy of the Tier Measurement

Organizations that self-assess following the NIST CSF using a subjective process gain a great deal of value from understanding where they stand in key areas relative to each other. Performing the self-assessment exercise annually or quarterly is highly recommended and helps prioritize and balance risk mitigation efforts with the necessary organizational context.

However, being a subjective self-assessment, the accuracy can suffer due to personal bias and emotional state. Wherever possible, obtaining objective data about the people, processes, and technology supporting a given subcategory is key to ensuring the executive leadership is performing that risk management balancing act with the fullest understanding of reality.

How We Integrate

At Darkbit, we have been working hard to ensure all of our Cloud and Kubernetes Assessment findings can be mapped directly to the applicable NIST CSF subcategories so that issues found can more easily roll up into the larger picture so that executives, technical leadership, and technical implementers can be on the same page when it comes to prioritizing their scarce resources to reduce organizational risk.