20

So I'm having a debate with someone about whether or not to remove disabled accounts. My stance is that it is good network hygiene, reduces the amount of noise to sift through, etc. However, the argument is, what is the risk being addressed. I have been racking my brain on this one but I don't see a risk that this practice would address. Yes, the wildest of scenarios, someone could compromise the SaaS platform, reactive the account and use that for their awful deeds. But likeliness is extremely low. Even looking through all the governance frameworks state "Remove or Disable".

Is there any security risk that removing disabled accounts addresses?

  • 14
    What does "disabled" mean to you? Can they be re-enabled? Notice that under some jurisdictions you are actually legally obligated to completely delete your client data (after some period) when they cancel their account. – Bergi Feb 1 '18 at 19:59
  • 3
    I'm assuming that "accounts" are isolated. If one account is able to interact with another account's data, then you may have keep at least a stub account around for auditing purposes. Think, for example, Stack Exchange's deleted users. – Michael Feb 1 '18 at 20:17
  • 2
    The question didn't specify the OS or platform, but in a Windows environment, I find it more useful to leave the disabled domain accounts in the system for auditing purposes. Otherwise you end up with ACLs that show up as SIDs instead of names, which can create more work trying to find what they referenced. Disable, scramble the passwords, remove from groups, and call it a day. – GuitarPicker Feb 1 '18 at 21:23
  • 6
    Beware that this is now a HNQ, so is being broadcast network-wide as "Removing disabled users", which is open to misinterpretation. ("users with disabled accounts"?) – smci Feb 1 '18 at 21:23
  • 1
    That depends radically on what an account is and what it does. – Harper Feb 1 '18 at 23:54
21

In general, it is always best to reduce your attack surface. No system is ever perfect and your deactivation protocol will be no exception due to both programmatic and potential human error.

Risk 1: Let's say all your terminated employees accounts have been properly de-activated, for example via altering their role in the employee table in the database (or however they are stored). In this hypothetical scenario your administrator account has been compromised. A smart attacker may use the administrator account to re-enable a past terminated employee's account and use that account to conduct malicious activity on the system. By doing so, they are less likely to be discovered by intrusion detection systems (i.e. admin always logged in from Texas, USA but all of a sudden admin is in Brazil?). This could increase the attack surface and potentially give the attacker more power. Never a good thing.

Risk 2: Human error exists. What if one day you accidentally de-activate a still valid employees account and type Alex instead of Alexander when you wish to re-activate and now re-activated a terminated employees account? Or maybe you did not even mean to re-activate an account but one day when your computer was frozen and you were angrily spamming your mouse clicking at anything for a response, you clicked the reactivate flag?

Both cases are unlikely but why take the risk?

Unless your system has the need for a sophisticated audit trail that relies on still existent accounts in the system to work (i.e. does more than just print name of user and action to log but rather still actively accesses users info), there is no good reason to leave this bloat data in your system.

I always check after I leave a company (while working as a co-op in the past I frequently spent spurts of time at various companies) if I can still login to my accounts and more often than not, one way or another, I could.

Always err on the side of cyber-safety.

  • 16
    The titanic sunk, HTTPS had HeartBleed and Intel had Meltdown. Nothing is perfect and the belief it is possible your system is perfect breeds compliance to stop improving. Risk 1 is a simple and potentially exaggerated example to make an easy quick to reference point. Alternatively a rouge employee from in-office used a physical key logger on admin's computer, stole password and off company computer re-activated an account and controlled it from off-site after being terminated. For risk 2, see Titanic reference. I agree, but no system is perfect and in my experience such bad design is common. – dFrancisco Feb 1 '18 at 20:48
  • 2
    Reusing account identifiers for different people is generally dangerous. Keeping retired accounts in a database of account identifiers would seem the simplest way to guard against such reuse. – supercat Feb 1 '18 at 20:57
  • 1
    @supercat My database does not re-use primary key values of deleted rows, so that issue doesn't exist for me, but it is important to consider. For me, the main benefit of keeping retired accounts is that some of the information kept in the row can be used for useful data analysis, including preventing users from disabling their account and then making another account with the same phone number etc. – user169799 Feb 1 '18 at 21:06
  • 4
    I always think of this quote by Gene Spafford: The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts. – SeanC Feb 1 '18 at 21:42
  • 4
    @safebookverified you say that Systems can be perfect - perhaps, but I'd argue that so far in known human history, not one computer system has ever been made perfectly secure (and challenge you to provide example showing such "perfect" system). Nor (with each iteration of software/hardware things getting more complicated and thus more prone to bugs) can I foresee it changing for the better anytime soon. And believe me that this is optimistic view (as opposed to "We're doomed, man! Game over, man! Game over!" which is probably more likely to happen in next few decades) – Matija Nalis Feb 2 '18 at 1:06
7

First of all, I don't like to use the term "address a risk" because there are more accurate words than "address". I know it's a commonly used term in risk management but I feel it is likely to be misunderstood so I would rather avoid it.

Anyway, there is no security risk that removing a disabled account addresses. However, I believe you are asking the wrong question.

It depends on what you mean by "a disabled account".

A disabled account could be as simple as a row in a database with 2 columns, a primary key userid which is an integer, and an enum isdisabled which is set to "TRUE". Does deleting this disabled account address a risk? I don't think it does.

But on the other end of the spectrum the disabled account could contain credit card numbers, unencrypted passwords, photo of driver license, social security number, etc, along with isdisabled set to "TRUE".

What exactly is a "disabled account" in your scenario?

