cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
d46j48fx
Contributor I

Deleting inactive accounts

Client user accounts are disabled on day of departure.  

Client is getting multiple alerts of failed attempts to log in to the disabled accounts, including some from "risky countries".  Security team is recommending the deletion of the disabled accounts after <period of inactivity>, but IT Ops are pushing back - "The account is already disabled; what's the risk?  What do we gain by deleting the account, apart from storage space?".  How can the security team persuade the GRC committee (c-suite audience who will make the final decision) to support the Security team's recommendation...or does IT Ops have a point? 

5 Replies
denbesten
Community Champion

I do get Ops' concern. Deletion tends to be more permanent and more likely to result in data loss, potentially including company data stored in the user's account. And, it can be hard to reverse, particularly in SAAS environments and if AD "SIDs" are destroyed.  Before accepting Ops' position you might ask them to demonstrate that disabled accounts can not be reenabled the through self-service password reset, social engineering of the help desk, etc.  Something as simple as appending "-disabled-2024-03-02" end of the username might be the trick to balance the Ops and Security goals.

 

The leadership discussion ought to surround the creation of a formal retention period for data, balancing the company's need to do business and prevent data loss against the depths to which they wish to facilitate legal discovery and their willingness to pay for drive space.  That policy will then drive the duration after which a disabled account is deleted. 

 

That said, You are burying the lead.  Why are the alerts suddenly coming in? Is this a new thing or were they being suppressed/ignored prior the the disablement?  Can you validate they all failed in the before-days?  Are similar things happening to other accounts?   Does the monitoring need to be tweaked? Can you determine if they are coming from the former-employee (if so, legal needs to be involved)?

 

d46j48fx
Contributor I

@denbesten , thanks for the guidance here; much appreciated!  Pulling the thread on changing the name of the disabled account, would the balance be that the SID (and the associated data) could be retained for, say, regulatory compliance, while resulting in an "account not found" type of error for the threat actor because they are trying to log in with a username that does not exist?  I just want to ensure I'm understanding the mitigation correctly.

Regarding the logins, the SIEM logs all failed logins, and tripwires are in place to alert the client, which is how they found out about the failed logins. The client is trying to ascertain whether it is a former employee/contractor trying to login or a [rarely-used] app/service that was coded with a user account instead of a service account. 

denbesten
Community Champion


@d46j48fx wrote:

@denbesten , thanks for the guidance here; much appreciated!  Pulling the thread on changing the name of the disabled account, would the balance be that the SID (and the associated data) could be retained for, say, regulatory compliance, while resulting in an "account not found" type of error for the threat actor because they are trying to log in with a username that does not exist?  I just want to ensure I'm understanding the mitigation correctly.


A few things.  The username is invalidated if it is stored anywhere (wifi config, contact lists, breached accounts, etc).  Plus, it serves as a visual indicator to the call center that the account was intentionally disabled.

 

Disabling instead of deleting also allows file security properties to continue listing a human readable name instead of an ugly SID.  Another trick my company uses is to move disabled accounts to an OU that has an extremely burdensome group policy and that requires substantial privileges to move users out.

tolda3000
Newcomer I

What do your current policies and procedure's state? If noting exists, good on ya, you get to create one and customize it specific to business needs, yeah!

 

If noting exists, or you see gaps in the process, look at ITIL, ISO, NIST, and even PCI, and others for their recommendation on retention of terminated user accounts. Use the longest retention time (of those suggestions above that are specific to your industry, eg. if you don't process credit cards, don't sweat PCI) to your policy; I would guess that 90 days is the answer.

 

Term accounts, as others have stated, append something to the account to denote the status visually and in your user management tools. You can do it to the display name if you are concerned about orphaning objects, and items the user created on various federated tools. 

 

Upon disabling, you should migrate their data to some type of secure filesystem, let the manager or the individual who would become the data owner to review the users digital artifacts. Add that to your policy and how long the manager/data owner has access before it is archived to tape and then eventually deleted. 

 

You could delete the email account from the user object. Some people use corp mail as a freaking file system which can be annoying to backup. You could consider putting a forwarder for their manager for 90 days as well, whatever works for your business's needs.

 

Part of the procedure should include an "account/user term checklist" for termination that has to move through the IT, Ops, Sec, Mgmt, and HR teams, this should be signed by each manager once their respective responsibility has been completed. 

 

This is FAR from a comprehensive list, simply some things I have used in the past. Moreover, I want to provide you with suggestions to focus you back on your CISSP knowledge and to give you some places that you can create policies that would pass third party auditing and to empower you to improved your new term process. 

 

Always, refer to your policies and procedures, lacking them, document and get approval from stakeholders and your CISO and maybe the legal team first.

 

Finally, data can bite in the posterior, if you keep it too long! This is especially true if the sector of industry your business belongs is highly litigious.

 

Best of luck!

 

tolda3000
Newcomer I

Yes, what this one said!

Wonderful, and obviously qualified, advice...I see you! My favorite part, is the last paragraph; I'd be your wingman anytime! <thumbs up>