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 in the configuration somewhere? Are my applications vulnerable? All 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 well at night.
Martin Gavanda
What does it mean continuous cloud compliance a cloud security posture management
First, let's define the two key terms above. If you're interested in cloud security, you've probably come across 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 the tools and processes that allow you to have Continuous visibility into the health of your cloud environment.
I personally prefer the term continuous cloud compliancebecause 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 the classical on-premise environment we most often encounter a reactive approach. Security checks or various scans are performed (usually 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 forwarded for resolution.
As you may have guessed, 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 whole 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 cannot afford to wait a few days for another security scan to run, I must have this information immediately. I want to be constantly aware of the current security of my cloud environment, hence the term 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 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
A key lesson from the shared responsibility model is that the user is always solely responsible for all configuration and security of the services operated.
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.
The "affair" of 2018 is a beautiful case in point. According to the very first articles, it looked like a major problem with AWS itself. What happened then? 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 to be human error or ignorance. If I mark my EBS snapshot as public, it is indeed public. And the most spicy thing is that users saw an explicit warning that public really, really means public, available to everyone.
What is the lesson here? People make mistakes. Either intentionally or out of ignorance. And the purpose continuous cloud compliance is to prevent these problems.
How it works continuous cloud compliance
Continuous cloud compliance provides us with instant overview about all components in each environment and constantly evaluates compliance or non-compliance of these components with the defined rules.
Examples of selected policies:
- Do all running components have mandator tags assigned to them, which I defined in my tagging policy?
- Don't 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 in a position to be in a position to be in a new non-compliant state immediately informed by notification (or even automatically create security incident).
Typical functionality
Individual tools vary in their functionality, but in general, tools for continuous cloud compliance 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 and compliance engine
I want to be able to define individual security policies. In general, various "industry-standard" predefined policies can be used, for example CIS Benchmark atp. The use of these pre-prepared rules facilitates the initial deployment continuous cloud compliance tools, but let's not forget 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 with more complex applications, it is often difficult to understand at first glance network infrastructure applications and connections between components. Some tools help us to visualize these dependencies automatically. For example, they show us which application elements have an assigned public IP address or how they are further connected to each other.
Example of tool specific functionality
Tool Orca Security can identify and classify the data content of individual servers in operation, for example the presence of a private key or password in a readable form.
What tools for continuous cloud compliance I can use
Individual cloud environments offer a set of tools to help you continuous cloud compliance largely covered. Unlike off-the-shelf solutions, you may have to connect the individual tools to each other yourself, work out the integration to your existing SIEM tool or similar. But in the context of the cost of off-the-shelf 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 use in each cloud environment deploy and use immediately. The following list is certainly not intended to cover all the tools offered, but to present those that I personally consider the most important.
Amazon Web Services & Continuous cloud compliance
AWS Security Hub provides a central view of all security-related areas in AWS and brings together other tools (for example, the results of automated infrastructure scans by Amazon Inspector or sensitive data identified by Amazon Macie).
AWS Config is a service providing asset management. 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 de facto complex cloud security posture management a tool (similar to third party products) covering different 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. However, this requires some effort and, as we know, time is money. That's why in some cases it's preferable to reach for ready-made 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 funckionality as-is. 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 leaning more towards using third-party tools, I would definitely recommend at least looking at these products:
I wouldn't want to go into comprehensive reviews of individual products, after all your requirements may differ greatly from the expectations I have of similar products. In general terms, I personally tend to be primarily inclined towards the CloudGuardwhich I know from the time 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, that security in the cloud is entirely 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 point of view, it doesn't matter which tools for continuous cloud compliance you will use. But if you're migrating production applications to the cloud, you should be able to cover this area.
If you are considering deploying continuous cloud compliance and you would like to discuss the topic in more detail (technical possibilities of individual products, necessary process changes that will certainly have to be made, etc.), feel free to contact us and we'll work together 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 article Cloud Encyclopedia Lukáš Klášterský will share with you his experience on how to assess the maturity of your organization in the context of possible use of the cloud environment.
