Perceived Cloud Security vs. Reality: Test Yourself

Introduction

As a cloud security gatekeeper, you “live and breathe” reducing risk. The cloud is an artful dodger, taking up enormous amounts of an organization’s time to find and fix risk, testing the limits of your teams’ knowledge, and challenging the solutions and processes you already have in place. Your day to day involves:

• Where to look for risk?
• If I know where to look, can I find it?
• Am I seeing risk in its full scope?
• How to remove it?

There’s another angle you want to take into account: Are you accurately perceiving your cloud environment’s risk level? How do you know if your perception is true? If you remove a detected risk, how do you know with confidence that conditions aren’t still in place for the risk to be repeated?

Seat belts on, please – we’re going to take a painful ride exploring these questions. We hope you’ll walk away without a scratch and with renewed conviction to be careful of your perception of your cloud security risk and what you are conveying to your report chain. Don't drink the Koolaid and be satisfied with their satisfaction. Be your own worst critic and put mechanisms in place to ensure that cloud security perception and reality are aligned.

A False Sense of Cloud Security?

As cybersecurity professionals we often use broad terms to describe the state of cloud security. We talk about “attack surface” and “security posture” but don't necessarily have KPIs that can help teams know their true cloud security posture. Risk scoring is another device that can lull us into complacency. Such values can make us look good when reporting to management, but do they accurately convey our risk situation?

The cloud security tools we use are also part of the problem. Not to fault any one tool but CSPM, for example, gives a broad view into risk, not a deep one. Take a closer look at what CSPM is and its significance. Cloud provider tools, typically our first go-to in implementing security protection, cover only single cloud environments and are limited in, for example, revealing log activity, making risky behavioral patterns hard to spot.

Bear in mind that the fox-like modus operandi of attackers is to leverage a weakness to gain access and then sit in wait – sometimes a long time – for the best opportunity to pounce.

The lack of a unified view and dynamic nature of cloud services and environments makes it increasingly difficult for security teams to objectively discern the risks, their scope and seriousness, and the potential impact a risk may have upon a breach. For some, the strategy may be to add more tools to the security stack to ostensibly ensure that all bases are covered. For others, there may be a sense of resignation that they’re doing the best they can with what’s available. For yet others, there’s simply under-awareness that the tools they have are insufficient or ineffective. The tools may be doing the work they claim to do but only naively so, leaving the environment full of security blindspots.

In our experience, during PoCs – or even demos using a small sampling of client data – organizations are often shocked by the number and severity of risk findings revealed. This includes organizations with high security awareness that are putting great effort in cloud security tools and practices.

An Osterman Research report found a similar reality: that despite their investment in cloud security most organizations surveyed – and a whopping 93% of large organizations – were at the lower levels of cloud security maturity.

Security professionals need some kind of framework for understanding if their cloud security bases are covered and their perception of their cloud security hygiene reflects the reality. Assessments can help. So can, as a first step, testing your ability to answer four basic questions.

Determine potential cloud security risks by answering these questions.

You can determine your ability to assess your organization’s potential cloud security risk level by answering four simple questions. If you can answer them, you’re likely in good shape and ready to dive deeper into examining the nuts and bolts of your cloud security. If you can’t, you’ll probably want to start building a security strategy plan that will address these issues, because your cloud infrastructure may not be secure or compliant.

Ask yourself these questions:

1. What resources can each identity in my cloud environment access?

This question helps shed light on the scope, depth and context of the visibility you have into your environment. Cloud environments are made up of tens of thousands of components that users and service principals can access and perform actions upon. These include very sensitive actions, like the ability to take all the data from a database and encrypt it.

By understanding all the actions an identity can perform and on which resources, you can map out vulnerabilities in your environment and how they can be exploited, so you can take action to mitigate them.

2. When was the last time the access was used - and how often?

The principle of least-privilege dictates that a user principal or application be assigned only the access to resources, data and applications needed to perform a task. Ideally, you also want to limit the time those permissions are granted and revoke the permissions immediately after (a concept known as Just-in-Time (JIT) access).

Analyzing which permissions are not being used regularly presents an opportunity to implement least-privilege, minimizing the cloud attack surface. In addition, keeping a close eye on behavior helps identify anomalies that might indicate a data breach.

3. What identities (human or service) can access each resource?

This question is similar to the first question but from the opposite end: permissions visibility from the perspective of the resource. Two-way mapping of which identities can access any given resource enables identifying toxic combinations, excessive permissions and other factors that put the resource at risk and should be mitigated. In addition, it enables tracking of behavior to detect anomalies.

4. What sensitive resources were accessed in a recent period of months?

Sensitive resources need to be protected with extra care. That’s why it’s important to continuously monitor them and make sure only authorized identities are accessing them and that only authorized actions are performed. This tracking can also help identify anomalous behavior that might mean a data breach occurred. Early detection helps minimize the blast radius and prevent breaches.

In addition, tracking recent access can help ensure that only the identities that require access do indeed have that access. Any excessive permissions can, and should, be right-sized immediately and policies updated. This minimizes the window of opportunity attackers have – and nips in the bud their “lay low and wait” MO – for progressing laterally to your critical assets.

5 Steps to Comprehensive Cloud Security Protection

Today, most cloud environments are plagued with hidden risks. The situation is exacerbated as cloud adoption accelerates and organizations broaden the scope of the cloud services they consume. Simple examples of risk are overprivileged access to sensitive resources, toxic scenarios that enable encrypting data in all databases and the ability to move laterally undetected within the environment. This reality results from lack of contextual visibility into resources and a lack of automation of risk analysis covering all bases.

Such risks are so common that even the most diligent security teams lack true understanding of where their cloud’s security falls short. Relying on point solutions for IAM, CSPM or workload protection, for example, pulls teams to focus their security actions and strategy on where the budget has been spent rather than on a holistic view that spans all cloud infrastructure components.

Taking the right actions to secure your cloud infrastructure will reduce your risk. Start with these five actions:

1.  Choose comprehensive solutions that offer full stack visibility, give risk context, automate remediation and are developer friendly (easy to consume, integrate in CI/CD,...). As a basic checklist, look for solutions that manage and give insight into:

• Business context
• Data sensitivity
• Governance and compliance standards
• IAM control
• Public accessibility and misconfigurations
• Workload vulnerabilities

2.  Bring cloud security best practice into the development process and all environments: staging, testing, production

3.  Ensure that risk analysis is beyond a naive, API level only

4.  Cover the new perimeter by making identity integral to your strategy

5.  Auto remediate for least privilege, and practice least privilege and JIT across the board

Such a strategy will put in place a solution that is usable and effective, and offers true understanding, at any time, of the security status of your cloud environment. It will also enable you to ace that four-question self test. ;-)