How to Avoid Privilege-Related Blind Spots
This week we bring you another informative Coffee Talk session. Last Wednesday’s topic was “Avoiding Privilege-Related Blind Spots.” The session hosts were James Quick, Director of Solutions and Advisory at Simeio, and Brian Chappell, Director of Product Management at Beyond Trust. Here are some session highlights.
Why should organizations be concerned about privileged accounts?
I would counter with, why shouldn’t organizations be concerned about privileged accounts? Privileged accounts are the first thing hackers look for when they land on your systems, and then move laterally across your organization. More than half of organizations struggle with managing privileged accounts. These accounts are where domain administrators manage servers, and start and stop services on Windows and Unix servers. Control of servers, devices, and databases, are all privileged account areas. So yes, organizations must have control over their privileged accounts, because they are the control path over your digital environment.
What are the obstacles around privileged accounts?
The first obstacle is privileged passwords, and knowing where they are, because there are so many now. Twenty years ago, everything was self-contained within the corporate office. It was easy to know who the network admins were, and to know they were trusted. We’ve expanded into distributed offices, work from anywhere environments, and support a broad supply chain. Now it’s hard to know where all the privileged accounts are, let alone the who, what and how behind their use. Discovery is the first thing that needs to be accomplished. You must find where those credentials are, and get a view into which ones are most important to get under management.
Traditional privileged accounts, like Windows admin or Unix root, are just the tip of the iceberg. Discovery is great, but it can’t be a static process. As new accounts, servers, and new types of devices are being onboarded, it has to be a continuous and dynamic process. Also consider the fact that APIs, clouds, and IoT devices are privileged, and robotic process automation accounts may be privileged. The entire privileged account surface has expanded from what we understood ten years ago. A primary obstacle is the fact that we are too limited in the way we define privileged accounts.
What are the primary drivers for sourcing a privileged account management solution?
Look at the traditional business drivers that are important for justifying any IT budget or project. The first driver is reducing your risk surface. The second is increasing compliance, because you need to track these accounts better. The third is cost avoidance. You don’t want to find yourself subject to a law suit, or compliance violation, because of a lack of foresight in managing privileged accounts. The last driver, and perhaps the one that matters the most, is finding products that enhance the user experience. You have to convince people that they’re not giving up their privileges, but their privileges are being enhanced.
Before I joined BeyondTrust, I was a contractor for a multinational pharmaceutical company for eleven years. I had seven privileged accounts. Then I left the company for fifteen months, and when I came back, six of those accounts were still active. They all had processes behind them, and I had responsibility for those credentials. In fact, I had to take many computer-based training courses on the risks of having the accounts, and the responsibility of holding them. The training and testing took a significant amount of my work time and energy. There are many admins that have tens, and even hundreds of privileged credentials. They are responsible for using them correctly, and protecting them. However, when you have a good PAM solution in place, it lifts that responsibility off of their shoulders. PAM doesn’t make them lose privilege; it actually reduces the stress in their day-to-day operations. That’s something I wish I had as a contractor.
Is there a framework that organizations can follow to avoid blind spots for secure access?
It goes back to discovery. I think of this in terms of a triangle. One side is what we’ve discovered, another is where people have raised tickets in the system to request privileged access, and the third is local knowledge, like the IT team’s knowledge of who has access. When you combine those three together, you have a really solid decision point, where you can clearly know what needs to be managed. Again, this is an ongoing process that also requires low-friction for users.
An overall consideration to the three principals mentioned here, is adding the concept of least privileged. This is a great idea if you are instituting controls on a system, because you are providing people with just enough privilege for them to do their jobs. On the other hand, it’s a scary concept, for someone that is used to a traditional, and unobstructed privileged account.
It’s a matter of balancing least privilege with most productive. How can we help users to be the most productive? Let’s go back to Brian’s example as a contractor with six privileged accounts. First of all, users shouldn’t have six accounts; they should only have one. Secondly, a privileged account shouldn’t just be sitting there. They are threat surfaces that shouldn’t be exposed.
One innovative area within BeyondTrust is just-in-time privileging. Creating a privileged account only when it’s required to perform a specific task. The user seamlessly logs into the account that allows them to do their job efficiently and safely. When they are finished and log out, the account is abolished. There is no privileged account, nor remnant to attack, because it only exists during the time required to complete a specific task.
The objective needs to be just-in-time privilege account management, combined with least privilege for a Zero Trust environment. This creates an environment where people are only enabled to do what they are explicitly allowed. With this solution, they simply can’t use it invalidly, because it is completely under the control of IT. This creates a system with fewer events, or noise. If something bad happens, and alarms go off, it becomes easier to see. This layered approach to cybersecurity is really a case where the whole is greater than the sum of its parts.
This takes the traditional IT notion of Defense in Depth, and applies it to privilege. When we think of privileged accounts, we must also include protection of devices, servers, processes, and even specific applications and functions. You must be able to defend at each of those levels, with processes in place.
What does success look like after your customers have implemented a PAM solution?
Success equates to getting the bulk of your accounts under control, with processes that continuously adapt, so they can’t be brut-forced. Success means you’ve defined your key performance indicators, and demonstrated that you’ve met them, by showing how you avoided litigation from non-compliance, and reduced risk. Success is demonstrating how you’ve improved the user experience, and achieved all the things you promised to do when you implemented privileged access.
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.