Logs-based Security Alerting in Google Cloud: Detecting attacks in Cloud Identity

Shifting from an on-premise model to a cloud-based one opens up new opportunities when it comes to logging and securing your workloads.

In this series of blog posts, we’ll cover some cloud-native technologies you can use to detect security threats and alert on logs in Google Cloud. The end result will be an end-to-end logs-based security alerting pipeline in Google Cloud Platform (GCP). We’ll start with a look into alerting on Cloud Identity logs in the Admin Console.

Cloud Identity

Customers use Cloud Identity to provision, manage, and authenticate users across their Google Cloud deployment. Cloud Identity is how the people in your organization gain a Google identity, and it’s these identities that are granted access to your Google Cloud resources.

Now think about this: What if a rogue actor gets admin access in Cloud Identity and starts adding users to Google Groups? What if one of those groups is assigned privileged access within GCP? Cloud Identity logs can provide visibility into these situations and serve as your first line of defense against authentication and authorization-based attacks.

Cloud Identity logs

Cloud Identity logs track events that may have a direct impact on your GCP environment. Relevant logs include:

• Admin audit log: track actions performed in the Google Admin Console. For example, you can see when an administrator added a user to your domain or changed a setting.

• Login audit log: track when users sign in to your domain

• Groups audit log: track changes to group settings and group memberships in Google Groups

• OAuth Token audit log: track third-party application usage and data access requests

• SAML audit log (G Suite/Cloud Identity Premium only): view your users’ successful and failed logins to SAML applications

The core information in each log entry is the event name and description. Cloud Identity logs track a large number of predefined “events” that can occur in your deployment. For example, the Login audit logs track “Failed Login” and “Suspicious Login” events. Failed Login happens every time a user fails to login. Suspicious Login happens if a user logged in under suspicious circumstances, such as from an unfamiliar IP address. The number of events Cloud Identity tracks is quite large, and these events can be explored in the Reports > Audit log section of the Admin Console.

Setting alerts in Cloud Identity

To detect threats and respond to potential malicious activity in a timely manner, you can alert on events in Cloud Identity logs. A good first line of defense is setting up alerts in the Admin Console. When you create an alert, you specify a filter and a list of recipients who will get an email when this alert is triggered. Let’s explore some potentially useful alerts.

Example 1: Alerting on login events
In this scenario, let’s say a user has unknowingly had their Google credentials stolen, and a malicious actor is trying to use them to sign in as the user from outside the company network. Cloud Identity will see that this user is trying to sign in from an unfamiliar IP address and log it as a Suspicious Login event. Let’s create an alert for this situation so we can take action if we think a user account has been compromised.

From the Reports > Audit log section of the Admin Console, choose the type of log you want to create an alert for. Once you’re viewing Login audit logs, create a filter for logs with the “Suspicious Login” event name.

You can create an alert by pressing the bell-shaped button in the top right corner of the console. You supply a list of recipients who will be notified by email every time this alert is triggered. In our example, “security@example.com” would receive an email alert if there’s a Suspicious Login. The notified users can then take action to mitigate the security concern.

You can create alerts for other Login audit events in the same way. For example, the “Leaked Password” event type is logged when we detect compromised credentials and requires a password reset, and the Government-Backed Attack event type is logged when we believe government-backed attackers have tried to compromise a user account. Alerting on these events and others can help you be aware of and react to login-related security threats.

Example 2: Alerting on changes to groups
We recommend that Google Cloud enterprise customers handle IAM permissioning by first assigning users to groups, and then listing these groups as members of IAM Roles. This way, deprovisioning Google Cloud access is as easy as removing a user from a group in Cloud Identity.

Of course, if deprovisioning IAM permissions is as easy as removing a user from a group, then provisioning access is as easy as adding them to a group. This could be dangerous if malicious users are added to a group with privileged, wide-reaching access in GCP.

There are four potential roles that can add a user to a group in Cloud Identity, depending on your settings:

• Super Admin (through the Admin Console)

• Group Admin (through the Admin Console)

• Group Owner (through Google Groups)

• Group Manager (through Google Groups)

Let’s look at a scenario to illustrate how we can use Cloud Identity logs to help mitigate these risks. Bob is a Security Lead at Company A. The Cloud Identity Super Admin has assigned him as a group manager for the Google Group “security-admin@example.com”, meaning he can add or remove members of his team to this group. This group is assigned powerful roles in GCP to carry out break-glass administrative actions surrounding security.

Let’s suppose that, in one way or another, a malicious actor has gotten access to Bob’s credentials, signed in as Bob, and has silently started adding users to the security-admin group. Now all of these rogue users have privileged access in our GCP organization. Not good!

To mitigate a scenario like Bob’s, you should set up alerts for group membership modification in the Admin Console. We can set up these alerts to trigger if modifications are made by group managers in Google Groups or by admins in the Admin Console.

To audit Group actions taken in Google Groups, we go to the Reports > Audit log > Groups section of the Admin Console. Here, we can see audit logs of actions taken on Groups. Then, we can filter on the “User added to a group” event name and specify the group name, for example a sensitive group like “security-admin@example.com”.

After that, we can create a reporting rule so that a static list of recipients is automatically emailed when this log appears.

The details for our new reporting rule are available in the Admin Console under Security > Rules > Security Admin Group Modification.

Google Groups isn’t the only way to add someone to a group. An admin could also potentially do this within the Admin Console, which would be tracked in an Admin audit log. In the same way we created an alert to trigger based on an event in a Groups audit log, we can filter for Groups-related events in the Admin audit logs.

Next steps

Cloud Identity logs help track many different events that you can use for security alerting. Once your organization is aware of these logs, you can brainstorm alerts that make sense for your use cases. For example, as you configure settings in Cloud Identity, you can make sure the settings stay that way by alerting if Admin audit logs ever show that a specific Cloud Identity setting is changed.

Setting alerts on Cloud Identity logs in the Admin Console is a good first step towards a more secure Google Cloud deployment. However, we can only go as far as the built-in Admin Console features allow us to. The next post in this series will look at how to get Cloud Identity logs into Cloud Logging on GCP so that you can analyze, export, and store them just like any other GCP log. This will allow for even more granular Cloud Identity log analysis and alerting.