A customer was receiving alerts from the out-of-the-box (OOTB) detection GCP IAM serviceAccounts getAccessToken Privilege Escalation. The alert message included [GCP]: [<ACTOR_NOT_FOUND>] performed [GenerateAccessToken] on project, which indicated that Panther's data model did not recognize the actor correctly.
Upon investigation, we found that the issue arose because the GCP Audit schema in Panther was only mapping the principalEmail field as the actor_user, while for third-party identity callers, GCP populates the principalSubject field instead of principalEmail. This behavior is confirmed by the GCP documentation.
Changes
Added a method get_actor_user to use principalSubject for actor_user field when principalEmail is not present
Applied the get_actor_user method to 'username' field since it was also mapping to principalEmail previously
Modified alert title of GCP IAM serviceAccounts getAccessToken Privilege Escalation to use the actor_user udm field
Background
A customer was receiving alerts from the out-of-the-box (OOTB) detection
GCP IAM serviceAccounts getAccessToken Privilege Escalation
. The alert message included[GCP]: [<ACTOR_NOT_FOUND>] performed [GenerateAccessToken] on project
, which indicated that Panther's data model did not recognize the actor correctly.Upon investigation, we found that the issue arose because the GCP Audit schema in Panther was only mapping the
principalEmail
field as theactor_user
, while for third-party identity callers, GCP populates theprincipalSubject
field instead ofprincipalEmail
. This behavior is confirmed by the GCP documentation.Changes
get_actor_user
to useprincipalSubject
foractor_user
field whenprincipalEmail
is not presentget_actor_user
method to 'username' field since it was also mapping toprincipalEmail
previouslyGCP IAM serviceAccounts getAccessToken Privilege Escalation
to use theactor_user
udm fieldTesting
make lint
,make test
Principal Subject Used