Employers Forgetting to Remove Access for Ex-Employees?

This devilish Anonymous Coward asks: "Quite by accident, I misdialed the other day and wound up in the voicemail system of my ex-employer, late of some 4 months now. Curious to see what would happen, I punched in my password, and lo-and-behold, I still had access to voicemail. Curious, I checked to see what I still had access to, and discovered that my shell account, Web logins and even the root password still existed as they did when I worked there. While I would never dream of trying anything funny (since they could pretty obviously track it back to me), I'm wondering how prevalent this lax attitude is in today's workplace, particularly in Silicon Valley where employees skip from job to job like mad. I'd bet that way too many Slashdotters still have access to things months or years after they left employment... including some pretty secure things." It's all a matter of the communication channels between the IT Department and Management. Better communication channels means less chance of this sort of security hole happening...or does it?

Comments

Gone but not forgotten

[maggard]

I've had old voicemail accounts last at least five years after leaving (that was as-of a few years ago - I'd check again but I can't remember the extension) and email accounts from places I left over a decade ago still working.

In places I've managed one of my first changes has been to insist that HR put a message on a email distribution list every time a position is created (note this is often well before someone is hired but it gives my staff time to determine the future employee's needs), upon a hiring, and the instant they believe someone may or will be leaving. In these communications HR must specify dates and the appropriate managers to contact for direct instruction. I also put an emergency procedure in place for 'rapid-separations' where all of a person's accounts are identified, marked for immediate back-up, and locked down until the situation is clarified.

I generally drive these policies & procedures home by holding a meeting between HR, IS, and Legal with all of us asked to brainstorm on the awful things that could happen should we drop the ball on this. One can usually come up with some very nasty scenarios pretty fast. The folks involved also generally know a few real-life stories we've seen or heard of we can recount just to completely scare everyone into following these policies seriously.

What can really force these policies is privacy laws. Even though many would think that communications to someone via a companies resources would be properly a companies property this changes a bit once the person is no longer an employee. I'm not a lawyer but I do know that in most places one is on shaky ground continuing to allow the former employee's name to remain active in the email system after a reasonable amount of time. To have someone then go through a former employees communications, specifically any that are received after the employee is separated from the company, is very dangerous and just asking for a nasty lawsuit.

My own solution to moved-on employees has been to place an auto-responder on the email account indicating the person is no longer with the company, possibly listing the other person(s) who are now handling the former employees responsibilities, and referring all other communications to HR. Generally this will do for up to a year after which the account just becomes another generic dead one. For voicemail a similar procedure is used by closing the person's inbox and replacing their old greeting with a new one giving the new numbers to contact for various services.

Of course one can avoid many of these problems by encouraging the use of functional email & voicemail accounts. With these many messages go to "Department - Function" instead of individual persons. One can't (and oftentimes shouldn't) get rid of personal email accounts but by keeping much of the purely administrative email on the functional address list does. Utilizing this duplicate system can cut down enormously on mail-list administration and general administrivia.

Another problem I commonly run into is the 'legacy' account where someone has moved on but another simply assumed their accounts, oftentimes their replacement. This sort of thing leads to really confusing situations where one isn't sure who is using what accounts, which are active, and which are linked. This can become particularly problematic when trying to implement unified login systems.

Finally there's the nightmare of IS staff leaving. Oftentimes we know waaay too many passwords, particularly the 'deep-mojo' ones. To help expedite these transitions I generally try to keep a list of all the primary accounts (passwords stored seperately in a secure place)and a instruction sheet on changing them all at need. It's also simply good practice to discourage users from giving passwords to IS staff and simply requiring them to enter themselves when needed.

Matter of policy

[Magus311X]

It's all a matter of the communication channels between the IT Department and Management. Better communication channels means less chance of this sort of security hole happening...or does it?

I've been at enough places to say that a lot of procedure indeed has to do with policy. If it isn't written down and enforced, more often than not it isn't executed.

Yes, things like this do happen, often because its not written in stone. You might think about changing the root password, but then you're just lazy, too comfortable typing it in during the blink of an eye, or too confident that since nothing has happened yet, nothing will happen.

Of course, we all know what happens when you do that - It leaves the potential for something to happen. This is why the manangerial staff that does know what they're doing gets on your case. Because unless you really care (and yes, plenty of IT staffers who give a damn, do), it might not get done.
-----

SSH with keys

[Rob Kaper]

We mainly use SSH with keys at work. No direct root access, you must first login as user with your key. From the outside, only one machine is accessable through SSH, so removing an employee from the list of allowed remote logins is as simple as removing his/her public key from that server. Surely works a lot better than all the hassle with passwords.. we still update the root password regularly, but if an ex-employee still knows it, that's not immediately a problem.

Is 50%pa turnover high?

[Kris_J]

We have a high staff turnover and a lack of clear policies. I always disable any individual remote access when I'm informed that a person has left, but otherwise most of our codes remain the same. The problem is that staff share their passwords a bit frequently and I'd really have to do a localised audit as each person left. Many passwords would have to change 2 or 3 times a month and remaining staff would start forgetting them (increasing turnover that bit more again).

