Part III: Authentication to Privileged Accounts
This week we bring you another informative and action-provoking Coffee Talk session. Last Wednesday’s topic was “Authentication to Privileged Accounts, Part III.” The session hosts were Vikram Subramanian, VP of Solutions at Simeio, and Chris Hills, Deputy CTO at BeyondTrust. Here are some session highlights.
As companies move to the cloud, what should they consider regarding privileged accounts?
This question came up in a discussion I had two weeks ago with the CISO at Starbucks. Many companies have a cloud-first approach. Now with COVID, everyone is re-aligning and readjusting where and how they’re spending their money. We have actually seen a pause in cloud-first approaches. Now that we are well into the pandemic, the perspective of a cloud-appropriate approach is on the rise.
There are three primary areas based around risk that drive organizations; risk acceptance, risk appetite, and risk tolerance. I think there is a shift in cloud perspectives, with more of a hybrid approach. There are many large organizations with mission-critical legacy systems and applications, and from a security perspective, there is no amount of money that will make sense in getting them to the cloud and achieving return on investment.
With this cloud-appropriate shift in focus, organizations are looking at what is going to make it easier for them, while maintaining security. And now, with so many working from home, they need to examine how to make it easier for workers to do their jobs, by securing applications in the cloud and on-prem.
I know some people say the cloud makes everything easier across the board. I don’t see that. There are technologies that enable endpoints and collaboration to allow people to have secure connectivity. But at the end of the day, you still have physical assets and applications that run on-prem. Let’s face it, organizations aren’t going to move hundreds of sequel databases and thousands of Oracle databases immediately to the cloud.
When we think about the specific practice areas related to PAM, how can we put those into the cloud, and make security better with two-factor, single sign-on, and Office 365? There are definitely PAM functions where it makes sense to quickly leverage them within the cloud, to enable remote workers. But other things may be too cost prohibitive. For example, there may not be enough developers, or enough time or budget to make them cloud-ready. You really need to prioritize your PAM structure as it relates to the cloud, based upon your specific organization’s needs and resources.
We need to stop thinking about PAM as just user accounts, or user access and password management. That’s a legacy approach. Ultimately, PAM maintains and manages all the secrets that you don’t want getting out. They could be in the cloud, or on-prem. It’s all about infrastructure, apps, API keys, SSH keys, and session management, and putting processes around them.
PAM can be broken down into three pillars. Password and session management is the first pillar, with APIs, SSH, root accounts, local Windows accounts, service accounts, applications, etc. The next pillar is endpoint privileged management, which is privileged escalation and removing excessive access rights away from users. The third pillar is secure remote access that enables the help desk support remote users, with privileged remote access that provides secure point-to-point connections. This provides user access and password management, in addition to keystroke and recording, for compliance validation.
Who within the organization should own PAM – IAM or cybersecurity?
There isn’t a single answer. You need to identify what you are managing. If you are managing all of the organization’s secrets, then the role, skillsets, and understanding of the IAM team needs to change. They need to understand that secrets go beyond accounts and access.
PAM often gets split between cybersecurity and IAM teams. This presents some challenges for the CISO responsible for reporting on risk, and how it gets reported. Evaluate your organizational structure, and identify what the IAM team can take on, and if you want them to take on all of the responsibility. If you can, all the better, because it will be within a single centralized location.
If not, get the reporting from the SIMM. This way the risk officer or security officer gets a single dashboard that covers all of the applications, systems, and people, with a consolidated view of the data. The other thing to evaluate is how the organization is moving forward. Do you have a lot of legacy systems, or is the organization more API and services-based? Does it have more cloud apps, and a huge IT shop that’s utilizing all the modern technologies? If so, then you probably have the skillsets to have infosec manage all of the organization’s secrets.
In order for PAM to be successful, someone needs to own it. You can’t have it assigned as a secondary task on top of another team’s responsibilities. Given the pandemic, I know companies are having to do even more with less, and people are taking on more responsibilities. But for the long-term, someone needs to own PAM. I’ve seen it get handed off to the Active Directory team, who says they are setting it up, and then handing it back to the IAM team. PAM holds the keys to the kingdom and controls all the access, and there is a lot of responsibility that goes with it.
Taking that a step further, consider what you’re doing with all of the analytical data that gets sent to the SOC. We rely upon the SOC to find the anomalies that might represent a breach. No matter where the PAM responsibility resides, whether within IAM or security, there needs to be a dedicated owner. Today’s enterprises are dynamic. Technologies are changing all the time. For PAM to be successful, it needs a single owner that is responsible for keeping it, and the application integrations and use cases, current.
How do microservices play within PAM?
If your organization is adopting a modern architecture with microservices, you need to understand how different microservices communicate with each other. You have API keys, and depending upon the security infrastructure the microservices are being layered on top of, you have different secrets that need to be maintained. Rather than storing those secrets within a database, or some other centralized store, think of PAM as another microservice. PAM is your check-in and check-out service; your credential providing service for interacting with other services. PAM is the central index for all of your APIs and admin activities. It’s like a certificate authority that maintains all of the organization’s credentials.
Earlier versions of PAM were not designed for high throughput transactions. However, today’s modern PAM platforms are adaptable for all of your high throughput transactions going through microservices. PAM really becomes a microservice. When we talk about segmentation and security, and making other microservices work, at the core it’s about vaulting the APIs and making sure they are available with a call at the time of need.
We’ve just touched upon some of the conversation. If you want to learn more, you can watch this, and other on-demand Coffee Talk sessions at https://www.brighttalk.com/channel/17142.
We hope you can join our next Coffee Talk where you can chat with IAM experts, ask questions and gain insights into how you can lower operational costs, and achieve greater security and privacy using IAM. Click here to sign-up.