GCP audit logs are a powerful tool that track everything happening in your cloud infrastructure. By analyzing them, you can detect and react to threats.
Modern cloud applications are not just virtual machines, containers, binaries, and data. When you migrated to the cloud, you accelerated the development of your apps and increased operational efficiency. But you also started using new assets in the cloud that need securing.
The shared responsibility model from cloud providers means that those cloud assets are being made secure by the providers, but part of that responsibility is yours as a cloud customer. Your cloud account is now the main door to all your information services. It is the most important thing to secure, and is the most desirable target for cybersecurity attacks.
Keep reading to discover how GCP audit logs work, and how to process them in an efficient way to implement cloud threat detection.
Cloud threat detection is key for a secure infrastructure
Cloud providers offer audit logs, a continuous stream of events detailing everything that is happening in your cloud account. These logs contain one event for each command executed on your cloud account.
This includes administrative commands that create, modify, or delete assets, but also read commands for asset metadata and data access events.
You can implement cloud threat detection by tapping into these audit logs and validating them against security policies. That way, you are able to detect and be informed about any misconfiguration, vulnerability, or compromise of private information as soon as it is detected.
The kind of threats you want to detect
Think of the steps attackers would take if they manage to obtain access to your infrastructure.
They’ll try to not get caught by disabling data access logging or deleting monitoring alerts. They could create additional keys for a service account to ensure they continue having access. Also, while they investigate your infrastructure, they’ll probably execute commands in regions that aren’t usually used.
All of those steps leave a recognizable trace in your audit logs.
Once malicious actors have a secure position on your cloud, they can start causing harm. For example, they could change the ACL or IAM policies of a storage bucket. This would make your files accessible to the public, leading to data exfiltration.
But you shouldn’t be looking out for only malicious actors.
One of your developers could create a CGP Cloud Function with an outdated runtime version, possibly containing known vulnerabilities that are already fixed in a more recent version. Those vulnerabilities could be exploited by attackers as an entry point, and then used to perform lateral movement.
Your cloud environment needs a continuous check to flag misconfigurations like these.
Cloud threat detection vs. CWPP and CSPM
While cloud threat detection focuses on your global cloud infrastructure, the CWPP category (Compute Workload Protection Platform) refers to runtime threats, happening in your compute workloads. Both analyze events to detect threats, but at different levels.
The CSPM category (Cloud Security Posture Management) has a completely different approach. It answers the question, “How secure is my cloud account now?” To do so, it focuses on analyzing the current state of the cloud account on a scheduled basis. For this reason, CSPM is more related to compliance and usually relies on different types of benchmarks like those published by the CIS (Center for Internet Security), the cloud providers, or other security standards.
Analyzing the whole static configuration, like CSPM does, gives the advantage of seeing the full picture of the cloud account, but is costly to execute continuously. On the other hand, cloud threat detection can easily detect when assets change to an unsanctioned status.
With all of this in mind, which one should you implement?
Well, all of them.
CSPM will highlight the points of your cloud infrastructure in need of better security, CWPP will flag anything fishy going on in your applications, and cloud threat detection will allow you to react to suspicious activity in your cloud infrastructure.
Implementing threat detection in GCP: Cloud Audit Logs
The service inside Google Cloud Platform (GCP) that enables cloud threat detection is Cloud Audit Logs.
The four audit logs
Inside Cloud Audit Logs, you’ll find four different kinds of logs:
- Actions which modify the configuration or metadata of resources will leave a trace in the Admin Activity audit log.
- Actions taken by Google which modify the configuration of resources will leave a trace in the System Event audit log.
- Actions which read the configuration or metadata of resources, as well as actions which create, modify, or read data, will leave a trace in the Data Access audit log.
- Actions which result in a security policy violation, and are thus denied by the Google Cloud Service, leave a trace in the Policy Denied audit log.
Be aware that public resources with the Identity and Access Management (IAM) policies allAuthenticatedUsers or allUsers won’t leave events on these logs for privacy reasons.
The Admin Activity audit log and the System Event audit log are always enabled. However, the Data Access audit log is disabled by default because it can grow really fast. The Policy Denied audit log is enabled by default, but could be disabled.
What an audit event looks like
All four of these audit logs are stored in JSON format and share some important structure, all including a protoPayload key consisting of the following fields:
authenticationInfoauthorizationInfoserviceNamemethodNameresourceNamerequestrequestMetadataresponse@type
There are several other fields outside the payload, including the timestamp of the entry, the resource affected, or the severity of the event.
In all cases @type contains the string type.googleapis.com/google.cloud.audit.AuditLog.
The following is an example of an entry in the Admin Activity audit log:
{
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"status": {},
"authenticationInfo": {
"principalEmail": "[email protected]",
"principalSubject": "user:[email protected]"
},
"requestMetadata": {},
"serviceName": "iam.googleapis.com",
"methodName": "google.iam.admin.v1.CreateServiceAccountKey",
"authorizationInfo": [
{
"granted": true,
"resource": "projects/-/serviceAccounts/123456789012345678901",
"permission": "iam.serviceAccountKeys.create",
"resourceAttributes": {}
}
],
"resourceName": "projects/-/serviceAccounts/123456789012345678901",
"request": {
"@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest",
"name": "projects/-/serviceAccounts/[email protected]",
"private_key_type": 2
},
"response": {},
"insertId": "m8ab679xmpg5",
"resource": {
"type": "service_account",
"labels": {}
},
"timestamp": "2021-03-17T17:33:44.852270Z",
"severity": "NOTICE",
"logName": "projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity",
"receiveTimestamp": "2021-03-17T17:33:49.462759141Z"
}
Processing GCP audit logs
The first part of cloud threat detection is generating all these audit events. The second part is validating them against your security policies.
Other services, like your security tools, can consume these events via a Pub/Sub topic.
First, you filter the audit logs and send your selected events to a sink that will forward them to a Pub/Sub topic. You just have to subscribe your security tool endpoints to this topic so they can process them.
These sinks will encrypt and validate the logs to make sure they are not tampered with after GCP generates them.
How Sysdig Secure for cloud implements runtime detection in GCP
Sysdig Secure for cloud taps into the Google Cloud Platform audit logs and processes the audit events against your security policies, defined by Falco rules.
A specialized ingestor feeds on the Cloud Audit Logs and forwards the GCP events to an evaluator.
Provisioned with a rich set of custom, out-of-the-box Falco rules, this evaluator will generate security events that can be reviewed inside the Sysdig Secure interface, GCP Trace, or GCP Security Command Center.
Out-of-the-box Falco rules mapped to compliance controls
The Falco rule language has become the de-facto standard to define suspicious activity in the cloud, and its flexibility allows for fine-grained customization to your operational needs.
While the out-of-the-box Falco rules, pre-bundled with Sysdig Secure for cloud, will save you time getting started, you can still customize them or add new rules to this library to detect any cloud activity.
The included GCP Cloud Audit Logs rules are mapped against compliance controls, like those in MITRE ATT&CK, and can detect events like:
- Creation of a new bucket
- MITRE ATT&CK: Collection: Data Staged
- Deletion of an existing bucket
- Modification of a bucket’s ACL
- MITRE ATT&CK: Collection: Data from Cloud Storage Object
- Modification of a bucket’s IAM policy
- MITRE ATT&CK: Collection: Data from Cloud Storage Object
- Creation of a Cloud Function
- Creation of a Cloud Function with an outdated runtime
- MITRE ATT&CK: Initial Access: Exploit Public-Facing Application
- Update of a Cloud Function
- Command execution on an unused region
- Add admin privileges to a service account
- MITRE ATT&CK: Persistence: Account Manipulation
- Creation of a key for a service account
- MITRE ATT&CK: Lateral Movement: Use Alternate Authentication Material
- Sending an invitation to a non-corporate account
- MITRE ATT&CK: Persistence: Create Account
- Disabling data access logging
- MITRE ATT&CK: Defense Evasion: Impair Defenses: Disable Cloud Logs
- Enabling data access logging
- Deletion of a monitoring alert
- MITRE ATT&CK: Defense Evasion: Impair Defenses: Disable Cloud Logs
- Update of a monitoring alert
Sysdig Secure for cloud comes bundled with a rich set of out-of-the-box Falco rules, that besides MITRE ATT&CK®, corresponds to security and best practices standards like NIST 800-53, PCI DSS, SOC 2, CIS Google Cloud Platform Foundation benchmark, and CIS Google Kubernetes Engine (GKE) benchmark.
Detecting a configuration change with Cloud Audit Logs
Let’s see an example of GCP threat detection in action with Cloud Audit Logs and Sysdig Secure for cloud.
Take a look at the Admin Activity audit log event we presented before:
{
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"status": {},
"authenticationInfo": {
"principalEmail": "[email protected]",
"principalSubject": "user:[email protected]"
},
"requestMetadata": {},
"serviceName": "iam.googleapis.com",
"methodName": "google.iam.admin.v1.CreateServiceAccountKey",
"authorizationInfo": [
{
"granted": true,
"resource": "projects/-/serviceAccounts/123456789012345678901",
"permission": "iam.serviceAccountKeys.create",
"resourceAttributes": {}
}
],
"resourceName": "projects/-/serviceAccounts/123456789012345678901",
"request": {
"@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest",
"name": "projects/-/serviceAccounts/[email protected]",
"private_key_type": 2
},
"response": {},
"insertId": "m8ab679xmpg5",
"resource": {
"type": "service_account",
"labels": {}
},
"timestamp": "2021-03-17T17:33:44.852270Z",
"severity": "NOTICE",
"logName": "projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity",
"receiveTimestamp": "2021-03-17T17:33:49.462759141Z"
}
This event captures the creation of a service account key, which can pose a security threat.
The key fields in this event are:
serviceName: Containing the service who fires the event,iam.googleapis.com.methodName: With the actual method invoked,google.iam.admin.v1.CreateServiceAccountKey.principalEmail: Is the user which invokes the event,[email protected].resourceName: The resource that will be modified,projects/-/serviceAccounts/123456789012345678901.status: Reflects the status of the request.
A non-empty status field in a request means that it could not be processed because of an error. For example, the requester may not have had permission to perform the action. We might not be interested in these events.
Let’s go back to our example. This event tells us that a key has just been created, for the service account google.iam.admin.v1.CreateServiceAccountKey, related to the resource projects/-/serviceAccounts/123456789012345678901.
A Falco rule to detect this security event would look like:
- rule: GCP Create Service Account Key
desc: Detect creating an access key for a service account.
condition:
jevt.value[/serviceName]="iam.googleapis.com" and
jevt.value[/methodName]="google.iam.admin.v1.CreateServiceAccountKey" and
jevt.value[/status]=""
output:
An access key has been created for a service account
(requesting user=%jevt.value[/authenticationInfo/principalEmail],
service account=%jevt.value[/resourceName])
priority: CRITICAL
tags:
- cloud
- gcp
- gcp_iam
- cis_controls_16
- mitre_T1550-use-alternate-authentication-material
source: gcp_auditlog
Note that this is one of the out-of-the-box rules included in Sysdig Secure for cloud.
Using jevt.value and a query in jsonpath format, we can reference parts of the audit event.
We use this in the condition part of the rule:
condition:
jevt.value[/serviceName]="iam.googleapis.com" and
jevt.value[/methodName]="google.iam.admin.v1.CreateServiceAccountKey" and
jevt.value[/status]=""
This condition filters events: related to the IAM service, that create a Service Account Key, and having an empty status.
The same is true for %jevt.value, which we use in the output part of the rule:
output:
An access key has been created for a service account
(requesting user=%jevt.value[/authenticationInfo/principalEmail],
service account=%jevt.value[/resourceName])
This output is used to provide context information, given that this rule ends up generating a security event. In that case, this output will be sent through all of the enabled notification channels, for example, creating a security event in your Sysdig Secure account.
We have one final note on creating Falco rules for cloud events.
This is a regular Falco rule, following the regular Falco syntax. The compatibility with GCP Cloud Event Logs is achieved by handling its events as JSON objects and referring to the event information using JSONPath. This mixes two standards that your security engineers might be already familiar with, making it easier to customize and create your own rules.
Conclusions
Cloud threat detection is critical to ensure the security of your cloud security, and it’s a complement to CWPP and CSPM.
When it comes to the Google Cloud Platform, GCP Cloud Audit Logs is a great tool that enables you to monitor your infrastructure and detect security issues as they happen.
Sysdig Secure for cloud is a great source of truth as it can see everything that is happening in your GCP accounts. The comprehensive set of out-of-the-box Falco rules in Sysdig Secure minimizes the setup effort, response time, and resources needed for investigating security events.
With Sysdig Secure for cloud, you can continuously flag cloud misconfigurations before the bad guys get in, and detect suspicious activity like unusual logins from leaked credentials. This all happens in a single console, making it easier to validate your cloud security posture. And it only takes a few minutes to get started!
Start securing your cloud for free with our Sysdig Free Tier!
The Sysdig Secure DevOps Platform provides the visibility you need to confidently run containers, Kubernetes, and cloud. It’s built on an open-source stack with SaaS delivery, and is radically simple to run and scale.
Request a free trial today!