On Sep 28, 2023, in an email to all GCP customers, Google announced that as of January 15, 2024, Policy Intelligence will become part of the Security Command Center SKU. This has several implications for security professionals that use Google Cloud Platform.
Policy Intelligence is utilized by security teams to make informed decisions about their identity access management (IAM) policies, reduce policy-related errors, and enhance IAM security. It's main capabilities include:
- IAM Recommender: Recommends role modifications for users, service accounts, and groups based on actual usage. It helps identify over-provisioned roles and suggests least privilege roles, making it easier for organizations to follow the principle of least privilege.
- Policy Analyzer: Helps understand the access relationships between resources and identities. It is useful for analyzing why a user or a service account has access to a specific GCP resource.
- Troubleshooter: Helps in diagnosing why a user might not have access to a particular resource or why they have more access than expected.
- IAM Recommender: For all roles, non-basic and custom, role recommendations will only be available as part of the premium SKU. Recommendations for the three basic roles (Viewer, Editor and Owner) will continue to remain free. However, in practice, since the non-basic roles (total of ~1600) and custom roles vastly outnumber the basic roles, it is likely that security teams will need to either upgrade or look for alternatives.
- Policy Analyzer: The free tier will only support up to 20 queries a day. Again, it is likely that security teams will need to either upgrade or look for alternatives.
Naturally, the path of least resistance is to just upgrade to the new SKU. This will have different cost implications for different GCP customers, depending on various factors such as their usage, environment and the particulars of their contract with Google.
A second option is to engage a specialized CIEM (or CNAPP) vendor, such as Wiz, Orca, or Ermetic. The obvious benefit of doing so is that such a vendor will provide a lot of additional capabilities such as workload protection (CWPP), protect sensitive data (DSPM), detect cloud misconfigurations (CSPM) etc. The obvious downside is that the customer may not need all of these capabilities, and more importantly, the price could become prohibitive.
However, for customers who want free alternatives, P0’s starter tier is worth exploring. P0 offers all the capabilities of Policy Intelligence, and a whole lot more:
Policy Intelligence only provides a full list of unused permissions across all principals. Given the complexity of GCP (or any other cloud, for that matter), this could be a very long list. Security teams usually do not have any context or knowledge about the vast majority of these permissions, and may not know how to prioritize changes.
A much better (and faster) approach is to only address the riskiest permissions. But the question is, how do you define risk for IAM roles and permissions?
At P0, we have built (and open sourced) the IAM Privilege Catalog, where we map GCP IAM roles to the well known MITRE ATT@CKⓇ framework. We then use this to identify the riskiest IAM configurations where you need to focus your attention, without getting lost in a sea of noisy alerts.
Using P0, you can view all contextual data from your IAM configuration, identity provider, and your access logs in one place. You can also track changes in access to the assets that matter to you the most by turning your queries into monitors.
Let’s say you are using Policy Intelligence, and find some principals whose permissions are clearly overprovisioned. What do you do?
Chances are that you will hesitate to remove permissions immediately. Why? Because you don’t want an unknown service to go down in production, without properly notifying that principal, or a service owner (in case the principal is a service account). Managing this process is difficult in any reasonably-sized organization, because it will involve coordinating across multiple teams.
You can immediately make the suggested change directly from the finding. Once the excess permissions are removed, P0 starts a workflow notifying the principal about the change (via Slack), and asking them to use P0’s Slackbot for access escalation, if they need the permission in the future.
At the end of the day, security professionals simply want to protect their crown jewels, their sensitive infrastructure and data, from identity attacks. Ensuring each principal has least privileged access is just part of the problem; they also need to ensure that the principal itself can be trusted.
In other words, to truly solve the cloud access problem, they need to ensure that only verified identities have access to sensitive resources and that no identity has more access than needed.
To secure machine identities, it is critical to ensure that keys are not being misused (or used in ways that do not correlate with historical patterns).