Security Logging and Monitoring with Cloud Audit Logs and SIEM

Every time you or a service does something inside Google Cloud — creating a virtual machine, deleting a storage bucket, changing a firewall rule — Google quietly writes down a record of that action. This record is called a log entry. A collection of these log entries over time is called a log. Cloud Audit Logs are the three specific types of logs that record administrative actions, data access, and policy changes inside your cloud project.

There are three kinds of Cloud Audit Logs you need to know for the PCSE exam: Admin Activity logs, Data Access logs, and System Event logs. Admin Activity logs record any action that changes a resource's configuration — for example, someone turns off a virtual machine or changes its disk size. Data Access logs record any action that reads or writes data inside a resource — for example, someone downloads a file from a storage bucket. System Event logs record automatic actions taken by Google Cloud itself, like shutting down a virtual machine due to a hardware failure.

Admin Activity logs are always enabled — you cannot turn them off. Data Access logs are turned off by default because they generate a huge volume of log entries, which costs money. You must deliberately enable Data Access logs if you want to see who accessed your data. System Event logs are always enabled as well.

Logs are stored in a Google Cloud service called Cloud Logging. Cloud Logging is a central place where all your logs — not just audit logs but also application logs and network logs — are collected and stored. You can search logs using a query language called Logging Query Language. You can also view logs in the Google Cloud Console web interface.

The problem with storing logs only in Cloud Logging is that many organisations need to keep logs for years for compliance reasons, or need to analyse logs alongside logs from other cloud providers or on-premise systems. That is where export comes in. You can set up a log sink — a configuration rule — that automatically streams copies of selected logs to another destination. The most common destinations are a Cloud Storage bucket (for long-term cheap storage), a BigQuery dataset (for SQL analysis), or a Pub/Sub topic (for streaming to security tools).

A SIEM (Security Information and Event Management) system is a specialised security tool that ingests logs from many sources — all your cloud providers, your on-premise servers, your network devices — and correlates events to find suspicious patterns. Google Cloud does not have its own built-in SIEM, but you can easily export logs to any SIEM that supports standard formats. Common SIEMs include Splunk, IBM QRadar, and Microsoft Sentinel.

Monitoring alerts are different from logging. Logging is recording what happened. Monitoring is being automatically notified when something specific happens. In Google Cloud, you use Cloud Monitoring to create alert policies. An alert policy defines a condition — for example, "more than five failed login attempts in one minute" — and an action to take when the condition is met, such as sending an email, a text message, or a webhook notification.

All of this replaces the old way of doing security monitoring, which was to have a human watch a single screen or to pay for an expensive on-premise logging appliance. Cloud logging gives you a cheap, scalable, fully managed system that works across all your cloud resources.

An IT security professional at a mid-size retail company is responsible for making sure no one tampered with the company's e-commerce platform running on Google Cloud. This professional wants to know every time someone creates or deletes a Kubernetes pod, and also wants to detect brute-force attacks on the database.

Step one: they enable Admin Activity logs (already on by default) and then enable Data Access logs for the BigQuery dataset that stores customer orders. This means every SQL query that reads customer data will be recorded.

Step two: they create a log sink that exports Admin Activity logs to a Cloud Storage bucket. The bucket has a retention policy that keeps logs for three years to meet PCI-DSS compliance requirements. They also create a second log sink that exports Data Access logs to a Pub/Sub topic, which feeds directly into a Splunk SIEM running on a separate set of servers.

Step three: they create a custom metric in Cloud Monitoring that counts the number of times a specific API call — 'iam.serviceAccounts.keys.create' — is made in a single hour. They attach an alert policy to this metric that sends a notification to the company's security Slack channel if the count exceeds 10 per hour.

Step four: they build a dashboard in Cloud Monitoring that shows a real-time line chart of failed SSH login attempts across all virtual machines, alongside a bar chart of storage bucket deletion events. They share this dashboard with the rest of the security team.

Step five: when a suspicious event is detected by the SIEM — for example, multiple failed logins followed by a successful login from an unusual IP address — the security professional opens the Cloud Logging interface and uses the Logging Query Language to search for all log entries from that IP address over the past 24 hours. They find that the IP address issued a command to export a database to a different cloud provider. They immediately revoke the user's access and open an incident response case.