In general, I would recommend to never delete disabled accounts, and rather consider removing sensitive information at the point of "disabling" the account. So if a user disables and then reactivates their account, they will need to add card numbers again, re-verify their phone number, etc etc. So basically setting all flags to their default positions and keeping only non-sensitive information.

Keeping disabled accounts has value. You have a hard record of how many users have ever signed up, and you may consider to keep some of their information for various purposes. If a user signs up, verifies their phone number, then becomes blacklisted/banned by your system, then deactivates their account (and your "disabling" system either removes their phone number or removes their whole row including phone number), then they can sign up again with another email address and re-activate their phone number and potentially get around the blacklist (if your blacklist is a column isbanned).

So definitely keep your disabled accounts, just make sure to consider removing sensitive information from them, especially the kind of information users would expect you to delete that you can't possibly use for good purposes.

  • 1
    Also consider why you are disabling accounts rather than giving users the choice to delete them. I recommend not allowing users to delete their accounts, but allowing them to "disable" the account. This means the system deletes sensitive columns and keeps only columns which can be used for general system security and purposes that benefit other users of the system (by keeping dangerous users off the platform). Disabled accounts can also be re-activated (whereas deleted accounts can not). – user169799 Feb 1 '18 at 18:48
  • The application I'm looking at is a simple SaaS app. The accounts are stripped of everything and are basically just exist as disabled. I guess my thing would be an inventory type out look of the more you have, the more you have to analyze/maintain. – POSH Geek Feb 1 '18 at 18:49
  • 2
    Well, if the rows have no useful information then it may be worth deleting them. But if you make this change, I would suggest never disabling them at all - just delete them instead (I assume they are being disabled when they expire). However, I would suggest rather than making this change, consider which information can be left in the rows that could be useful later. First of all, if you at least leave the email address there, and if your service is one where people pay monthly subscriptions, then you could send an email after 3 months of being disabled to prompt them to re-subscribe. – user169799 Feb 1 '18 at 18:58
  • Also note that if you're planning on allowing European customers to use the system, due to GDPR regulation becoming binding if few months, not removing all personal data (including things like name, phone number, email addresses etc) will not be an option anymore. – Matija Nalis Feb 2 '18 at 1:12
  • If you want to keep non-sensitive data about users for analytics (including "fraud" detection) for a variety of reasons, it should most likely be extracted out of the "users" table(s) and stored in a separate (set of) table(s), possibly an entirely different data store. There's little reason to keep the records in the OLTP database. – Derek Elkins Feb 2 '18 at 6:14
3

The first question is: how reliable is your deactivation procedure? (if the answer is "100%", I'd suggest you're most likely not being honest with yourself.) Removing unused accounts helps ensure that terminated employees, even if their account misses deactivation, still are removed from the system in question. And ensuring that former employees do not continue to have access is a good security practice.

In theory a locked account shouldn't present much risk. If someone reactivates a disabled account, they're already in your network with admin credentials. But it would still be a good thing to not give them additional room to play in. Let's assume that this breach happened. You'd then need to go through all your terminated employees and ensure that their accounts have all been deactivated to ensure that the bad guys don't just come back in through the back door they've activated/created. Additionally, paring down disabled accounts reduces the potential attack surface.

In a validated environment, those accounts need to be kept around for documentation and audit purposes. There it makes sense to move them into a "disabled" OU and run a check against them nightly to ensure that they don't somehow get reactivated.

TL/DR: unless there's a good reason to keep these accounts around, it makes more sense to remove them.

  • LOL I'm a consultant and having this conversation right now with the client. It is in a SaaS application so trying to convince them that deleting is the better way to go. – POSH Geek Feb 1 '18 at 18:54
  • 1
    "If someone reactivates a disabled account, they're already in your network with admin credentials." there are other ways to do that. You're basically paraphrasing the OP's question in your answer. – Tom K. Feb 1 '18 at 19:37
2

What user accounts are your talking about?

An easy example where you should keep them: Accounts on your unix server.

If you do not keep the account, you won't be able to attribute any files you find somewhere if they belong to a deleted user. When the user id (the numeric one, not the name) is given a new account the new user will even be able to access the remaining files of the old one.

  • What exactly does this add to any of the existing answers? – Tom K. Feb 2 '18 at 15:12
  • 1
    @TomK. That you should consider file ownership and numeric ids which will be reused if the user account is fully deleted. – allo Feb 2 '18 at 15:56
1

Most answers focus on the security aspect of this question, rightfully so considering this site is focused on security. But there is another aspect to this, that being the legal troubles that come with holding data you don't need.

Leaving accounts that are no longer used, leaves tons of unused and likely unregulated data. This not only increases the attractiveness of the system as a target, but also can land the company/owner of the software in some significant legal trouble depending on the country. If someone was to leak or sell data that they've gained access to, the company is then liable (in most countries) for the data of each leaked account where sensitive data has been recorded.

Security shouldn't just include prevention, but also mitigation and damage control. Even if the company is completely covered with regards to the law when it comes to data breaches and leaks, making the system as unattractive as possible is definitely a good practice. Anybody who is seriously considering attacking a system for malicious gain, will be picking targets based off of a [Data obtained : Time/effort required] ratio. Minimising the amount of data in a system is much easier than exponentially increasing the difficulty for an attacker.

0

In my own solution user accounts are never deleted to avoid reusing IDs (user names, POSIX-IDs) assigned before.

But there are two different states for deactivating the user accounts:

  1. deactivated: Account is temporarily de-activated, still seen by the so-called zone admins and can be re-activated by a zone admin.
  2. archived: Account is finally de-activated, some attributes are stripped away due to privacy regulations. Accounts are not visible anymore for the zone admins and cannot be re-activated from this state.

See also description of Æ-DIR's attribute aeStatus.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.