In a previous blog post I sounded the alarm about the insider threat. Someone in your IT organization must have the root passwords, the argument goes, so what’s to keep your own Edward Snowden from absconding with your data or worse, sabotaging your company? The frightening answer to this question is that we simply don’t have a foolproof method for mitigating the insider threat.

To address this problem within their own ranks, the NSA has instituted a two-person rule (the politically correct moniker for the two-man rule). This rule requires two people to be present for the transfer of sensitive information, and applies to admins with root privileges. If the two-person rule for launching nuclear weapons comes to mind, you’ve got the right idea.

If the two-person rule is the best the NSA can come up with, then maybe you should institute it in your own IT shop, right? Maybe. But don’t count on this simple technique to mitigate the insider risk by that much of a margin. Here’s why:

• You’ll need to separate those instances where the two-person rule applies from all those situations where it doesn’t. If you set this dial too far one way, then you allow a wide range of insider attacks. But set it too far the other direction, and you’ve just put a huge roadblock in front of your people, interfering with their day-to-day work.
• Remember that sysadmins are a chummy bunch. Sure, Snowden may have been working alone, but all it takes is a conspiracy of two people to defeat the two-person rule entirely.
• The logistics of the two-person rule are problematic. Today’s systems aren’t designed to enforce a two-person root login process. As a result, someone has to have the root password. Now you have a new rule that says he or she has to have someone there when they log into a system with this password, but how do you ensure they don’t use it surreptitiously?
• Even if you were able to reconfigure your server kernels so that the only way to get root access was for two people to log in with two separate passwords, you’ve still only addressed the root password vulnerability. Keep in mind, however, that access to sensitive data in your organization may not require a root password. Instead, you have various identity management and entitlement management systems controlling access to data and various APIs, and each of those systems has their own admins with their own admin passwords. So now you have to reconfigure the inner security workings of all those systems?

Good luck with that.