Security, et al

Chances are you’ve heard about the network administrator, Terry Childs, who reportedly held the City of San Francisco’s network hostage last week rather than sharing access with fellow IT folks. Clearly, this was a management issue first and foremost. But whether you think he’s a good guy or bad guy and regardless of his motivations, rogue admins are a fact of life. I don’t have anything against admins - I’ve been one myself. It’s just that admins are humans like everyone else and sometimes to doing bad things. I think an even more compelling public account of a rogue admin is the Roger Duronio / UBS PaineWebber case from a few years back.

The bottom line is when you give someone admin authority you lose all preventive control over them. Today’s operating systems, databases and applications do not have effective separation of duty features built-in for controlling admin operations, end user access - yes, admin tasks - no. Once you are an administrator you can do anything.

To mitigate this risk we first need to reduce how many people have admin authority and some technologies make it easier to do this than others. For instance Active Directory allows an IT department to follow least privilege thanks to AD’s delegation of control feature. If you determine the various roles within an IT department you can delegate just the authority to perform each role’s respective tasks (create user accounts, reset passwords, modify group membership, join computers to the domain, edit group policy objects, etc) without giving anyone full Domain Admin authority. Unfortunately few organizations do this because of the work involved in getting delegation right and because of understandable resistance from admins who want to be able to fix problems without depending on anyone else.

At the end of the day though, a sizable number of people in any IT department will have enough authority to really hurt the organization. Since there’s not really any preventive controls over privileged admins, our only recourse are detective and deterrent controls. That means that secure log management becomes the cornerstone of control and accountability over trusted but very powerful admins. We can’t control what an admin does but at least we can audit what he does. If you know your actions are being monitored you are going to be more careful and less prone to do bad things - that’s one of the reasons the USPS is dependable as it is; postal workers know they are being monitored. (Before you disagree try out the mail system of other countries.)

However, using audit trails to enforce accountability over admins means that log integrity becomes a real issue since admins can stop auditing or erase audit logs that remain on their system. Therefore you need a real log management solution that gets security events off the systems being monitored as frequently as possible to separate system to which normal operation admins have no access. If a Windows system that means the log management server would need to be outside the forest. And of course the log server admins can’t have admin authority to the systems being monitored - so it’s a separation of duty issue in addition to the architecture of the log management implementation.

But beyond classic log management, log normalization also provides special benefits specific to detecting and responding to rogue admins. Here’s an example:

Let’s say an admin - Bob - knows he is being let go. He begins changing the admin password on each system he has access to from Active Directory to Solaris and Linux servers to Cisco network devices. If your log management system normalizes log events from disparate systems your infosec staff can easily configure an alert rule that says alert me to any changes to the admin account (administrator on Windows, root on Unix, admin on Cisco, etc). With such a rule configured they will start getting the same alert (Admin password changed) from multiple systems in rapid succession.