How do you handle the departure process when privileged or technical staff resign / get fired? Do you have a checklist of things to do to ensure the continuing operation / security of the company's infrastructure?
I'm trying to come up with a nice canonical list of things that my colleagues should do when I leave (I resigned a week ago, so I've got a month to tidy up and GTFO).
So far I've got:
Escort them off the premises
Delete their email Inbox (set all mail to forward to a catch-all)
Delete their SSH keys on server(s)
Delete their mysql user account(s)
...
So, what's next. What have I forgotten to mention, or might be similarly useful?
(endnote: Why is this off-topic? I'm a systems administrator, and this concerns continuing business security, this is definitely on-topic.)
I'd suggest creating a checklist of things you do when a new sysadmin joins the company (systems you need to add them to, groups their account has to go in, etc) and include both technical and physical things - e.g. physical keys and alarm codes are just as important as SSH keys and passwords.
Ensure you keep this list up to date - easier said than done, I know. But it makes it easier both to process new team members into the company and again to process them out. You can still do this now and get at least some of the benefit of using it to help with the person who is leaving. The reason I mention a checklist is because we all tend to think in our own spheres of comfort and different things might be missed out otherwise, depending on who is processing the leaver. For example: a "building security manager" or an "office manager" is going to be thinking more about door keys than SSH keys and an IT person will be the exact opposite and end up revoking their access to the system while leaving them able to walk into the building at night.
Then just go through their checklist when they leave, use it as a checklist of things to undo/get returned. All your IT team should be enthusiastic about this if they are professional as having an agreed process like this protects them from unwarranted blame from a former employer just as much as it protects the employer from them.
Don't forget things like access to remote datacentres or physical access to a 3rd party backup data repository.
I'm surprised no one mentioned that one before but...
If your WiFi network uses WPA or (I hope not) WEP as opposed to tapping in the Radius server, you might want to consider changing that key.
It's a huge door left open, if you're the network admin, there's a pretty good chance you know that key by heart...imagine how easy it would be to get back on the network from the parking lot or something of that nature.
Other things that spring to mind:
If some sysadmin leaves the company, we change all passwords for users (instead of the monthly password change). We have ldap and radius, so it isn't very difficult. Then we look at systems he was working on, as well as files that were created by/modified by him. If there is important data on his workstation, we clean or archive it.
We have access audit for all services that have users. If there is some unknown user using the service, we block him, at least until identification is passed.
Other systems will be cleaned in a week; most are for developing purposes and have no valuable information, and they're regularly cleaned by reinstallation.
Many good ideas in this thread... A few other things to consider:
I agree on changing passwords or disabling term'd user accounts versus deleting them (at least initially), however may be a good idea to check and see if user account is being used to run services/scheduled tasks before taking action. This is probably more important in a Windows/AD environment than a U
A few of the following items may be difficult to do if the employee leaves quickly or under less than ideal circumstances; but these can be important (particularly at those 2 am WTH just happened moments)
Knowledge transfer - While we all keep all of our documentation up-to-date (ahem, shuffles feet), it can be a good thing to schedule time with the short-timer and do some q & a or walkthroughs with another admin. If you have a lot of custom s/w running, or a complex environment it can be really helpful to ask questions and get some one-on-one time.
Along with that goes Passwords. Hopefully everyone is using some type of encrypted account/password storage (KeePass/PassSafe, etc). If that is the case, this should be pretty easy - get a copy of their file and the key to it. If not, it is time for some brain-dumping.
Start by changing all of the "perimeter" passwords for your network. Any accounts that he can use to get into your network from home (or from the parking lot with WiFi), should be changed immediately.
Once these are covered, work your way inward.
Other things to check for just to tidy things up:
Try to make sure that all password changes happen between 'leaver isolated from network' (maybe an exit interview in a conference room, after work laptop has been returned) and 'leaver is left to own devices'. This drastically lessens the chance that the leaver would be snooping the new credentials (but with smartphones and such-like, it's still non-null).
The above answers are all very good. As a practicing professional in the InfoSec profession (IT Auditor), some other points for you to consider:
Remove privileged administrative rights such as domain admin if you use Active Directory
Remove privileged database roles they may have had (ex: db_owner)
Inform external clients that the terminated user may have had access to so that access privileges can be revoked.
Remove local machine accounts if they had any in addition to domain access