How to Restart a Stalled PAM Security Program

TL;DR

Privileged access management works only when organizations actively apply its tools and processes to identities that create meaningful risk. A strong PAM program manages privileged identities, monitors credential use, links shared-account activity to unique users when possible, and supplements automation with procedural controls when tools cannot cover a business need.

Transcript

Uh, thank you so much for coming. Uh, a-and I, I do, you know... I, I've, I've thanked several people at RSA for the opportunity to, to share this journey, uh, and it has been one, uh, about, uh, privileged access management obviously. And a little bit about me, uh, you know, there, there's obviously an intro in the, in the, the pocket g-- well, no... Read More

Key Insights

• Privileged access is broader than administrator or root authority. It can include special permissions inside an application, broad access to an underlying business system, or any identity whose capabilities create significant risk for the organization.
• Account risk is a practical way to identify privileged identities. A backup account may lack a conventional administrator label while still enabling access to highly sensitive information, so PAM scope should reflect potential business impact rather than account names alone.
• PAM is a program, not merely a deployed tool. Its effectiveness depends on how consistently people use available controls, just as a gate lock provides little protection when it is not fully secured or properly checked.
• Effective privileged identity management includes controlling identities, monitoring credential use, and tracing activity to unique users whenever possible. These measures establish who used a privileged account, when the access occurred, and whether anyone else could have acted through the same credential.
• Shared accounts require individual accountability. Ideally, one person checks out a shared credential and becomes its sole authorized user for a defined period, allowing the organization to connect actions on a system to a specific person and challenge claims that anyone could have used the account.
• Procedural controls can reduce risk when PAM automation does not support a business pattern. Merck addressed shared Facebook access through a process that enabled rapid revocation when an employee departed, even though the available tooling could do little beyond vaulting the credential.
• Identity is an important security control beyond the traditional network perimeter. As organizational data moves outside boundaries protected by firewalls, intrusion prevention systems, and intrusion detection systems, authorization tied to identity can govern permitted actions regardless of a user's location.
• The South Carolina taxpayer breach shows why unconventional privileged accounts matter. Attackers used a backup account rather than a root account, and the absence of encryption for data at rest allowed them to exfiltrate the database and expose taxpayer and business identity information.

Questions & Answers

Q: What is privileged access management?

Privileged access management is the coordinated management of identities and accounts that can exercise sensitive or unusually broad authority. Its scope includes administrator and root accounts, special permissions within applications, and other identities that pose substantial organizational risk. An effective program manages these identities, monitors password use, and connects privileged activity to a unique person whenever the access pattern permits it.

Q: How can an organization identify privileged accounts?

An organization can identify privileged accounts by examining what each identity can reach or change and the risk created by that access. Administrator and root accounts are clear examples, but they are not the entire population. Special application permissions, shared social media credentials, and backup accounts can also be privileged when they provide broad access or could cause serious harm if compromised.

Q: Why should PAM be treated as a program instead of a tool?

PAM should be treated as a program because security technology provides value only when people apply it through reliable practices. Deploying or purchasing a tool does not ensure that accounts are discovered, placed under management, monitored, or removed promptly. The gate story illustrates the principle: a control may exist, but incomplete use of that control can still leave the protected boundary open.

Q: How should shared privileged accounts be managed?

Shared privileged accounts should be controlled so that their use can be attributed to a specific person. Ideally, a user checks out the credential and is the only authorized holder during that period. This creates evidence that a named individual accessed a particular system at a particular time and prevents the account's shared status from eliminating accountability for actions performed through it.

Q: What can teams do when PAM automation cannot manage an account?

Teams can implement a documented procedural control when PAM automation does not support a particular account pattern. Merck used this approach for a Facebook account shared by five social media employees. Although the credential could be vaulted, the tooling did not provide a complete pattern. A defined process allowed the team to revoke a departing employee's access quickly while automation remained unavailable.

Q: Why is identity considered a new security perimeter?

Identity is considered a new security perimeter because organizational information increasingly exists or moves beyond boundaries protected by firewalls, intrusion prevention systems, and intrusion detection systems. Those perimeter protections still matter, but they cannot provide the entire defense. Identity controls determine what a person or account is authorized to do regardless of location, helping protect the data behind that identity.

Q: Why can a backup account be a privileged identity?

A backup account can be privileged because its effective access may be broad enough to expose an entire database, even when it is not called an administrator or root account. In the South Carolina breach described in the talk, an attacker used a backup account to exfiltrate taxpayer data. The example shows that privilege must be evaluated through capability and risk, not naming conventions.

Q: What lessons does the South Carolina breach provide for PAM?

The South Carolina breach demonstrates that PAM programs must include powerful accounts outside the conventional administrator and root categories. The compromised identity was a backup account, and it enabled the attacker to exfiltrate the taxpayer database. Because the data was not encrypted at rest, information concerning individual taxpayers and businesses was exposed, compounding the consequences of the account compromise.

Summary & Key Takeaways

• Privileged access includes traditional administrator and root permissions, special application permissions, and any account that creates substantial organizational risk. A PAM program should therefore classify identities by their actual access and potential impact instead of limiting its scope to accounts carrying familiar technical labels such as administrator or root.

• Effective PAM combines technology with disciplined operating processes. Privileged identities should be managed, credential use should be monitored, and activity should ideally be attributable to a unique person. When tooling cannot support a particular access pattern, procedural controls can still provide a practical way to revoke access and reduce exposure.

• Identity has become an important security perimeter because organizational data increasingly moves beyond boundaries protected by firewalls and other perimeter controls. The South Carolina breach illustrates the consequences of overlooking unconventional privileged identities: a backup account enabled database exfiltration because its access was powerful and the underlying data was not encrypted at rest.