Privileged Account Management (PAM) is Necessary, but Deploying it Stinks

As we looked into the topic of core defense in a recent series of blog posts and discussions, we concluded that privileged account management (PAM) technologies would be of great value in protecting the most sensitive IT assets from cyberattacks and breaches.

But then the rubber met the road. Security Architects Partners got called in to perform a PAM consulting engagement for a client. Our task: To validate a PAM deployment in dire straits. To discover: Is there a problem with the product? Is it a problem with the client’s approach? Are they on the right track? Will the vendor be able to meet their requirements?

We cannot name any names of any of the players concerned, but we can tell you that the process inspired the sentiments expressed in the title of this post: Deploying PAM stinks! (But you probably have to do it).

Why PAM?

Our client, many other enterprises and also cloud service providers (CSPs) are driven by security and compliance concerns to deploy PAM. On security, its clear enough that large enterprise end user populations and devices are routinely penetrated by attackers. You have to protect your core from genuine insider attack, from compromised insiders’ devices and from externally-orchestrated privilege escalation attacks.

On compliance, a number of regulations say its necessary to exercise special controls over privileged accounts. Sarbanes-Oxley, rules from the Monetary Authority of Singapore (MAS), PCI, CIP and various other authorities speak to least privilege and  separation of duty as well as audit and monitoring of privileged access. Of these, MAS is the most prescriptive. All this points to PAM.

PAM Basics

The market has responded over the years by providing multiple product categories to meet PAM requirements. A Gartner framework subdivides them into the following subcategories:

• Shared access password manager (SAPM)
• Superuser password manager (SUPM)
• Privileged session manager (PSM)
• Application access password manager (AAPM)

PAM password vaults, or SAPMs provide an extra layer of control over administrators and password policies, as well as detailed audit trails on privileged access. Enterprises can selectively require dual control (two people) to authorize an administrator’s session. Passwords can be changed after each use. Session brokers, or PSMs, take PAM further, ensuring that administrators never see the passwords; their hardened proxy servers (aka jump servers) also monitor active sessions, and enable reviewers to kill admin sessions if they see something wrong. Similarly, AAPMs can release credentials just-in-time for application-to-application communication, and even modify startup scripts to replace hard-coded passwords with API calls to the vault.

PAM Suites

PAM vendors are rapidly bundling the above mouthful of acronyms into integrated suites. The integration is a good idea, but no product is the best at everything. Healthy competition must be preserved so that customers still have viable best of breed options. That means documentation and integration tools – ideally open source – should be provided. Unfortunately, some of the larger vendors are, in our opinion, locking up the integration points excessively and making it too difficult for legitimate users, developers and evaluators to even get detailed documentation on their products.

Devils in PAMs Details

We’ve just scratched the surface of PAM basics; there’s a lot more to learn. The basics sound good in theory, but when customers get into a real deployment they’re likely to encounter some super-challenging issues:

• PAM may be resisted as an inconvenience by administrators, and it may disrupt other IT projects
• Password vaults can become single points of failure
• Load-balancing, performance and scalability concerns can dog PSM and AAPM solutions. Emergency access processes are needed should PSMs fail. AAPMs must have local caches. 
• Logging, and integration with enterprise SIEM systems should be a key part of PAM’s value, but marrying PAM to SIEM is not a trivial matter
• Integration with ticketing systems like Remedy – which provide the workflow for PAM and for a customer’s broader identity management provisioning environment – can require much more than just a simple API call if you need to implement robust separation of duty, access certification and related policies in ticketing processes
• Video session recording files from most PAM vendors providing the PSM function lack the metadata to enable timely reviews and alerts. Monitoring them may require many staff to do manual review in places like Singapore – and there are a LOT of sessions.

The fact of the matter is that not all the vendors – from the market leaders to the lean startups – are fully enterprise-ready.

Bottom Line

Customers planning to undertake PAM projects would do well to understand these issues and properly resource and prepare for their PAM projects. Security Architects Partners recommends:

• If you believe your end user IT environment may be vulnerable to malware (whose isn’t?) or insider threats, plan for PAM as a core preventative and monitoring technology
• Create a detailed functional architecture and design for deploying PAM and integrating it with your directory services, identity provisioning, ticketing, SIEM and other tools
• Define the scope of the initial project carefully – don’t bite off more than you can chew
• Break the project up into chunks that can actually be delivered and produce benefits along the way
• Don’t rely on a PAM software vendor to do too much custom integration with your internal systems. Use a carefully vetted system integrator to do the hard work, but keep control of your architecture and maintain internal subject matter expertise.
• Run communication and training programs to maintain buy-in from business stakeholders and administrators
• Allocate plenty of time for testing

Our current PAM customer is benefiting from those of these recommendations that apply to the circumstances in which we found them. So should you.