20

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:

  1. Escort them off the premises

  2. Delete their email Inbox (set all mail to forward to a catch-all)

  3. Delete their SSH keys on server(s)

  4. 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.)

12
  • relevant (not nessecarily a dupe) serverfault.com/questions/171893/…
    – tombull89
    Jun 30, 2011 at 11:10
  • 4
    Be aware of e-mail forwarding; there are several countries where this isn't allowed. In Norway we're not even allowed to give out auto-reples stating that the employee no longer works here, we have to wipe the account completely. The standard NDR (non-existant user) is the only thing allowed.
    – pauska
    Jun 30, 2011 at 11:15
  • 1
    Is it common for people to be exported off the premises? I would imagine that would only be necessary when people are fired.
    – Vetle
    Jun 30, 2011 at 14:07
  • 3
    Are you certain you want to delete their email inbox? When a coworker was instant-fired from a job I worked at, going through their inbox allowed me to quickly figure out what decisions had been made on projects that I suddenly found myself managing. I think (depending on legality) you might want to reconsider #2. Jun 30, 2011 at 16:50
  • 2
    @Tim: digi.no/803038/reglene-for-epost-duger-ikke
    – pauska
    Jul 1, 2011 at 12:31

10 Answers 10

7

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.

6

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.

2
  • 1
    This is usually solved by having it authenticate against AD or any other directory service. Once the account is deleted, you can't get on anymore.
    – Split71
    Jun 30, 2011 at 16:33
  • @Split71: The now-departed admin might not be able to get into the servers directly, but if they're on the local, trusted network, they've got access to the soft, squishy underbelly of all your infrastructure.
    – womble
    Jul 28, 2011 at 14:42
5

Other things that spring to mind:

  • Physical security - take away keys / access tags / vpn tags / laptops
  • Take away phones / blackberries
  • Remove / disable any accounts they have on external services / sites
  • Lock their user account
  • Change any shared passwords they may know (I appreciate you shouldn't have any shared passwords)
  • Disable VPN account
  • Ensure all bugs / tickets / issues etc in any tracking systems are reassigned
4
  • Take them off the nagios/paging system
  • Remove their sudo (just in case)
  • Tell the datacentre(s)
  • Disable/revoke any vpn system into the office network
  • Disable any web applications/apache confs/firewalls that have their IP addresses hardcoded in
2

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.

1

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.

1

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.

  • Remote administration passwords for routers and firewalls?
  • VPN accounts? What about the admin accounts on the VPN?
  • WiFi encryption?
  • Browser-based e-mail (OWA)?

Once these are covered, work your way inward.

1

Other things to check for just to tidy things up:

  • if they had a static IP address, mark as available
  • remove/clean up any custom DNS records if possible
  • remove from any sort of employee directory
  • phones
  • remove email address from any sort of automated report being sent out by a server or a service
  • if you keep hardware/software inventory, mark hardware and software licenses as available (this really depends on how you manage these things).
1

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).

0

The above answers are all very good. As a practicing professional in the InfoSec profession (IT Auditor), some other points for you to consider:

  1. Remove privileged administrative rights such as domain admin if you use Active Directory

  2. Remove privileged database roles they may have had (ex: db_owner)

  3. Inform external clients that the terminated user may have had access to so that access privileges can be revoked.

  4. Remove local machine accounts if they had any in addition to domain access

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .