What does continuous cloud compliance & cloud security posture management mean? Part 1
First, let's define the two key terms mentioned above. If you're concerned about cloud security, you've probably encountered them in the past. Different cloud providers or security tool manufacturers use one term or the other, but they are essentially the same thing – they refer to tools and processes that allow you to have a continuous overview of the state of your cloud environment.
Personally, I prefer the term continuous cloud compliance, because it includes not only specific tools that allow you to constantly check compliance with various security policies, but also the approach to security in the cloud itself.
In the classic on-premises environment, the most common approach is reactive. Security checks or various scans are carried out (usually automatically) on a predefined schedule (typically on a weekly or monthly basis) and based on the results, a security incident is then created, which is then forwarded to the solution.
As you may have guessed, the main disadvantage of such an approach is the length of time my environment is diluted in a "suboptimal" state.
The purpose of the cloud environment is to have your resources immediately available – whether it is a database, a Kubernetes cluster or a set of virtual servers. Similarly, I should respond immediately to any security flaws or misconfigurations that happen in them.
If I accidentally post the contents of my S3 bucket to the internet, I can't afford to wait a few days for the next run of the security scan, I must have this information immediately. I want to have a constant overview 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 about the shared responsibility model between us and the cloud service provider.
This model defines and divides responsibility for certain areas 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 is the responsibility of the user of cloud services
Source picture: Amazon Web Services
A key lesson of the shared responsibility model is that the user is always accountable for all configuration and security of the services provided. The service provider gives us tools and services with which we can use to comprehensively secure our cloud environment. However, we are solely responsible for their implementation or use.
A beautiful case is the "affair" of 2018. What happened then? A group of security experts discovered a large amount of sensitive data in AWS, namely:
- 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 error? No, in the end, it turned out that it was all due to human error or ignorance. If I mark my EBS snapshot as public, it really is public. And the most piquant thing is that users have seen an explicit warning that public really, really means public, available to everyone.
What is the lesson? People make mistakes. Whether intentionally or out of ignorance. And the purpose of continuous cloud compliance is to prevent these problems.
How continuous cloud compliance works?
Continuous cloud compliance provides us with an immediate overview of all components in an individual environment and constantly evaluates the compliance or non-compliance of these components with defined rules.
Examples of selected policies:
- Do all operated components have mandatory tags assigned to them, which I have defined in my tagging policy?
- Do I have any Firewall rule allowed access “from anywhere"?
- Are all my servers encrypted?
- Am I running an application server somewhere with 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 immediately informed in the event of a new non-compliant state by notification (or even to automatically create a security incident).
Typical functionality
Individual tools differ in their functionality, but in general, continuous cloud compliance tools should cover the following areas:
- Assets management
I need to have a clear overview of all operating components across all environments and know all available metadata of these components (e.g. their configuration).
- Event management
I need a comprehensive view of the individual components being operated and the time sequence of individual events (rule violations). Usually, we can automatically create security incidents on a case-by-event basis.
- Rules and compliance engine
I want to be able to define individual security policies. In general, it is possible to use various "industry-standard" predefined policies, such as CIS Benchmark, etc. The use of these pre-prepared rules facilitates the initial deployment of 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). The tool should support at least scanning of standard virtual servers, containers, and container images.
- Visualization of network topology
Especially in the case of complex ones. On the other hand, Applications can be difficult to understand at first glance network infrastructure application and continuity between components. Some of the tools help us automatically visualize these dependencies. This Example shows us which elements of the application have public IP address or how they are further interconnected with each other.
Any questions? We are here for you!
