Skip to main content
Splunk Lantern

Identifying inactive user accounts in AWS

Scenario: Your organization relies on the Identity and Access Management (IAM) service of AWS to keep track of all the users, groups, roles, and policies that provide access to data and resources. 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. You know that stale user accounts, whether they are for humans or applications, are a huge security risk for any organization. You would like to create a semi-automated process that is repeatable and extensible for identifying inactive users.

Prerequisites

To succeed in implementing this use case, you need the following dependencies, resources, and information.

How to use Splunk software for this use case

This playbook creates a scheduled search for AWS user accounts with a password that hasn’t been used for 90 days. 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 your chosen time range. Finally, the playbook gathers additional information about those unused accounts, and stores the results for further action. To use the playbook:

  1. Configure an asset for the AWS IAM app on Splunk SOAR.
    1. On your Splunk SOAR instance, navigate to Home>Apps>Unconfigured Apps>Search for AWS IAM>Configure New Asset.
    2. Give the asset a name. For example, “aws_iam”.
    3. On the Asset Settings page, provide an access key and secret key to give Splunk SOAR 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.
  2. Configure an asset for the Phantom App on Splunk SOAR.
    1. On your Splunk SOAR instance, navigate to Home>Apps>Unconfigured Apps>Search for Phantom>Configure New Asset.
    2. Give the asset a name. For example, “phantom”.
    3. On the Asset Settings page, provide the base URL of the Splunk SOAR instance you use (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.
  3. 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. For example, “aws find inactive users”.
    5. Change the polling interval drop-down to “scheduled” and provide a time. For example, “Every week on Thursday at 13:00”.
    6. Save the timer.
  4. If you haven't previously used this playbook, configure and activate it.
    1. Navigate to Home>Playbooks and search for aws_find_inactive_users. If it’s not there, click Update from Source Control and select Community to download new community playbooks.
    2. Click 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.
  5. Navigate back to the Timer page and click Poll Now to create a test event and see the playbook in action.
     

Results

After 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 Splunk SOAR automatically to save time.

Additional resources

These additional Splunk resources might help you understand and implement this use case:

  • Was this article helpful?