Spoiling staff with toys could turn against your business

One size fits all

We have all seen it: you engage a third party to support one or other of your systems, which means they need to be able to connect remotely and log in. And those of us who are old enough have also seen, when picking up the pieces of something that broke, that the last login before the crash was from “acme-support”.

Which of the 25 people in the third party's support team was that? Or was it even one of them, since if they all know the credentials for that account then it is likely that others do too.

In the same vein, I come from the good old days of Unix when you could only log in directly as the “root” user (the omnipotent super-user) from what was called a “secure terminal” – generally the console plugged physically into the box.

To become the root user from any other terminal required you to log in as a normal user with your own ID and then switch to the root user – which was logged. These days the default configuration on many Unix/Linux systems is to allow native root access from anywhere, which kills accountability.

Generic logins are the work of the Devil, and they generally exist because it is a faff to create a login for each individual in a team. Yes, it is a faff, but once it is set up you generally don't have to expend much effort on starters and leavers in the team, and the payback with regard to audit logging is huge.

Shtum and shtummer

Sharing your login credentials should be a capital offence. At the very least it should be a disciplinary offence.

If a user tells someone his or her password and then it is used to do something stupid or malicious, then two people need to be sacked: the person who did the action and the person who hindered the diagnosis by disclosing their credentials and sending the IT team in the wrong direction.

Oh, and talking to the IT support team should be like talking to your bank. Your bank will never ask you for your debit card's PIN, and neither should the IT gang ever need to ask you for your password.

They should have sufficient access to diagnose a problem without needing to log in as a user. If they do need to see what the user sees they should remote-control the desktop and walk through the process with the user present so the user can be sure they are not going to break anything.

Yet people share credentials and get away with it. Just don't do it.

Another thing: can your users sync their personal phones to your mail server and do email on the hoof? Yes? Well, they shouldn't be able to.

What happens if a user leaves the business – or gets punted? Answer: they take their confidential company email with them.

There is really no excuse. There are so many mobile device management packages on the market that allow you to offer corporate email on users' personal devices while being able to ensure it is blown away if they leave.

These packages usually either involve a “sandbox” email application that users can access only if their device is in contact with your corporate security server and that server says, “yes, this is a permitted activity”; or they hook into the enterprise-related features built into device operating systems such as iOS which allow remote wiping of data.

Loads of companies permit users to access their corporate email natively. They shouldn't.

New boys and girls

What prompts you to create a new user in your corporate Active Directory database? A form filled in by a manager who has just recruited someone? Users calling the help desk the day they start and asking to be created? Wrong answer in both cases.

In an ideal world the HR department would have the ability to create and remove users via a nice friendly non-technical interface where they just tick the boxes relating to the user's role.

The next best thing is for HR to request the IT department to do this, which is common as not many companies have a system that is sufficiently friendly for the HR people to use.

What about when you engage a third party to do some work and this requires them to have access to your systems? Requests like that don't go through HR – it is just a contractual relationship with the service provider.

The average company has a hefty list of active user accounts for people who no longer work there

But in fact they probably should go through HR – or at the very least a single, specified “clearing house” that can monitor and control comings and goings.

It is particularly important that when non-permanent staff's logins are created they are configured with the individuals' end dates so the system automatically disables their accounts when they are due to leave.

When a full-time member of staff leaves the HR department knows about it (they have know to stop paying them) but contractors very often just vanish into the night with nobody noticing – or disabling their login, their remote access and so on.

The big mistake when taking someone on and setting them up is to leave their finish date blank and not follow up later. The average company has a hefty list of active user accounts for people who no longer work there.