“So you work in service desk? Must be soul-killing to ask people to turn their computers off and on again all day”. This, or a variation, is by far the most common reaction I’ve had when I told people what I used to work with.
“We don’t handle security” is another common misconception among service desk people. Nothing can be farther from the truth! A big part of the daily operations are security-related. A normal week we may handle crypto trojan outbreaks, password resets that must comply with arbitrary “password strength” rules, deny people access to their account all the time with a service mind and a smile on our faces.
Support staff are low in hierarchy and salary, while typically having very high privilege in the systems that they’re maintaining. Therefore, they are an excellent attack vector for hackers with or without acting skills. I will discuss security issues related to service desk with the following categories: procedures, passwords, privilege, and insiders.
Disclaimer: I have worked on a service desk myself, but I am in no way implying that the specific vulnerabilities discussed here are present or exploitable at any of my former employers. I have chosen to write in the context of a service desk that handles Active Directory domains and works in the Swedish legal system, which may differ a bit from other European legal systems.
ProceduresProcedures, the most unappreciated part of any job. But they are oh, so important.
Procedures must: 1. Exist, 2. Be effective and possible to follow, 3. Actually be followed. Seems simple? Well, it’s not, because we’re dealing with people.
The first point is obvious: when procedures are absent, everyone has to work on their own and the risk of big mistakes is imminent. Such an environment must be a nightmare to work in, as there is no guidance and any disciplinary actions will be erratic and unfair.
The second point, processes must be possible to follow. Sometimes processes are ill-conceived and do not fulfill their purpose. Did you know that best practice in password management is to NOT force frequent password changes and that length is a better measure for password strength than complexity? Many companies still follow decades-old recommendations of eight-character passwords changing every three months, resulting in really poor and exploitable passwords across the board.
The other extreme would be that the processes are designed by a security nut like myself who thinks that everybody else regards confidentiality as the core functionality of any system. Result? Rigid protocols with zero usability. Most other people regard availability and usability as more important. Such a scheme will often end up being side-channeled, opening up new holes and thus creating a system that is weaker than it was before.
PasswordsActive Directory (AD) is a well-researched technology and a wide variety of attack vectors are known. It is entirely possible to harden an AD system to a point where most adversaries are deterred or discovered. Of course, there are a million ways to do it wrong and give people an unnecessarily easy time.
One is to send cleartext password resets via unencrypted channels. About 60% of all email traffic is encrypted in some way, but the encryption rate is lower on corporate email systems. Passwords in cleartext are also often stored in the Issue Tracking System (ITS) the service desk uses. Some of these systems are completely open towards an authenticated person, meaning that any employee can look up any password that has been sent out. The “Change password at first logon” option does not always work and is thus not always used.
One of the basics of password management is that password databases should never be stored in plaintext or with reversible crypto. According to best practice, they should be “salted” with a bit of extra padding and undergo a special purpose password hashing algorithm. Done properly, this greatly reduces the risks when users are using bad passwords. It reduces the risks when databases leak: the salt makes sure that the passwords cannot be cracked in bulk, and the slow hashing algorithm makes it impractical and expensive to make guesses. Active Directory uses no salt and an all-purpose hashing algorithm (MD4). If an AD password database is leaked, you can use Google to look up most passwords within milliseconds. Often any service desk employee has the privilege to extract the database.
PrivilegeGiving your key to your neighbor in order for them to water your plants does not mean you want to give them the privilege to look through your closet or bedroom drawers. For most of us, there is no possibility to technically restrict your neighbor’s access to your house to just the plants; you either give them access to all of the house, or you don’t give them access at all. This is a system that relies on trust. To put it mildly, this is not an ideal trust model for your IT infrastructure, but you would want one that relies on least privilege.
In many AD infrastructuresthe highest possible access rights are given out to all sysadmins who work with the environment. Or they have a procedure that includes having the same local admin password on all machines. In essence, this means that they put complete and blind trust in all of their staff. With that in mind, let’s go to the last point in this text:
Insider threatRecently there has been a story in the news about an alleged spy infiltrating the Swedish parliament . A weakness in parliament procedures makes the parties, not the parliament, responsible for background checks against secret service records for an employee. This has resulted in a man with at least five different identities being allowed high physical access.
A service desk employee often has domain administrator access to a variety of systems. They can do recon and identify weaknesses in infrastructures and procedures and leak this information. What is a company’s defense against this?A Non-Disclosure Agreement is standard nowadays and may deter leaks, but there are very few cases where people have been brought to trial.
Extracts from the criminal records registry (“utdrag ur belastningsregistret”) are increasingly popular, but they only show whether you have been found guilty of something in the last five years. For security classified objects a check against secret service registers is performed, but neither the public nor companies have any insight into how competently the secret service are performing their duties. Also, for integrity and proportionality reasons this kind of background check is not allowed for most service desks. Placing an agent in a service desk would thus be heaven for a determined hacker group. They can get a very clear picture of which of the above-listed vulnerabilities are present in any given infrastructure. But we also need to consider a less obvious form of insider: former employees.
Account lockout should be standard procedure in all cases where employees are leaving. The scenario that needs to be avoided is that of an employee with high access retaliating after feeling that they are wronged. They could extract information or destroy systems. This is obviously not a stealthy attack, and the risk for the raging insider is significant. But the rate of actual court cases on NDA violation and IT related crime is very low. Judicial control may be less effective than societal control in this regard.
Final words We need to get away from the picture of security threats as lone wolves with bad hygiene who remotely hack arbitrary sites for the lulz. And you should never underestimate the security issues with treating other people disrespectfully and unfairl
