Watching the Watchers

Even if your Latin skills are weak, you might recognize a few well-known phrases such as ipso facto and quod erat demonstrandum (Q.E.D.). Another key phrase you might know is quis custodiet ipsos custodes? It means something close to "who watches the watchers?" That's a question that might be on your mind even if you don't recognize it in the original Latin. Who watches your watchers? Who monitors the activities of your users and administrators, and who watches the ones doing the monitoring?

I thought about this recently when I read a Wall Street Journal article about Bruce Gabbard, a former security engineer for Wal-Mart ("Wal-Mart's Firing Of a Security Aide Bites the Firm Back," April 9, 2007). Gabbard was responsible for counter-surveillance and had nearly unlimited access to some of Wal-Mart's most sensitive data, and now Wal-Mart is suing him because the company thinks he's misappropriated some of that information. The suit raises some interesting questions about whether Wal-Mart knew the full extent of Gabbard's access. The matter will undoubtedly work its way through the courts with a lot of sound and fury; no matter how it's resolved, the case gives cause for thinking about similar issues in your own organization.

Administrators, of course, have a broad array of privileges. However, Exchange Server administrators don't have to have administrator privileges to Windows and Active Directory (AD), and vice versa. Specific Exchange tasks, such as installing service packs or adding or removing Exchange servers, do require Windows administrative privileges. In addition, user management tasks, such as adding or removing user accounts or distribution groups, require AD permissions.

Exchange and Windows allow delegation of administration so that you can delegate access rights for specific operations to only the groups that should have them. Here's a security tip: Don't assign delegated permissions to individual users. Instead, assign them to groups and put users in the groups. This method reduces the risk that you'll end up with orphaned permissions on an object or that you'll forget to remove an account when the user no longer needs access.

One of the most common questions related to administrator access is how you can tell if administrators are reading other people's mail when they shouldn't be. This is a tough nut to crack because if you look at the event log you'll see that Exchange logs an event ID 1016 whenever one user attempts to access another user's mailbox. Sounds good—except that the event is logged for legitimate access, too, not just failed attempts. You can check the mailbox databases and mailboxes to see whether administrators have Send As and Receive As privileges on mailboxes they don't own, but that's not a complete solution either; administrators can always grant the permission, read the mail, then remove the permission—making it much more difficult to catch.

I once taught a security workshop for Microsoft field engineers. We had a lively discussion about what the ultimate defense is against an untrustworthy administrator. We discussed various security measures, but for everything I proposed, the engineers came up with a clever workaround. Finally I described the ultimate security measure: Get the sheriff to arrest the evildoer after you catch him. But this method sounds fairly unsatisfying. After all, you like to think of security measures as proactive steps that will either block attackers from succeeding or help you catch them in the act. However, it's a time-tested rule of computer security that administrators can do anything they want; having that level of access is what makes an administrator.

The bottom line: Hire trustworthy administrators, and if you have reason to think that someone is no longer trustworthy, consider removing that person's administrator access.