But since staff are given full afterhours access to the building's main doors and our floor on the day they arrive (I was!) I think that outgoing IT security is the least of our worries...

"Why is this filing cabinet empty?"

What it means.

[mindstrm]

It means... that the IT manager doesn't know his job, and is not properly auditing security. Period.

For all the toys, code, and technology us IT people get to 'play' with at work, the bottom line is all too often forgotten: IT is there to provide computing facilities for a company and to maintain them appropriately.
If the IT staff left a hole like this, they should be yelled at.

Curiously enough, this problem is especially prevalent at shops WITHOUT senior type systems people. Lots of kids.

It's funny how hacker kids seem to know everything about security, but put them in an IT department, and they 'forget' all kinds of things like voicemail, door entry codes, leaving terminals logged in. Of course, they are REALLY busy fuckign with all the unix boxes 'just in case'.

Re:Sometimes, continuing access is on purpose

[Steve B]

Sometimes, when an employee leaves on good terms, there is a full intention that they will dial in or whatever from time to time to help transition responsbilities to other people

Then they should say so.
/.

Appropriate responses

[DaveHowe]

I think a lot depends on the circumstances. At our company, voicemail tends to be tied to individual handsets - so that stays until the desk is reassigned, at which point any outstanding voicemail is cleared, a new announce for the new user is set up and so forth.
Email is more marginal - if we are informed of a leaver, email is disconnected from the external gateway (internet email inbound will bounce) but is left in existance for a few weeks - many managers will have access to their leaver's account to clear up any outstanding stuff in the system. Unless requested otherwise, the email account is deleted when the network account is deleted.
Network accounts are disabled when a given user leaves (again, provided we are notified!) In addition, we audit account use - any Network account that hasn't been used in two months flags up an alert, and we contact the department to ask why.

Obviously, all of this applies to ordinary user accounts. for Techie accounts, it becomes more interesting. Email and network are disabled, as above, and any remote access keys are disabled too. However, there are three possibilities.

1. The techie left on friendly terms
   Any user accounts he held have their passwords disabled, but root accounts are left to expire and be cycled normally; Unless given a good reason to assume otherwise, this techie may want to look for references from us, possibly even another job in the future.
2. Techie left on unfriendly terms, without warning
   Unfriendly does not have to mean removed for cause; redundancy is equally valid. In this case, all root passwords (even ones he theoretically didn't know) are changed at once; account lists are searched for dubious accounts with either permissions they shouldn't have or with access entries matching the techie's pc.
3. Techie left on unfriendly terms with unsupervised access to machines
   nightmare scenario; User has been expelled from the building for cause, has resigned for reasons that are likely to indicate resentment of the company or individual managers (contributatory dismissal for example) or knew he was being downsized in advance and wasn't happy about it.
   This has to be any sysadmin's worst nightmare - the system is totally screwed. any or all servers may be rootkitted; timebombs or backdoors may exist in any utility or system program, backups may be corrupt, deliberate errors added in data that may take years to identify and fix.
   Procedure if this ever happened would be extreme - backup server (normally used for development testing) would be backed up then completely reinstalled from original media; new accounts set up and validated, software reinstalled and databases transferred. Backup server would become live server, live server pair would go offline and suffer similar indignities, after forensic examination by contract experts; user would be carried on payroll and his user accounts left untouched until the whole of SAP R/3's user code was validated by the DEV team; and even then, you could never be 100% sure.

Luckily we have never had a case of the nightmare scenario - but the procedures we could not afford to not follow would be massively more expensive and disruptive than even our worst-case disaster recovery plan.
--

Insist your accounts are deleted

[eap]

As an outgoing employee, you should make sure your own access to sensitive resources is eliminated when you leave. By knowing root passwords, you are placing yourself in a position of vulnerability if any systems are compromised.

It could be very easy for a disgruntled sysadmin to blame hacked system on you, when you aren't there to defend yourself.

At the least, it could mean a bad rec for you when you try to find another job, or worse, you could expose yourself to a lawsuit.

If you aren't sure your access is going to be cut off, then obtain proof that you attempted to have it removed by sending a letter to the appropriate mgmt body.

Re:Some companies are concerned

[fliplap]

To think changing passwords is going to it is naive. If thier violations of policy were this severe a total security audit would be appropriate. I used to work for a telemarketing firm (eww, yes it was that bad) Our admin had so many backdoors installed when I left, 6 monthes ago, it was obscene. A few minutes ago every last one was still there. The best solution would be to take all those backup tapes, put them in a safe place, and reinstall everything. Granted this can be a costly decision, sometimes its faster than fixing everything.

Some companies are concerned

[Suds9]

I just experienced a situation like this.

Both members of our two person IT department (I'm a finance geek) were recently found to violating several major company policies. Management decided the infractions were too serious to keep them on board. Our biggest concern after the decision was made was how we could secure our systems (internal network, internet site, ERP system, PBX system, etc.).

While the two were separately being told of the decision, several trusted IT consultants were in disconnecting our T-1s, disconnecting modems, and changing system passwords. By the time the two were escorted from the building, our systems were secured.