It will hopefully come as no surprise to hear that employees are not permanently bound to their employers—this is called slavery, and is widely considered a bad thing. It is a fact of business life that employees may, one day, cease to be a part of your organisation. There may be many reasons for this, and the separation may be more or less mutual; more or less amicable. The one thing that all separations have in common is the need for you to have policies and procedures to be in place that will ensure a smooth transition, without leaving yourself vulnerable.
Many companies spend a lot of time thinking out their onboarding processes, which help new starters to quickly get up-to-speed with all of the logins and tools they need to perform their work. Whilst a well thought-out onboarding process can certainly provide efficiency and convenience, less focus is perhaps paid to the offboarding process, despite the security issues this can raise. This may be, in part, due to the need for the offboarding groundwork to be laid early on, often beginning with that aforementioned onboarding process. In this article, we’ll present some tricks to ensure a robust offboarding procedure. We’re only looking at technical aspects here, although offboarding should be far broader than this.
So, you’ve got a wide-eyed new starter arriving today to start their first day at your company. As part of your onboarding strategy you have already prepared a list of accounts that the new starter will require, along with temporary passwords to be reset by them upon their first login. You might be tempted to dispose of the list afterwards, but retaining a record of each employee’s work-related accounts is a vital step in being able to securely offboard them later. This is not just limited to accounts and access permissions set up on their first day, but to all subsequent work-related accounts the employee makes or is assigned. Leaving these on your system once their owner has moved on serves only to unnecessarily provide an attacker with potentially another way into your systems, or a convenient place to hide as they attempt to further penetrate your network or exfiltrate data.
Sometimes, it may not be possible to delete an account—perhaps there are regulatory reasons for it to be retained, or important files that can only be access through it. In the former case, the rights and privileges of the account should be limited as much as possible. Even if an attacker can get into the account, they should hopefully be unable to do much damage. In the latter case, every effort should be made to transfer ownership of those files to a current employee.
As Zack Holman writes, ‘you should automate the process of credential rolling as much as possible [because] as you grow, more people are inherently going to leave your company, and streamlining this process is going to make it easier on everyone’. Finally, remember that you should not just be revoking access to employees who leave acrimoniously. An ex-employee does not need to bear a grudge for their leftover access points to still provide a valuable window to an attacker.
