Why Continuous Monitoring Matters in the Cloud

The best organizational cybersecurity strategies have continuous monitoring as one of their main tenets. Sure, you can get a bunch of flashy new security tools, but it’ll all be for naught if you’re not constantly keeping tabs on them. 

And if you’re not constantly keeping tabs on them, you run the risk of being breached and finding out about it when the damage is already done. This holds even more weightage in cloud environments, where people are still assimilating to the relatively new technology. 45% of all breaches are cloud-based, and executives say security (85%) is the biggest challenge when it comes to cloud adoption.

65% of the world’s cloud data is stored in either an AWS, Azure or Google Cloud Platform (GCP) server, but going with big names doesn’t necessarily guarantee big security. 27% of organizations have experienced public cloud security incidents, and a lot of this has to do with not being aware of all the security resources each platform provides. 

This blog covers the continuous monitoring and threat detection methods in GCP you can adopt using all its native tools. Constant keeping of tabs doesn’t necessarily mean reading countless logs all day. In this current scenario, where 80% of organizations report not having a dedicated cloud security team, that approach is unfeasible.

As it turns out, GCP has a lot of tools that do the heavy lifting for you, with the right configurations and alerts, of course. Utilizing them effectively will create a robust mechanism to detect & respond to potential security incidents. We’ll start off by discussing the various monitoring and detection tools GCP has at its disposal, and then impart what we consider to be cloud security monitoring best practices.

Let’s begin by stating that the bedrock of successful cloud threat detection strategies are logs. Lots and lots of logs. From your VMs, your network traffic, your storage systems, your application services. Only by thoroughly scrutinizing all these logs can you begin to identify any anomalous activities or patterns.

Here are some of the resources at your disposal to help you with that:

Cloud Monitoring

This resource collects metrics, events & metadata from all across the platform, and converts them into dashboards, alerts and uptime checks to ensure that the systems are running reliably. One can create custom alerting policies that promptly alert you whenever an event triggers a condition in one of the policies you create. This method can also be configured to send notifications to people or third party notification services.

Cloud Identity

This is GCP’s Identity as a Service (IDaaS) platform, that manages and authenticates users across all GCP environments. Cloud Identity is in charge of giving users Google identities, and then granting access allotted to individual identities. 

Here are the logs you should be keeping tabs on in this platform:

• Admin Audit Logs track actions performed in the Google Admin Console, allowing you to see activities like an admin adding a user or changing a setting.
• Login Audit Logs track sign-ins, like failed logins and suspicious logins from unfamiliar IP addresses.
• Group Audit Logs track changes to group settings and memberships in Google Groups.
• OAuth Token Audit Logs track third party application usage and data access requests.
• SAML Audit Logs track successful & failed logins to SAML applications.

Cloud Logging: The Importance of Logs in Cloud Security

This program receives, indexes and stores log entries from Agent Logs (running on VMs or Google Kubernetes Engine), Access Transparency Logs (actions taken by Google staff when accessing your data) and, most pertinently, Cloud Audit Logs.

Those logs are highly pertinent because they record all the who, where, and when. With them, it is possible to attain the same level of transparency as on-premises environments over admin activities & data access in GCP, because every activity is recorded on a hardened, always-on audit trail that attackers can’t disable. 

Cloud Audit Logs can be divided into the following 4 categories:

Access Logs

These are logs generated by a variety of services, such as:

• VPC Flow Logs capturing information about traffic going to & from VPC network interfaces
• Cloud Load Balancing Logs capturing details of each request or connection made to a Load Balancer
• Cloud CDN Logs dealing with external HTTP(S) load balancers that the Cloud CDN backend is attached to

GCP Security Command Center (SCC)

Finally, we’ve saved (arguably) the best for last. The SCC is a risk dashboard & analytics system for spotting, understanding & remediating security & data risks across your GCP presence. It is comprehensive in displaying possible security findings & risks associated with each asset, and the findings can come from built-in services, third party partners or even custom sources.

Here are the SCC’s distinct features:

So there we have it – all the myriad parts of GCP that can help you continuously monitor all your assets . Here are the four steps you can undertake to seamlessly bring these continuous monitoring tools GCP has provided into one cogent strategy:

Step 1: Gather All the Logs

Cloud Logging must be enabled in every GCP project to collect logs from every environment, and here are some of the many logs you should be collecting – Agent Logs, Application Event Logs, Audit & Access Transparency Logs, Access Logs and Kubernetes Logs.

Oh, and get all the logs you can from Cloud Monitoring, Cloud Identity and SCC, too.

Step 2: Queueing Up for Cloud Resilience

The integrity, completeness and availability of collected logs are crucial for forensic and auditing purposes. The challenge lies in the fact that most logs (like all the Cloud Logging ones) are only there for a limited time. Therefore, a queuing system like Pub/Sub could be used to receive & buffer all the logs collected. This improves your cloud resilience, since queuing can be crucial in the event of a downstream component failure.

Step 3: Secure Storage with DLP and IAM

A LogStash Agent can be used to pull logs directly from Pub/Sub topics & store them in a bucket where they are treated as immutable files. Properly configuring the Bucket Retention Policies & Retention Policy Locks ensures that nobody is able to delete objects during the pre-defined retention period.

In addition, you should fortify these files with DLP to prevent & detect cases of attempted data exfiltration, and strong IAM to limit access.

Step 4: Stay Alert with Cloud Monitoring and SIEM

Cloud Monitoring forms the crux of this – you can use it to create and manage your alerting policies so that you can be immediately informed if something potentially fishy is going on. Additionally, another LogStash agent can be used to pull logs from Pub/Sub to an ElasticSearch instance used by your SOC team for monitoring.

So there you have it! With a little assimilation to all the great tools GCP has at its disposal, you can effectively create continuous monitoring & threat detection ecosystems that allow you to be at ease when it comes to your cloud data.

We’d be happy to help you out with this, so contact us here to start the conversation.