In 1995, Nick Leeson aptly demonstrated the damage a single rogue employee can bestow on an unsuspecting organisation.
You’d have thought financial institutions would have learnt the lesson but Kweku Adoboli has proven that’s not the case when he caused Swiss bank UBS to lose over 2 billion dollars, as a result of unauthorized trading performed while he was a director of the bank’s Global Synthetic Equities Trading team. Or what about the example of a senior IT employee of Switzerland’s state intelligence service that downloaded terabytes of classified material using his admin rights? What he subsequently did with that information remains to be seen but the fact that he had access in the first place is obviously an issue.
Do you think you’ve got a rogue employee? Could you stop them before it’s too late?
Of course, some of you reading this article will be thinking, rather smugly, that of course you don’t have a rogue employee. You only employ hard working loyal individuals of high moral standing – and some of you could be right. However, 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. Of course, size isn’t everything and any organisation carries the risk of a malicious insider deciding to help themselves.
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 spread sheet 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 they can, then a rogue ex-employee could still have access to your systems. 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. Just as likely, an existing member of your staff could use the old credentials to point the finger of suspicion elsewhere.
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? Anonymity offers a rogue employee, or even a chancer, the perfect guise to perform misdoings as there’s little chance of identification after the fact.
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? Often people are granted permission to the new folders, but rarely is their previous access revoked.
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.
Unfortunately, this can generate opportunities that may prove too much for a rogue employee. What about employees in other locations and even countries? For some, the reward could outweigh the risk.
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. If you’re not monitoring what they’re up to, they don’t have to be afraid of getting caught!
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. You have a duty to your workforce that, if someone is rogue, you can identify them without blame falling on anyone else’s shoulders. Nothing affects morale as significantly as mistrust and suspicion.
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, perhaps the question isn’t necessarily how to spot the rogue, but how to make sure the damage caused is limited.
Getting a firm 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. As previously mentioned, you can’t take away access to the customer database from someone on the helpdesk, so making sure they don’t abuse it is the next best thing.
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.
About the Author:
Philip Lieberman | Founder & President | Liebsoft
Philip Lieberman, the founder and president of Lieberman Software, has more than 30 years of experience in the software industry. In addition to his proficiency as a software engineer, Mr. Lieberman is an astute entrepreneur able to perceive shortcomings in existing products on the market, and fill those gaps with innovative solutions. He developed the first products for the priviliedged identity management space, and continues to introduce new solutions to resolve the security threat of privileged account credentials. Mr. Lieberman has published numerous books and articles on computer science, has taught at UCLA, and has authored many computer science courses for Learning Tree International. He has a B.A. from San Francisco State University.
