Imagine you’re an electrician. You just got a work order to fix an issue that a building inspector has recently discovered and given you the steps you need to take to resolve the issue. You head over to the site, only to discover that the building was just a “display” building and, on top of that, the building no longer exists as it had been demolished a few days before you arrived! This is a “real” world example of a common scenario in the day-to-day life of a cloud security team, meant to give you a better sense of how it feels to try and solve risks without context in a constantly shifting cloud environment.
Alert fatigue is real. And getting worse.
In the world of cloud security, security teams need to manage hundreds, if not thousands, of alerts daily. It is a real challenge to keep track of all these alerts, understand them, investigate them, prioritize them properly, and find the relevant person or team to solve them. Adding to the challenge is the fact that many alerts are false positives, inaccurate, or of very low priority. There is no single source of truth, and multiple teams manage the different assets in a cloud environment which change rapidly and are volatile in many cases. All of these issues have created overwhelming “Alert fatigue” and burnout in security teams. And the situation is only getting worse.
Now let’s take a real example of a common security alert to show you what we’re talking about. Many security tools, including built-in tools provided by cloud providers, will surface and typically give a high score to unused/over-privileged permission alerts on different runtime assets (VM Instances, serverless functions, etc…).
First of all, let’s ignore the fact that the source of these alerts is not the runtime asset but the identity granting permissions to the asset. From this point, we are already missing a lot of the context - it is not truly clear what actions these permissions allow the identity to do and on what assets it can perform these actions. And then getting to the real issue here, we don’t have any context on the asset itself. Does it still exist? Is it running? When was it last used? Who has access/permissions to it? To what is it related? Is there any way to access it externally?
CNSOs Connect Data & Add Context
Without understanding the real environment, collecting data from all possible sources, and then connecting it to create the relevant context needed to ask and answer the right questions, it is very hard to surface significant risks and even harder to prioritize them.
Risks without context are meaningless in the world of the cloud.
Bringing context to risks is just what the new breed of solutions known as Cloud Native Security Operations (CNSOs) are doing. CNSOs, like DevOcean, help security teams get the relevant context needed to quickly and easily prioritize and solve all the alerts they get from their different security solutions. Here are some examples of the added context we add to each alert and resource that we discover in our clients' cloud environments:
- Is the alert still relevant? Does the resource even exist? Is it running?
- Can the alert expose assets in the environment to external attacks?
- What is this environment used for? Production? Staging? QA & Testing? Demo? etc….
- What are the applications deployed in the environment?
- What resources does the alert have access to, and how?
- What assets are related to the alert?
- Are there any related/similar alerts?
- What are the possible attack paths in case of an entry? And does this alert affect it in any way?
Only by truly understanding the full context of a risk, will security teams have less “alert fatigue” and burnout - as they are able to prioritize the risks that matter most to their business.
Coming Soon to a Blog Near You
But that’s just the tip of the iceberg. Be on the lookout for future blogs as we discuss how this new approach can still connect to older approaches, such as threat hunting in logs! We’ll also talk about the layers in the cloud that are often “so far away” and are pushed to the side, easily overlooked, forgotten or even dismissed due to the overflow of non-contextual risks. These neglected layers are network accessibility and configurations inside the account, and cross-account connections and permissions. Stay tuned for feature blogs as we dive into the new world of CNSOs and how they bring context to risk!
We take the manual work out of cloud remediation so you can accomplish more.