Splunk SOAR Playbooks: Finding and Disabling Inactive Users on AWS

Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.

Every organization that uses AWS has a set of user accounts that grant access to resources and data. The Identity and Access Management (IAM) service is the part of AWS that keeps track of all the users, groups, roles and policies that provide that access. Because it controls permissions for all other services, IAM is probably the single most important service in AWS to focus on from a security perspective. Over time, there are often personnel changes within the organization as users change roles or leave the company. When this happens, the user accounts may not get updated with the correct permissions or get deleted from IAM if the user is no longer an employee.

For this reason, Amazon describes the detection and removal of unused accounts as a fundamental best practice for any organization on AWS. Unused accounts that are not properly managed can end up being an entry point for malicious actors to gain access. Furthermore, IAM accounts are not just for human users. Applications, scripts and other services need IAM accounts to interact with AWS. Stale user accounts, whether they are for humans or applications, are a huge security risk for any organization.

So clearly it is important to regularly check inactive user accounts within your organization. This process is a prime candidate for automation so you can reduce time spent on it, and also to help you keep up the practice on a regular cadence. Our solution will involve two playbooks: one to find user accounts with passwords that have not been used in a long time, and another to disable those accounts.

The combination of these two playbooks will provide a semi-automated process that is repeatable and extensible. The first playbook will run on a scheduled interval, and the second playbook will be available to launch based on the results of the first playbook if there are any user accounts detected which are no longer in use.

In the rest of this blog post, we will take you step-by-step through how the playbooks work, how to deploy them, and some more advanced capabilities you can add to improve the playbooks. Want to see these two playbooks in action? Check out this video before diving into the written steps below!

Playbook I: AWS Find Inactive Users 

Our first playbook is a scheduled search for AWS user accounts where the password hasn’t been used for 90 days (by default). By building this into a playbook, we’re removing the need to manually write a query against the IAM API or manually look through the list of all of your user accounts to find those that are dormant. This playbook was created entirely in the visual playbook editor in Splunk Phantom, so there is no custom code. If additional capabilities are needed, the playbook can easily be extended by adding on after the last block.

Here is a screenshot of the playbook:

First, the playbook lists all user accounts in IAM. For large organizations, this could be hundreds or even thousands of people and applications with different levels of access to AWS. The next block in the playbook is the filter that determines which user accounts have a “password last used” date older than our chosen time range. Finally, the playbook gathers additional information about those unused accounts, and stores the results for further action.

Deploying the Playbook

In order to get this playbook up and running you’ll need to configure three apps, then activate the playbook. 

Here are the steps shown in the video above:

1. If you don’t already have Phantom, you can sign up and download the free community version here.
2. Configure an asset for the AWS IAM app on Phantom
   1. On your Phantom instance, navigate to Home>Apps>Unconfigured Apps>Search for AWS IAM>Configure New Asset.
   2. Give the asset a name such as “aws_iam.”
   3. On the Asset Settings page, provide an access key and secret key to give Phantom access to query AWS IAM. The required permissions are iam:ListUsers and iam:GetUser.
   4. Save and test connectivity to make sure the asset is functional.
3. Configure an asset for the Phantom App on Phantom
   1. On your Phantom instance, navigate to Home>Apps>Unconfigured Apps>Search for Phantom>Configure New Asset.
   2. Give the asset a name such as “phantom.”
   3. On the Asset Settings page provide the base URL of the Phantom instance you are using (everything before the first slash), and copy the ph-auth-token from Administration>User Management>Users>automation.
   4. Save and test connectivity to make sure the asset is functional.
4. Configure a timer to start the playbook on a scheduled interval
   1. Navigate to Home>Apps>Timer>Configure New Asset.
   2. Give the timer a name, such as “aws_find_inactive_users_timer.”
   3. On the Asset Settings page provide an event name, such as “AWS Find Inactive Users.”
   4. On the Ingest Settings page provide a new label name such as “aws find inactive users.”
   5. Also change the polling interval drop-down to “scheduled” and provide a time, such as “Every week on Thursday at 13:00.”
   6. Save the timer.
5. Configure and activate the playbook
   1. Navigate to Home>Playbooks and search for “aws_find_inactive_users.” If it’s not there, use the “Update from Source Control” button and select “community” to download new community playbooks.
   2. Click on the playbook name to open it.
   3. Resolve the playbook import wizard by selecting the newly created “aws_iam” and “phantom” assets.
   4. If you want to use another time instead of 90 days to determine if an account is stale, change the “amount_to_modify” field in the “calculate_start_time” block.
   5. Set the label to “aws find inactive users” or whichever label was created in the timer configuration.
   6. Set the playbook to “Active.”
   7. Save the playbook.

At this point the playbook should be scheduled and active. Navigate back to the Timer page and press the “Poll Now” button to create a test event and see the playbook in action.

Taking it Further

Once this playbook is up and running for a few weeks, it might make sense to come back to it and add additional actions. Are there automatable steps that you find yourself doing manually each time you generate a list of unused AWS accounts? For instance, if you always send a Slack message to the same channel when you find an unused account, you could configure the Slack App on Phantom and add a “send message” action to the playbook.

Similarly, you might find that you always look up the department or job role of the user, so you could add an Active Directory or Okta integration to pull that information into the artifact in Phantom automatically to save time. Elsewhere in AWS there may be other resources you want to monitor on a regular basis. We have 10 more apps in addition to IAM which manage other services on AWS, so the structure of this playbook is something you could repurpose in many other use cases.

Playbook II: Disable AWS User Accounts

After running the first playbook, you will have your list of stale user accounts, and the last thing you want to do is disable them all manually. Our second out-of-the-box playbook will automate that task for you. Once you identify an AWS user account as a problem and decide it shouldn’t be there, the playbook will run and disable it. Here’s how:

The playbook starts with a filter that checks the allowlist, which is a custom list containing AWS usernames that should not be disabled. Next, the playbook prompts an analyst with the names of the user accounts to be disabled. If the analyst confirms the action, the final block deletes the appropriate login profiles on the AWS console and disables the associated access keys.

Deploying the Playbook

Most of the prerequisites for this playbook were configured in the Playbook I deployment steps video above. The only additional steps are to ensure that the AWS IAM asset in Phantom is using an access key which has the correct privileges, and to initialize the allowlist for IAM usernames, which should be ignored.

1. In the AWS Console, navigate to the IAM service, choose “Policies” on the sidebar, and edit the policy used by the AWS IAM app on Phantom to include the following permissions:
   1. iam:CreateLoginProfile
   2. iam:DeleteLoginProfile
   3. iam:UpdateAccessKey
2. In Phantom, navigate to the Playbooks listing page and select “Custom Lists” on the top bar. Use the +List button to create a new custom list called “aws_inactive_user_allowlist.” For each trusted user account you don’t want to disable, create a new row with the username in the first column. Feel free to leave the list empty at first while establishing a baseline.

Taking it Further

Once this playbook has been in use for a trial period, it may make sense to circle back and add more automated steps. For instance, a Splunk Enterprise query could reveal other accounts or resources associated with users that have left the organization or changed teams. To make this playbook more proactive, you could also connect it to a more robust process for enforcing least privilege, such as a Jira ticket that is created to exhaustively enforce least privilege any time an organizational change occurs.

The possible use cases vary widely, but hopefully this simple example makes it easy to get started!

This blog is part of a series called “SOAR in Seconds” where our distinguished Splunk Phantom experts guide you through how to use out-of-the-box playbooks and other features to automate repetitive tasks.

----------------------------------------------------
Thanks!
Philip Royer