So who guards the guards?

Here’s the scary thing about admins. They are hired to guard the security battlements, to be the keepers of the keys, and to pull an organization out of a hole when outsiders or employees do something inconvenient, unpleasant or worse. The job implies huge trust.

But what happens if an admin, to borrow military parlance, ‘goes rogue’? That it happens from time to time is well-established and yet most organizations remain almost defenseless against the threat posed by such a high-level insider attack.

Ask the Swiss Federal Intelligence Agency (NDB), which discovered earlier this year that one of its admins had become disaffected enough to siphon off terabytes (yes, terabytes) of top secret information with the hope of hawking it to the foreign intelligence services.

His ultra-sophisticated method of attack? He copied the data from secure servers to external hard drives, photocopied paper documents, and then left the building with them in his back-pack.

The press not surprisingly homed in on the possibility that the man almost certainly copied counter-terrorism data shared with Switzerland by the CIA and MI5, but the much bigger shocker was that the vast theft was only detected when a bank queried his attempt to set up a numbered bank account.

Let’s pay tribute to the Swiss Intelligence agency’s last line of a defense against a potentially disastrous data leak – a diligent clerk at a bank.

We don’t know what, if any, layers of security this admin has to sneak through to carry out his theft but is a no brainer that his admin access gave him a lot of freedom that wasn’t being adequately monitored or logged.

We do know, however, that under Windows Active Directory – the system through which admin rights are enacted for the majority of organizations – by default admins get full administrator rights to every PC and server on a given domain. A similar principle applies in a more limited way for every user on a network under Windows; even a humble desktop PC user with local admin rights has the power to install software as they choose and copy data to and from local drives.

That admins at times need this level of access and control is not in doubt but the Swiss example underlines that the security template should never be left this open-ended. Admins are a kind of technical manager, not super-users who should be allowed unquestioned or absolute control.

A lot depends on the admin structure at a given organization and which fail safes are built into a company’s administrative protocols, but technologies such as privilege management can certainly help matters on the basis of a number of key principles.

At the simplest level, admins should always be granted only the privileges they need and extra privileges should be requested using the same system used by any other user on the basis of policy. Crucially, when the need has ended, this access should automatically be revoked or at least time limited.

Importantly, as with every other user on the network, admins should have their activity tracked and logged by other members of the team in a form that allows both internal and external auditing, preferably through an automated reporting tool.

The defense against abuse by the super- admin can, then, be summed up in a single word: visibility. It was the lack of such a thing that allowed the unnamed Swiss intelligence admin to run amok as he pleased.

Granted, reinventing admins as ordinary users who just happen to have a degree of higher-level access necessary to do their jobs presents a culture change for many organizations stuck with the now-obsolete hierarchical idea of network power. But it is also now essential if organizations are to avoid becoming the next case study of insider disaster.