Often, the most powerful entities in any organization are found in the form of privileged accounts and identities, since they provide the widest and deepest access to systems and their underlying data. These accounts enable the most influential IT users in an organization to accomplish their tasks with the required elevated permissions, access rights and administrative capabilities. Often these accounts are the least managed, monitored or controlled. They provide anonymous or untracked access, since these are shared, generic accounts that are not typically associated with an individual user.
Traditionally, organizations managed these privileged accounts by “trusting” the administrators and personnel with access to only use them “as needed” and not abuse them. Unfortunately, as we find out time and time again, trust is not a security policy. We've seen several recent examples of how pervasive and powerful these privileged accounts are – and what the consequences can be if they go unchecked. Consider these examples:
- An IT contractor was recently indicted for illegally accessing a privileged account, compromising a computer system used by Pacific Energy Resources to monitor offshore oil platforms in California and Alaska. The contractor crashed the system, and while thankfully there was no environmental disaster as a result, this company is reporting his actions caused thousands of dollars of damage;
- Yusuf Acar, Washington D.C.'s CSO, is still in jail on charges of the bribery scheme he was running out of his office. One of the biggest challenges facing authorities is understanding how pervasive his access was to systems and information in the IT infrastructure – Acar had set up backdoors throughout the organization through his privileged accounts;
- In one of the most infamous cases of privileged abuse, IT worker Terry Childs was charged with bringing San Francisco to a grinding halt last year by using his privileged admin account to lock down the San Francisco IT system;
- Fannie Mae narrowly avoided a devastating attack after a former employee used his privileged access to implant a logic bomb on the company's network that could have brought the network down entirely.
- Include privileged identities within the broader security/Identity Management project scope. This is a critical first step, because if privileged access isn't included in the initial scope, it won't get addressed. Identity management projects need to focus on more than controlling end-user access in your organization. Given the power of these privileged accounts, this needs to be included in any IdM discussion, and should be a focal point from the onset of the project.
- Identify the key systems, applications and databases and the underlying privileged accounts that exist in each one. Often overlooked is that fact that each application in your organization has underlying generic identities, which, once access through a privileged account, gives wide ranging access to any other application in the organization it touches
- Identify who should have access to privileged accounts – make sure you understand who exactly you're giving this power to.
- Identify who does have access to privileged accounts – as you audit these accounts, you'll be shocked to find out how many users have access that they shouldn't.
- Clearly define policies for privileged access to key systems, ensuring safeguards such as dual-control, time-based access and frequent strong password changes.
- Implement processes to automatically apply the policy definitions. As cited above, the Consensus Audit Guidelines suggest that these processes be managed automatically and continuously.
- Monitor and report actual adherence to the defined policies you set forth. This is a critical component in safeguarding your organization, making sure you not only know who is accessing these accounts, but monitoring the activity once the access is granted to make sure the activity itself is in compliance with your security and business policies.