researchHQ’s Key Takeaways:
- An effective cloud control plane monitors cloud operations and configures application programme interfaces (APIs) calls to help organisations maintain visibility over their cloud environments.
- A unified interface to monitor activity across enterprise cloud infrastructure and applications enables the real-time detection and prevention of threats through access right delegation.
- Key cloud security pain points and blind spots include data-level events, Undocumented APIs, and Pre-GA Services.
- Implementing the principle of least privilege increase enterprises’ visibility over their cloud environments by restricting access to services and applications.
Visibility in the cloud is an important but difficult problem to tackle. It differs among cloud providers, and each one has its own positives and negatives. This blog reviews some of the logging and visibility options that Amazon Web Services (AWS) and Google Cloud Platform (GCP) offer. We also discuss their blind spots and how to eliminate them.
Visibility Options
Cloud providers typically offer some sort of default logging/monitoring at no extra cost, but it is never enough to gain sufficient visibility into what’s going on across your organization. They also provide additional paid services that allow you to gain more visibility into your environments for a variety of use cases. Each cloud provider does things slightly differently, meaning blind spots and lack of visibility will differ across providers.
The Cloud Control Plane
The “control plane” offered by a cloud provider is essentially what handles “cloud operations,” or API calls. The control plane needs to be accessible from anywhere on the internet, and it is what allows users to interact with the cloud and the resources in it. For example, API calls made through the AWS Command Line Interface (CLI) are routed through the AWS control plane, allowing you to take actions such as launching a new EC2 instance. In GCP, the control plane would handle things such as calls made through the “gcloud” CLI.
Visibility into what API calls are being made in your environment is incredibly important, which is why many of the free, default logging services are provided. This could include CloudTrail Event History in AWS (a 90-day history of API calls made in your account) or something like activity logging in GCP, which provides a broad overview of activity in a project. These default offerings have shortcomings, meaning that without additional configuration you will miss things.
To monitor the cloud control plane, you will need to use built-in services provided by your cloud provider, but those logs should then be exported to an external SIEM, such as Splunk, for further analysis and alerting. These services include things like an AWS CloudTrail trail being configured for every region and for every event type across your organization or GCP audit logs applied to all supported services at the organization level.
Network and Hosts
When it comes to activity within your cloud network or the hosts within that network, there is typically no free default offering to gain visibility. There may be default logging on your hosts, such as bash history, but there is nothing aggregating those logs and providing you access to all of your hosts through a unified interface.
There are many built-in and third-party offerings available to gain visibility into activity in your network and on your hosts. The CrowdStrike Falcon® platform is one option for host-based monitoring and visibility that allows you to detect and prevent threats in real time. Other offerings, such as AWS VPC (Virtual Private Cloud) Traffic Mirroring or GCP Packet Mirroring, can help with full packet capture within your cloud network. VPC flow logs are another useful tool for network visibility, and offerings such as AWS GuardDuty can monitor those flow logs, as well as DNS logs and CloudTrail logs, to detect threats and unusual activity within your environment.
Pain Points and Blind Spots
Regardless of the monitoring and visibility that is in place, even if you are utilizing all of the built-in services your cloud provider offers (and even some third-party services), there are likely missing pieces to the puzzle.
Data-Level Events
Data-level events differ from control plane/management events because they are actions performed on specific data rather than a cloud resource. For example, AWS Simple Storage Service (S3) data events log activity for objects in an S3 bucket, meaning you get insight into who’s interacting with what objects. Without additional configuration (and therefore additional cost), these types of events are not logged. Some services offer data-level event logging, such as S3 bucket access logs, but others do not, such as AWS EBS Direct APIs.
To ensure you are not losing insight into data-level events, you should enable them where possible. Where it is not possible, we recommend that you deny all users access to those data-level APIs.
