How do you assess Risk within Privilege Account Management?

How do you assess Risk within Privilege Account Management? That’s been a very interesting conversation we’ve had with many customers lately. When you first talk about the topic and use made-up words like ‘Risk Score’, there’s a lot of confusion and even some push back. Security admins don’t want to assign an end-user a risk score for obvious reasons. It certainly seems subjective/judgmental for one. And assigning a risk level for each user and keeping it up-to-date would be a monumental task. However, when you continue the conversation and dig deeper, what ends up being described is the idea of risk level. Risk level really describes a way to be more efficient in processing a lot of information to make an informed decision. For example when you setup a workflow around who can get access to a shared administrative password…at some point in the workflow process someone has to make a decision that involves knowing what password is being requested, and who is requesting it. Is this for the root account on one of the PCI systems? Or is it for a shared application account on an internal test system? This is often tribal knowledge that has the same problems as all tribal knowledge, there is a learning curve and things change. So what about the idea of including some relevant ‘risk level’ information in the request? If the approver could see that the access being requested was for a ‘high risk’ system could that make it easier for them to make an efficient, informed decision before approving the request?


It’s not just the workflow and approval process – it can also manifest when looking at event logs and privileged event activity. If an auditor has hundreds of hours of recorded sessions, what should the priority be and where should the focus be? In designing a way to catalogue the session as high risk vs. low risk it could ease the process of prioritization. In our discussions we’ve learned it’s difficult for someone to weigh if granting access to a shared admin account on one system is more or less risky than granting access to run a command on another system. And if you are going to go thru the effort internally as a business to understand the difference, then doesn’t it make sense to provide a way to store and use this learned information to make better decisions? Ultimately you are not assigning a risk score to a user, but you are assigning some type of risk level to the resource that may be requested.


It’s been interesting understanding how companies make policies around privileged access management, and where the discussion of risk level enters. Feel free to share with us your thoughts on this.