(Six Best Practices to Remove Dormant Identities in the Cloud…without fear of business repercussions)
Do you know that you probably have a ton of dormant identities with access to your organization’s data?
%20(1).jpg)
Perhaps you do know, and perhaps you don’t know.
If you do know, then you know how fraught with “danger” disabling these dormant identities can be, even though they are so obviously not being used. In fact, despite organizations knowing that they have dormant identities, the average time to them can be over 185 days. That is an awfully long and inviting time to leave an identity unmonitored, particularly one that could potentially be used to gain access to your data.
Why do organizations struggle to disable dormant identities?
Murphy’s law seems to apply in this case—if something can go wrong, it will. With dormant identities, regardless of how long you wait, it will be just your luck that a legitimate identity will attempt to use that identity almost immediately after it is disabled. The user’s expected frustration of not being able to remember the password will be quickly replaced with anger directed at IT, security, and technology in general, because, in their mind, the technology has broken yet again.
The “danger” from disabling a dormant identity usually comes from the swift and over-exaggerated organizational repercussions, as that anger is often directed to the security or IT executive. It is fair to say that senior executives seem to gain an amazing amount of satisfaction from unfairly castigating their fellow executives (or as we say in Australia, “ripping them a new one”) for doing something so wrongful as protecting their organization. This castigation usually increases in intensity until it lands on the poor cloud security team who was simply enforcing their enterprise security policy to begin with.
How do you avoid the inevitable repercussions?
We pride ourselves at Symmetry Systems in being able to help our customers make meaningful and lasting improvements to their data security posture, so I asked our team to identify some of the best practices they have seen work in reducing dormant identities, while avoiding the unnecessary political heat. Many thanks to the amazing Jake Attia and others from the team at Symmetry Systems for their contributions, including Gopi Ramamoorthy, Eran Abramovitz, and Rajiv Sinha.
Best Practice 1: Define and monitor for dormant identities
As I hinted above, some organizations might not even be aware they have dormant identities in their environment; so clearly you have to start monitoring dormancy. The most critical dormant identities in the current threat environment are accounts with access to the things you care about most: data.
Fundamentals include creating a clear definition of what constitutes a dormant identity. You should consider :
- The length of dormancy (usually defined by number of days).
- The type of account (root account, service account, customer account, break glass accounts, etc.).
- The environment (disaster recovery or other standby environments may differ in usage).
You obviously also need to be monitoring for dormancy. This means having full visibility of all the identities and the operations they are performing in your environment to be able to determine the date of the last operation performed in the environment. It is important to remember that dormancy can vary by environment—which means being conscious of cross account operations. That is a story for another day though.
Most important, to avoid business impact, is having processes in place to ensure that the metadata associated with each identity and each datastore is accurate and current. The metadata should include, at a minimum, the owner’s name, their email address, and any other details that may impact dormancy. I’ve regularly seen organizations overlook maternity, paternity, and other extended leave when cleaning things up.
Best Practice 2: Prioritize identities based on risk
Don’t kid yourself. You’re likely to have a lot of dormant identities to start with, and more will keep becoming dormant as users leave the organization, change roles, or don’t use the access that their department manager thinks they will use.
Disable all the accounts at once at your own risk! Start small and focused. You need to prioritize, and it’s best to prioritize based on risk. Prioritize accounts based on:
- Whether multifactor authentication (MFA) is turned on.
- The volume of data that the identity can access in the environment.
- The sensitivity of the data that the identity can access.
- What operations can be performed by the identity against the data, identities, and other cloud resources (delete, remove, etc.) and the risks if these operations are performed.
You might also want to monitor for occurrences of the account on the dark web and in password compromises.
Best Practice 3: Turn on the detection seatbelts
Start monitoring and alert on any account usage. If you ever wanted a high-fidelity signal of potential compromise of an account that requires investigation, look no further than an account that hasn’t been used for a while that starts to suddenly access data. Monitoring and Alerting could help you avoid becoming the next Drizly.
Best Practice 4: Gather context about the owner of the account
It might sound obvious, but without knowing context about the account, you are asking for trouble. At a minimum, you need to identify the owner of the account to proactively avoid their anger if they decide to use the account in the future. This requires gathering context about:
- The owner, which might require tracing the account to request and approval records (if they exist), if not clearly identified in the account name or metadata.
- The status of other accounts with the same owner in other environments—a significant number of accounts in cloud environments are due to failures in the employee termination process to adequately remove downstream accounts.
- The hierarchy—particularly line managers are useful contacts for determining the legitimacy of maintaining dormant identities.
Best Practice 5: Communicate, Communicate, Communicate
When disabling accounts that may be perceived to have potential business impact, it is always best to communicate. This may be targeted communications if the owner is known and still with the organization or may be general communications to departments and users of specific applications. Including the line manager of known accounts is a valid way to remove unnecessary repercussions.
Best Practice 6: Limit access for active users rather than remove
The most powerful recommendation to reduce user repercussions is to ensure that access is not simply removed or disabled, but limited when the user is active. Removing access tends to result in an “access denied” message. From a user perspective, they know they should have access so assume this is yet another failure by IT or security; rather than removal of permissions due to inactivity. It also provides no context on what the next steps would be to regain access.
Leading organizations instead limit access so that users can still view metadata about the data resources, but cannot access the data itself. This allows them to view what data they were attempting to access and, more importantly, who the owner of the data object or data store is. This provides an easy path to regaining access.
For example, we can move dormant users into a permissions scope that removes direct data access to an S3 bucket, but still allows visibility of useful S3 bucket and object attributes. In the policy statement below, the S3 permissions assigned to metadata_viewer_group only allow viewing of bucket and object attributes without the ability to GET objects or download via AWS console etc).
| { “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “VisualEditor0”, “Effect”: “Allow”, “Action”: [ “s3:ListAllMyBuckets”, “s3:ListBucketVersions”, “s3:GetObjectAttributes”, “s3:ListBucket”, “s3:GetObjectVersionAttributes” ], “Resource”: “*” } ] } |
As a result of this reduction in permissions, users that become members of metadata_viewers_group can view useful metadata and attributes like the owner through List Buckets. This provides confirmation that the object still exists, what it was, and who they need to contact.
| aws s3api list-buckets |
Also in the AWS Console:
However, any Get-Object operation will fail:
Downloading object via AWS console fails with a 403 error:
Whatever you do, don’t ignore the problem simply because it requires effort.
Dormant identities are unnecessary expansions of your attack surface—often providing attackers with a direct and unmonitored access point to sensitive information. In the worst case, that dormant identity is using previously compromised and easily guessable credentials that were involved in a data breach and can be linked to your organization. Dormant identities are less likely to be actively monitored and credentials rotated when notified of involvement in an external breach.
While there is no magic formula for controlling dormant identities, a data security posture management (DSPM) solution can be an immense help in understanding and prioritizing your dormant identities. More importantly it will enable your cybersecurity teams to monitor and investigate unusual activity from previously dormant identities.
To learn more about DSPM or see a DSPM solution in action, please reach out. We’d love to show you how DataGuard can help drastically improve the number of dormant identities and the length of their dormancy.
Share this entry