Privileged Identity Management (PIM) and Privileged Access Management (PAM) are two terms that have broad IT security implications, and security pros such as CISOs know them well. PIM and PAM also have more specific applications and definitions in the Microsoft world, especially concerning Office 365 (or Microsoft 365 in newer parlance) and the world of Azure and Active Directory.
First, we will let Microsoft explain what PIM means. “Azure Active Directory (Azure AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in your organization. These resources include resources in Azure AD, Azure, and other Microsoft Online Services like Office 365 or Microsoft Intune,” Microsoft explained.
So what’s the point? “Organizations want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious actor getting that access, or an authorized user inadvertently impacting a sensitive resource. However, users still need to carry out privileged operations in Azure AD, Azure, Office 365, or SaaS apps. Organizations can give users just-in-time (JIT) privileged access to Azure resources and Azure AD. There is a need for oversight for what those users are doing with their administrator privileges,” Microsoft said. “Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management:
Now that we have PIM out of the way, let us see how Microsoft defines PAM. “Privileged access management allows granular access control over privileged admin tasks in Office 365. It can help protect your organization from breaches that use existing privileged admin accounts with standing access to sensitive data or access to critical configuration settings,” Microsoft argued. “Privileged access management requires users to request just-in-time access to complete elevated and privileged tasks through a highly scoped and time-bounded approval workflow. This configuration gives users just-enough-access to perform the task at hand, without risking exposure of sensitive data or critical configuration settings. Enabling privileged access management in Microsoft 365 allows your organization to operate with zero standing privileges and provide a layer of defense against standing administrative access vulnerabilities.”
Many IT pros feel that if they have Privileged Identity Management and Privileged Access Management, they are all set. However, neither one of those, either by themselves or together, are the answers to ultimately get you where you need to go – which is Least Privilege Access.
The dire consequences of not having Least Privilege Access are breaches and theft of intellectual property – and all manner of invasion and infestation.
CoreView does not do PAM and PIM per se. Instead, CoreView augments them to help IT on their security and identity journey – towards Least Privilege Access.
Matt Smith is a Microsoft veteran, and for the last several years, a CoreView Solutions Architect. That makes Smith an expert in Microsoft and CoreView’s approach to Office 365 security, and in particular, how administrator rights are granted and managed.
We spoke with Smith about PIM and PAM, and how to augment both with a deeper approach to achieve deep and safe Least Privilege Access.
CoreView: We walked through Microsoft’s definition of Privileged Identity Management (PIM) and Privileged Access Management (PAM). What do these approaches mean to you?
Smith: Privileged Identity Management and Privileged Access Management are two methodologies to achieve the real goal for every IT security person — Least Privilege Access. Least Privilege Access is well established in IT security, and means you have just enough rights to do the job that you need to do. No more, no less.
CoreView: Can you diver deeper into Privileged Identity Management (PIM)?
Smith: Privileged Identity Management is basically a workflow, and a Band-Aid in my mind, to grant people access to roles for a period of time so that they have an elevated permission and then take it away from them.
The real problem in the Microsoft world is those roles that they grant access to are way, way too broad. Role-Based Access is really a 1970s term, and from Microsoft technology perspective is a 2010 type approach.
We no longer play the role in administration anymore – such as being the Exchange person or the SharePoint admin, where all we do all day long is create mailboxes and add people to distribution lists. We actually perform functions across the entire cloud stack, which is quite complex. This can include adding a user, setting the password, and granting them a license. You can add them to a mailbox, to distribution lists, or Microsoft Teams channels. You can also pre-initialize their OneDrive, set policies for devices, and so on.
We no longer work in this concept of roles. Microsoft’s response to enhancing their role-based model is to add more roles.
Let us talk about the Microsoft role-based model. The first one, Application Administrator, gives you access to literally 75 different attributes. Nobody in Microsoft knows what all those attributes do. Certainly not IT. If I grant you access to the role of Application Administrator, I cannot look the CISO in the eye and tell them, “I know exactly what I gave him access to” because I do not know the underlying foundations for it.
There are unintended results. Leveraging Privileged Identity Management to temporarily grant access to a role that is not understood and well defined is just a Band-Aid towards achieving Least Privilege Access.
Least Privilege is not well implemented in the Microsoft world. CoreView does a much better job at this because our Role-Based Access Model is actually functionally based. It is based on check marks where you check off the functions you want to grant rather than broad roles.
CoreView’s permissions model is what I like to call Functional Access Control or FAC versus Role-Based Access Control or RBAC, which we also provide. FAC is simply more granular and fits today’s IT workstyle better.
CoreView’s FAC is check box-based. IT can give someone the ability to forward email addresses by clicking two boxes. It is automatically scoped, which is hard to do in the Microsoft world without creating a custom role and creating a custom scope – and frankly, nobody does that.
I can also give somebody at the help desk the ability to forward email for people who are on long-term leave in the accounting department. Boom. We are done.
One use case is for a desktop deployment person putting software on PCs that may have been locked on Friday at 5:00 PM. They need the ability to unlock the PC to reset the password, install the OneDrive agent and make sure that it is working. In that case, that person could request that ability to change the password and set the OneDrive settings.
CoreView: Can we turn to Privileged Access Management (PAM)?
Smith: Privileged Access Management, in the Microsoft view, provides access based on your role from certain locations, and gives you a certain permission level.
What this really should look like is this picture here.
This is the journey that a user takes in the upper left to data asset in the lower right, and the gates that they have to pass through in order to get to that asset. This is Privileged Access Management. First, I am going to set conditional access policies or CASB roles at the edge that define items such as “I’m not going to allow you to log in from Kuala Lumpur because you have no business reason for being in Kuala Lumpur.”
I can red flag areas where I should not have sign in attempts, require that you have multifactor authentication, or allow hourly workers to log in outside of standard working hours so that they can claim overtime — things like that.
The next gateway we have to get through, assuming that your location is not an unacceptable location, is multi-factor authentication.
CoreView plays in all of these areas too. We also have effectiveness reports that tell you whether MFA is working or not. We can tell whether multifactor authentication has been applied and implemented, and whether or not it came into play during a particular sign in event. The username and password is the next barrier. Here, CoreView has controls around password complexity and how many failed log in attempts you get before we lock your account.
CoreView monitors your password complexity. It tells if an account has been locked. We have workflow and alerting around that aspect, and can take a workflow action if you lock your account – we can notify people, wipe user sessions, and so forth. Once a user is authenticated, our Least Privilege Access or Functional Access Control comes into play. Meanwhile, what we call virtual tenants is really permission scoping – and defines which users I can apply elevated privileges to.
Another aspect of privileged access are the security groups users belong to. Finally, is authorization which comes in the form of a token that is based on all these things, granting the ability to access, say, a Word document in Office 365.
That is the security journey towards the applying of Least Privilege Access and the gates that we take to get to that data asset with the appropriate permissions and privileges.
Within a specific CoreView report, you will see during a sign-in attempt and whether or not multi-factor authentication came into play. Or it may not have come into play just because we blocked them through conditional access.
IT is responsible for our accounts and our identities. How are they configured? Do they have multi-factor authentication? Did we give them the appropriate roles? IT is also responsible for our devices. Are those devices at the appropriate and acceptable patch level? Have we applied mobile device management policies? There are information and data access controls, including roles IT deploys to those users as the security groups they are provisioned to.
With CoreView, all this falls under our responsibility. We also have responsibility for certain network controls. That is our conditional access policies for the application configurations themselves. Did we allow external sharing for SharePoint, for example? If we did, can we audit all that external sharing? We do these things that Microsoft does not do because Microsoft has delegated that responsibility to us. In other words, if you do not have CoreView or CoreView-like controls, you are missing your secure identity responsibility. The native Microsoft Admin Center does not take care of these items for you.
CoreView: It sounds like PAM and PIM, while helpful, do not do nearly enough to achieve true least privilege access. How is Functional Access Control part of doing least privilege right?
Smith: In Microsoft’s Zero Trust model, the feature functionality that Microsoft and others are pushing are PIM and PAM, which are approaches to Least Privilege Access. What does the CISO care about? He cares about true Least Privilege Access. If you asked 100 IT personnel, ‘Should we have Least Privilege Access for all of our applications?’ 100 of them would reply, ‘Yes we should!’ The next question is — why don’t you? ‘Microsoft doesn’t give us the tools that allows us to do that.’ And they are right. You cannot do it natively within the O365 Admin Center.
The only right way really to apply Least Privilege Access is to extrapolate administrative access and proxy it the way that we do through a portal that says, ‘I am not giving you access to a role. I am giving you access to a function, and you have no privileges whatsoever within the application itself to do other things.’ It is a predefined function that CoreView admins have the ability to turn on and turn off, or even apply a workflow to give time bound access. That is the only way to get to that goal.
CoreView: How does CoreView help batten down the O365 security hatches on a daily basis?
Smith: Imagine an organization of 10,000 people. Hackers do not get in on the first attempt. Meanwhile, IT is getting how many sign-in events, every single day, across days, weeks, months, and years? There are too many signals there. CoreView sorts through all those signals. We correlate the data, we enrich the data, and then we surface it into an easy to read dashboard and set of reports.
CoreView:What are the consequences of not doing Least Privilege right? Why should a CISO care?
Smith: Security people know that they are going to be hacked, and they know what the consequences are, and the costs. What is top of mind for CISOs is, first, did I meet the minimum bar of my peers? Did I at least have controls in place that are part of my fiduciary duty?
Am I at parity with IT in general, and most importantly, within my vertical? If I am in healthcare, I have to at least meet the healthcare vertical’s minimum standards. In financial services, those standards are somewhat different from a compliance and a regulatory standpoint. I must have at least deployed best practices across my entire organization.
CISOs do not know what they do not know, even more so if they have not implemented the standard core security principles of auditing, logging, reviewing issues, tightening down security, device configuration management, account information management, and so forth.
CoreView: With regard to this benchmarking, what is one metric that security and IT people should care about?
Smith: Microsoft put together Secure Score precisely for that. FINRA, Financial Services Regulation, has a spreadsheet of security controls that they recommend every regulated financial organization follow. The federal government has its NIST standards.
