Superuser Privilege Management: It's Not About Trust

Though "everyone knows" the threat and consequences of insider attacks, it was still shocking to read the headlines that a former Unix engineer at mortgage giant Fannie Mae was charged in federal court with allegedly planting a logic bomb that would have effectively shut down all 4,000 servers at Fannie. The FBI alleges that this logic bomb planted in a script would have "caused millions of dollars of damage and reduced if not shut down operations" for at least one week. And it was "only by chance" that another Unix engineer spotted the logic bomb a week after it was planted and prior to its detonation.

This incident reveals the imperative to implement what IT analysts refer to as "superuser privilege management." The "root" of this potential problem that can have such a catastrophic impact on the operations of an organization lies in the fact that most operating systems, applications and databases have an administrative account to enable installation, configuration and management of those platforms. These administrative accounts are used and shared by multiple personnel (e.g. systems administrators, database administrators, developers, etc.), resulting in the situation whereby multiple people in your organization have the privilege of carrying the proverbial "keys" (i.e. administrative access) to your "kingdom" (i.e. the systems and applications that power your business).

• Don't share privileged accounts. IT organizations need to break the bad habit of IT staff sharing the Unix root password (which the Fannie Mae Unix engineer had access to) and the passwords to other privileged accounts. People should log in with an account that clearly identifies who the user is. This provides more accountability and makes user actions easier to trace; it also means when an IT staffer is terminated, you don't have change the root password on 4,000 systems.
• Move to a single directory that spans multiple platforms. A single directory that can span multiple operating system platforms (e.g. Unix, Linux, Windows, Mac, etc.) and applications (e.g. SAP (NYSE: SAP), Oracle (Nasdaq: ORCL), Apache, etc.) provides the ability to immediately disable a given user's access across the enterprise (i.e. all Unix and Windows systems) from one place. For example, a popular and widely deployed directory such as Microsoft (Nasdaq: MSFT) Active Directory (which is focused on the Windows platform) combined with third-party "Active Directory bridge" products that tie-in non-Microsoft systems can provide a central identity store. In minutes you can immediately disable a user's accounts across the enterprise, while in the case of Fannie Mae it took over 10 hours to disable the Unix engineer's access. This centralization is essential because access to Unix systems is typically managed locally (i.e. the local /etc/passwd text file), and it may take many hours (if not days) to check and turn off a user's access to 4,000 systems.
• Implement access control and authorization management technologies to enforce the principle of "least privilege." Organizations need to limit which users with privileged access can authenticate to which particular systems or groups of systems. They should also ensure users run with as few privileges as possible. For example, the popular sudo utility on Unix can manage and enforce fine-grained control over user access and privileges on their systems.
• Implement user-level auditing and forensic tools on critical servers. Just as security cameras are deployed at banks and casinos, software auditing tools can be deployed on mission-critical systems to help IT organizations view who has been accessing what systems, what commands are being executed, and what changes are being made to key files and data. If a forensic tool to capture user-level activity had been deployed at Fannie, the Unix engineer's every keystroke and the actual text of the script he was editing would have been captured. The FBI would then be able to "playback" (like TiVo (Nasdaq: TIVO) or a VCR) in court the login session in which the Unix engineer created the logic bomb and implanted it in the maintenance script.

Fortunately, this incident at Fannie was prevented, and we hope it will serve as a wake-up call to organizations to make sure they are properly managing who has privileged access to their systems and applications. Given the keys that these personnel hold, a philosophy of "trust but verify" should be implemented that is backed up by a set of superuser privilege management procedures and technologies that enforce the essential protections required.