Continuous cloud compliance: keeping your cloud safe
With the increasing number of cloud environments and individual components in operation, customers are beginning to address pressing questions such as: is my environment still set up correctly? Did I make a mistake somewhere in the configuration? Are my apps vulnerable? All of these questions can be answered by the area of continuous cloud compliance, and by products from the cloud security posture management family. So in today’s Cloud Encyclopedia article, we’ll focus on how to sleep soundly at night.
Martin Gavanda
What does continuous cloud compliance andcloud security posture management mean
First, let’s define the two key terms above. If you’re interested in cloud security, you’ve probably encountered them in the past. Different cloud providers or security tool vendors use one term or the other, but they are essentially the same thing – they refer to tools and processes that allow you to have continuous visibility into the health of your cloud environment.
Personally, I prefer the term continuous cloud compliance because it includes not only specific tools to continuously check compliance with various security policies, but also the approach to security in the cloud itself.
In a classical on-premise environment, we most often encounter a reactive approach. Security checks or various scans are performed (mostly automated) at defined time periods (typically on a weekly or monthly basis) and based on the results, a security incident is then created and then submitted for resolution.
As you can guess, a major drawback of this approach is the length of time my environment is in a “sub-optimal” state. Some security aspects I am not even able to detect.
The point of a cloud environment is to have any resource immediately available – whether it’s a database, a Kubernetes cluster, or a set of virtual servers. Similarly, I should respond immediately to any security flaws or misconfigurations.
If I accidentally expose the contents of my S3 bucket publicly to the internet, I can’t afford to wait a few days for another security scan to run, I need to have this information immediately. I want to have a constant overview of the current security of my cloud environment, hence the concept of continuous cloud compliance.
Shared Responsibility Model
Whenever we talk about security in the cloud, we must not forget the shared responsibility model between us and the cloud service provider.
This model defines and allocates responsibility for certain components between us and the provider. It is divided into two parts:
- responsibility „of“ the cloud – what the cloud service provider is responsible for,
- responsibility „in“ the cloud – what the cloud service user is responsible for
The key lesson from the shared responsibility model is that the user is always solely responsible for all configuration and security of the services being run.
The service provider gives us the tools and services to comprehensively secure our cloud environment. However, we are solely responsible for their implementation or use.
A beautiful case is the “affair” of 2018. According to the very first articles, it looked like a fundamental problem with AWS itself. What happened then? A group of security experts discovered a large amount of sensitive data in AWS, specifically:
- 116,386 publicly available EBS snapshots exposed to the internet, from 3,213 different accounts,
- 373 public Relational Database Service (RDS) snapshots from 227 accounts,
- 711,598 public Amazon Machine Images (AMIs) from 20,952 accounts,
- 16,000 public IPs of exposed AWS-managed ElasticSearch clusters that could have their contents stolen or data possibly deleted.
What did the data contain? For example:
- over 300,000 customer emails and encrypted passwords that belong to a Fortune 50 enterprise,
- 500,000 customer and employee records belonging to a healthcare supply chain management vendor whose clients include most major healthcare providers.
Was it some kind of AWS bug? No, in the end it turned out that human error or ignorance was behind everything. If I mark my EBS snapshot as public, it is indeed public. And most poignantly, users have seen explicit warnings that public really, really means public, available to all.
What is the lesson here? People make mistakes. Either deliberately or out of ignorance. And the purpose of continuous cloud compliance is to prevent these problems.
How it works: continuous cloud compliance
Continuous cloud compliance gives us an instant overview of all components in each environment and continuously evaluates the compliance or non-compliance of these components with defined rules.
Examples of selected policies:
- Are all running components assigned the mandator tags I defined in my tagging policy?
- Do I have a Firewall rule that allows access “from anywhere”?
- Are all my servers encrypted?
- Am I running an application server somewhere that has known vulnerabilities (CVEs)?
At the same time, I want to have a clear and comprehensive overview of all environments “in one place”. And last but not least, I need to be notified immediately in case of a new non-compliant state (or even automatically create a security incident).
Typical functionality
Individual tools vary in their functionality, but in general, continuous cloud compliance tools should cover the following areas:
Assets management
I need to have a clear view of all running components across all environments and know all available metadata for those components (for example, their configuration).
Event management
I need a comprehensive view of the individual components in operation and the time sequence of individual events (rule violations). Typically, we can automate the creation of security incidents on an event-by-event basis.
Rules a compliance engine
I want to be able to define individual security policies. In general, various “industry-standard” predefined policies can be used, such as CIS Benchmark, etc. Using these pre-made rules makes the initial deployment of continuous cloud compliance tools easier, but remember that it is crucial to be able to create your own rules.
Vulnerability management
This functionality allows you to scan individual operating components for known security threats (CVEs). At a minimum, the tool should support scanning of standard virtual servers, containers, and container images.
Visualizing the network topology
Especially for more complex applications, it is often difficult to understand the network infrastructure of the application and the connections between components at first glance. Some tools help us to visualise these dependencies automatically. For example, it shows us which elements of the application have an assigned public IP address or how they are further connected to each other.
Example of tool specific functionality
Orca Security can identify and classify the data content of individual servers in operation, such as the presence of a private key or password in readable form.
What tools for continuous cloud compliance can I use
Individual cloud environments offer a set of tools that can help you cover much of the continuous cloud compliance area. Unlike off-the-shelf solutions, you may have to interconnect the tools yourself, work out the integration to your existing SIEM tool or similar. But in the context of the cost of ready-made solutions, these will be marginal amounts.
On the other hand, you need to have some know-how and an idea of what you want to achieve. Now let’s take a look at the tools you can deploy and use immediately in each cloud environment. The following list is certainly not intended to cover all the tools on offer, but to present those that I personally consider the most important.
Amazon Web Services & Continuous cloud compliance
The AWS Security Hub provides a central view of all security-related areas in AWS and brings together other tools (such as the results of automated infrastructure scans by Amazon Inspector or sensitive data identified by Amazon Macie).
AWS Config is an asset management service. It allows you to evaluate the status of individual resources against defined security policies.
AWS Inspector enables automated scanning of different running components (virtual servers, containers, container images) against known vulnerabilities (CVEs).
Amazon GuardDuty allows you to automatically analyze individual logs or audit records. Based on anomaly detection and machine learning, it alerts you to potential security incidents.
Microsoft Azure & Continuous cloud compliance
Azure Policy allows you to define (and possibly enforce) individual security policies over running components.
Microsoft Defender for Cloud is a de facto comprehensive cloud security posture management tool (similar to third-party products) covering various areas of continuous cloud compliance.
Microsoft Defender for Identity provides a wide range of identity protection services. For example, it can detect compromised identities (e.g. a misused service account, etc.).
Application Change Analysis allows you to inventory all running resources and track any configuration changes made.
Third Party Products
Personally, I prefer to use the tools provided by the cloud providers themselves, which I can tailor to my exact needs. But it takes some effort and, as we know, time is money. That’s why, in some cases, it’s preferable to reach for off-the-shelf third-party solutions.
With ready-made solutions I perceive a certain discrepancy between the required and provided functionality and several other pros and cons.
Benefits of ready-made solutions:
- Usually provided as SaaS without having to “worry” about the tool itself
- Seamless integration of different cloud providers, at least in the case of AWS and Azure
- Simple and fast deployment; basic onboarding environment is a matter of minutes
- A unified view of different cloud environments
- Extensive functionality provided
Negatives of ready-made solutions:
- They provide as-is functionality. If something does not suit you, it is difficult or impossible to change it.
- The pricing model is in some cases complicated (payment for different modules, functional units, etc.).
- The price is usually based on the number of “managed” resources.
If, after this quick assessment, you are more inclined to use third-party tools, I would definitely recommend looking at least at these products:
I would not like to go into comprehensive reviews of individual products, after all, your requirements may differ considerably from the expectations I have of similar products. On a general level, my personal inclination is primarily towards CloudGuard, which I know from the days when it was not a product of Check Point, but of Dome9.
In conclusion to continuous cloud compliance
What should you take away from this article? First and foremost, cloud security is purely your responsibility. Consequently, you should always know the state of the individual components in operation and be able to define your individual security policies and requirements.
From my perspective, it doesn’t matter which continuous cloud compliance tools you use. But if you are migrating production applications to the cloud, you should be able to cover this area.
If you are considering deploying continuous cloud compliance and would like to discuss the topic in greater detail (technical capabilities of individual products, necessary process changes that will certainly have to occur, etc.), feel free to contact us and we will try to come up with the best solution for your individual needs.
And that’s all for today. Thanks for reading this far. In the next Cloud Encyclopedia article, Lukáš Klášterský will share his experience on how to assess the maturity of your organization in the context of the possible use of the cloud environment.
This is a machine translation. Please excuse any possible errors.
