When you hire an employee, especially one with a sensitive role like a system administrator, what kind of background checks do you perform? Typical organizations will check candidates’ criminal records and perhaps their credit scores, on top of a series of interviews with various people within the organization.
What if that person is responsible for keeping government secrets critical to the security of their country? Time for a more in-depth check. To obtain a Top Secret clearance with the US Government, for example, investigators interview neighbors, former colleagues, and family members. They pore over bank records and credit card statements, looking for anything fishy as well as any reason to believe the candidate would be susceptible to blackmail. And the interview process is far more rigorous and detailed than your typical job interview process.
And yet, as the Edward Snowden NSA PRISM debacle showed, such clearance checks are far from foolproof. An intelligent, shrewd malefactor may still be able to pass all the checks, fly through all the interviews.
And while we may presume Snowden had nefarious intent when he applied for his job at government contractor Booz Allen Hamilton, there may be far more individuals who were trustworthy at the time of hire, but through some subsequent disaffection or alienation, feel they must turn upon their employers.
Either way, organizations essentially have no protections against such insider threats. Someone must have root access. Someone must be able to reboot servers. Someone must administer the identity management system. Someone must be in charge of the passwords and digital certificates. And nobody is 100% trustworthy.
Compartmentalization helps mitigate the possible damage, to be sure. Even people with Top Secret clearances can only access top secret information on a “need to know” basis. But ask yourself: what did Edward Snowden or Bradley Manning need to know? Compartmentalization is ineffective, and because it essentially prevents collaboration across an organization, it’s almost always counterproductive.
Ask yourself: what if someone in your organization with root access suddenly turned on you, and did as much damage as they could. Could they erase systems of record? Destroy all backups? Delete Cloud accounts?
su root, cd /, rm –rf *, people. It’s as easy as that.