Cloud Risk Management (CRM) is the practice of managing, prioritizing, and acting on risks within the large scale of modern multi-cloud environments. Context is a critical driver of that prioritization; namely, understanding the potential impact of a particular risk and its likelihood of exploitation.
CRM can be an ephemeral concept – much like cloud operations themselves – to understand. At its core though, you should be able to leverage a single CRM solution to secure highly ephemeral, cloud-native apps, as well as your entire on-prem footprint. It’s not an easy thing to find, but the need is there for today’s risk-laden operations and environments.
With more than half of respondents to a recent survey believing risks are higher with cloud operations vs on-prem, it’s easy to see why there is such a booming need for CRM. In fact, five key risk areas that came to light: runtime, identity management, potential for misconfigurations, unaddressed vulnerabilities, and audits.
Each of those areas feature personnel and systems that must work hand-in-hand with one another – often at a fast pace – to remain productive. A single miscommunication or misconfiguration could create risk exposure analysts or developers aren’t even aware of until it’s too late. Yes, managing risk in the cloud is very complex, but there are frameworks in place Security Operations Center (SOC) teams can leverage to research, remediate, and reduce risk.
You assess risk in the cloud by first determining who is responsible for cloud security and risk management: you or your cloud service provider (CSP)? The shared responsibility model (SRM) stipulates that CSPs are typically responsible for managing risks to the underlying cloud infrastructure on which your business’ operations are running.
Internal security teams are typically responsible for security of those operations in the cloud, meaning they are responsible for making sure their own data – and their customers’ data – is properly secured. Once a team determines where their responsibilities lie and what exactly they’ll need to take a hard look at, it’s important to take into account that the assessment will need to take place in real-time.
It's important to choose a CSP that not only holds up its end of the SRM, but also one that is backed by several years of experience, solid regulatory and compliance standards, consistent performance over time, and how closely their services/architectures match your needs. A security team must also ensure their scanning tools can fit into the workflow you define within that CSPs platform.
Things happen fast in the cloud, and risks are typically exploited within two minutes of first exposure, meaning you should be able to access real-time visibility into your environment at any given time instead of waiting for a scheduled scan.
Regularly conduct risk assessments via the steps outlined in the previous section. The data gleaned from the first two steps in the process, however, still faces the reality that the scale, speed, and complexity of cloud environments creates a situation where the amount of risk signals/alerts is so vast you simply can't address everything at once.
As such, it’s imperative to prioritize the risk signals that present the most risk to the business and have the highest likelihood of exploitation. This needs to be done in real-time and with complete context, as a risk signal alone won’t provide the thorough detail needed to act.
Extend coverage into runtime and monitor for anomalous activity based on an established baseline of what "normal" looks like. Detecting anomalous behavior – and thus potential threats – into runtime helps to correlate behaviors across multiple logged activities. It’s best to target a solution that can consolidate runtime threat detections and provide context by associating the findings with the affected cloud resource.
Findings and context are nothing, however, if no one is alerted to the fact there is something anomalous happening. Teams should calibrate notifications and alerts to go to specific personnel who can most quickly remediate the issue.
Data is sensitive at any state, so it’s important to implement risk- management tools as early in the development process as possible. This can help to avoid friction between teams, but also to continuously protect data during key build and runtime processes. Data should always be encrypted at rest by default.
In this way of protecting data at all times, it’s probably a good idea to also establish a least privilege access (LPA) protocol. This helps to set the minimum amount of access a person or machine will need to do the job, while also protecting data throughout its lifecycle.
In the event of a significant cloud-security incident, it won’t be business as usual. However, business can and should certainly continue to whatever extent possible. Therefore, it’s critical to have a business-continuity plan in place in the event of just such an incident. Some key components of such a plan can include:
2022 Cloud Misconfigurations Report: Latest Cloud Security Breaches and Attack Trends