It seems that stories of employees ‘going rogue’ are always in the press – but how can companies stop them before they make the headlines? Do you even know if you have a rogue employee?
If you’re a large multi-national organisation, the laws of probability aren’t in your favour. Add to the mix a person who’s earning minimum wage, handling data that has a retail value on the black market and the temptation might, one day, just prove too much.
For arguments sake, let’s say within your workforce is an individual down on his luck and desperate enough to do something out of character. Your security measures in place prevent your systems from harm – don’t they? Let’s take a short quiz to see if you’re right.
Q1. Is it possible for a member of the IT team to get into anything they want, whenever they want?
If you answered yes, then you could have a rogue employee working within your IT team. If IT use an ‘admin’ account that’s shared amongst the team, then your information and system is not only at risk but you have no way of telling who is to blame if something does go wrong.
Q2. Do you have a spreadsheet that has every password on it just in case someone forgets theirs?
If so, then a rogue employee could also know every password. Think for a second, do you know who can, or has, accessed it? Would you even know?
Q3. Can former employees still use their credentials to get into your company?
If you don’t automatically decommission a former employee’s account, and change all the credentials for any shared systems, then a person can still wander unchallenged virtually within the organisation long after their names have been removed from the payroll.
Q4. Are all your machines set to the same password?
If the answer is yes, then a rogue employee could access any machine. Even if you have a handful of passwords someone could ‘guess’ the correct one. Having used the credentials to access the machine, would you be able to determine who’s hiding behind the nameless ID?
Q5. How many people in your organisation have access to information that they don’t need to perform their roles? For example, can your accounts team access HR records, or can HR see the R&D results?
If so, then a rogue employee could be selling your secrets. Even if you answered no, are you 100% sure? Has anyone changed roles recently within your organisation and has their access been changed accordingly?
Q6. Do you have people working on the helpdesk that are on a relatively low income?
The help desk employees may have the ability to reset passwords and access systems in an unrestricted manner giving them full and unaudited access to department computers such as: HR, financial, R&D, and Executive Management. Since the access is via generic or impersonated accounts, there is no trail and unlimited access for a potentially anonymous off-shore or local minimum wage person.
Q7. Are you monitoring what employees are doing with the access that they do legitimately have?
If you are then you might detect a rogue employee, but could you stop them? Just because someone has legitimate reason to access the customer database, or the R&D material, doesn’t mean they won’t do something they shouldn’t.
Q8. Do you see anything wrong with any of the practices in Q1 – Q7?
If you answered no … then you could and probably deserve to have a rogue employee. In my opinion, ignorance isn’t bliss. Failing to grasp the severity of the risks any organisation faces from insecure processes, that potentially allow an employee carte blanche access with little risk of being identified, is tantamount to negligence.
How to spot the rogue
Organisations have built solid businesses on doing just that, conducting stringent testing and behavioural analysis of a person’s psyche to determine the risk they pose to your security. However, the question isn’t necessarily how to spot the rogue, but how to make sure any damage is limited.
Getting a handle on the permissions within your organisation is one piece of the puzzle, as is control over your privileged accounts. Considered the “keys to the IT kingdom” privileged accounts include UNIX root, Windows Administrator or accounts associated with database ownership and router access. Making sure people have only enough access to get the job done closes most exploitable avenues. The next element is close monitoring and auditing for what people are doing with the permissions they have.
In summary here’s a good idea:
• Identify and track the location of privileged account passwords
• Delegate so that only appropriate personnel can access privileged accounts
• Enforce rules for password strength, uniqueness and change frequency
• Audit and alert so that requesters, purpose and duration of privileged account use are documented
Don’t allow a rogue employee to hide behind anonymity –attribution will make him identifiable and time-limited access will stop him in his tracks.
