GCP IAM Custom Role Creation
Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/09/21"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are
11user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will
12not be updated automatically and could lead to privilege creep if not carefully scrutinized.
13"""
14false_positives = [
15 """
16 Custom role creations may be done by a system or network administrator. Verify whether the user email, resource
17 name, and/or hostname should be making changes in your environment. Role creations by unfamiliar users or hosts
18 should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
19 """,
20]
21index = ["filebeat-*", "logs-gcp*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "GCP IAM Custom Role Creation"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
29
30### Investigating GCP IAM Custom Role Creation
31
32Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations.
33
34### Possible investigation steps
35
36- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role.
37- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations.
38- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions.
39- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies.
40- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs.
41
42### False positive analysis
43
44- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior.
45- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
46- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern.
47- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly.
48- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities.
49
50### Response and remediation
51
52- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
53- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization.
54- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege.
55- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation.
56- Implement additional monitoring on the identified user or service account to detect any further suspicious activities.
57- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles.
58- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions.
59
60## Setup
61
62The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
63references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"]
64risk_score = 47
65rule_id = "aa8007f0-d1df-49ef-8520-407857594827"
66severity = "medium"
67tags = [
68 "Domain: Cloud",
69 "Data Source: GCP",
70 "Data Source: Google Cloud Platform",
71 "Use Case: Identity and Access Audit",
72 "Tactic: Initial Access",
73 "Resources: Investigation Guide",
74]
75timestamp_override = "event.ingested"
76type = "query"
77
78query = '''
79event.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateRole and event.outcome:success
80'''
81
82
83[[rule.threat]]
84framework = "MITRE ATT&CK"
85[[rule.threat.technique]]
86id = "T1078"
87name = "Valid Accounts"
88reference = "https://attack.mitre.org/techniques/T1078/"
89
90
91[rule.threat.tactic]
92id = "TA0001"
93name = "Initial Access"
94reference = "https://attack.mitre.org/tactics/TA0001/"
95[[rule.threat]]
96framework = "MITRE ATT&CK"
97[[rule.threat.technique]]
98id = "T1078"
99name = "Valid Accounts"
100reference = "https://attack.mitre.org/techniques/T1078/"
101
102
103[rule.threat.tactic]
104id = "TA0003"
105name = "Persistence"
106reference = "https://attack.mitre.org/tactics/TA0003/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating GCP IAM Custom Role Creation
Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations.
Possible investigation steps
- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role.
- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations.
- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions.
- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies.
- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs.
False positive analysis
- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior.
- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern.
- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly.
- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities.
Response and remediation
- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization.
- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege.
- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation.
- Implement additional monitoring on the identified user or service account to detect any further suspicious activities.
- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles.
- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions.
Setup
The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- GCP IAM Role Deletion
- GCP IAM Service Account Key Deletion
- GCP Service Account Creation
- GCP Service Account Deletion
- GCP Service Account Disabled