Verizon’s 2019 Data Investigations Report (DBIR) found that 34% of all breaches are caused by insiders, while another study showed that more than 70% of attacks aren’t reported externally. The worst breaches, however, are the ones that crack administrator accounts and take advantage of the high level of privileges IT professionals enjoy.
The ability to separate all the different functions and feature sets is critical to maintaining a security and governance in Microsoft 365 environment, including protecting remote employees from leaking data inadvertently.
The first step to defending against both privileged credential hijacking and insider threats is using role-based access control (RBAC). RBAC enables companies to grant privileges that are absolutely needed, and only for a specific time. However, not all RBAC is created equal and it’s imperative to take security to the next level with functional access control (FAC).
Let's look at FAC and RBAC, the difference between them, and how FAC is a far better fit for today’s IT environment. We’ll start by providing some context in FAC and RBAC’s role and function within enterprise cybersecurity.
Role Versus Function
The distinction between a role and a function is important. Functions are granular security tasks while roles are combinations of various functions that relate to a role. In fact, roles such as Exchange or Active Directory (AD) are becoming rarer than functional administrator assignments for many Microsoft 365 customers who can grant and control these functional rights.
Least Privilege
Before we dive more deeply into the differences between RBAC and FAC, it’s critical to understand least privilege. Least privilege is the concept and practice that every user in the system must be able to access only the information and resources that are necessary for its legitimate purpose. CISA states:
The main purpose of least privilege is to limit the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur.
For a digital workplace where everyone is online working remotely, least privilege is essential to ensuring your confidential enterprise data is protected.
More Roles is Not the Solution
Today’s IT professionals are no longer focused on "roles" in administration anymore—e.g., the Exchange person who spends the day creating mailboxes and adding people to distribution lists. As of April 2020, Microsoft reported 258 million Microsoft 365 (M365) users and 75 million Teams users. However, most M365 IT professionals continue to work in the concept of roles because that is the only way the native Admin Center can define administrator privileges. In reality, M365 and other IT administrators perform functions across the entire cloud stack, which can quickly become complex, especially when limited by the role-based model.
A functional approach to administrator privileges might involve adding a user, setting the password, and granting them a license. Next, another administrator may add them to a mailbox, to distribution lists, or Teams channel(s), pre-initialize their OneDrive, set policies for devices, and so on. All of these are functions, not roles.
As a response to IT administrators’ shift away from using roles, Microsoft enhanced their role-based model by adding more roles. This created a bigger problem because the sheer volume of roles makes it impossible to know exactly what each is and isn’t allowed to do. For example, many businesses use the application administrator role for their employees but don’t understand the 75 different attributes the role grants them. This type of blind spot opens the organization up to unnecessary risk.
How can an organization operate as a multi-tenant environment while, from Microsoft’s perspective, on a single tenant? It’s simply not possible. IT administrators need a way to divide what every role in their organizations needs access to in order to do their job.
While FAC is the holy grail of Least Privilege Access, RBAC is a good place to start. In fact, too few M365 shops take this worthy first step. And when they do move to RBAC, find this approach limiting. The problem is the native administrator delegation tool in M365 is simply too blunt, lacking the granularity and actionable insights enterprises need. IT pros who thought their lives would be easier with a cloud suite find themselves mired in endless administrations tasks, trying fruitlessly to give administrators and users the exact level of visibility they need. The IT team becomes frustrated and often relinquishes control by simply assigning all administrators the same broad global permissions. Too many people with too much permission opens gaping holes in the network.
The Difference Between RBAC and FAC
RBAC is based on the least privilege cybersecurity concept. It is a permissions scheme that is based on granting IT administrators the ability to perform specific actions while denying them the ability to perform other actions. In contrast, NTFS permissions is the more traditional permissions scheme used by Windows that allows or denies access to files and folders. RBAC schemes are more flexible than NTFS permissions, and allow for many distinct levels of administrative permissions, especially with the wide-array of Microsoft 365 applications, which includes Exchange, SharePoint and OneDrive, among others.
RBAC is role-based and assigns permissions based on role, whereas FAC is attribute-based, and grants access based on attributes that change in real-time. FAC takes security a monumental step than RBAC.
Think about the native M365 Admin Center. The problem is the roles granted by Admin Center are way too broad. FAC is simply more granular than RBAC and fits the requirements of the modern digital workplace much better.
The Power of FAC
RBAC is a way to approach least privilege access, while FAC is a way to actually achieve it. It’s granularity and specificity in what it allows—and doesn’t allow—employees to perform within their IT environment. Here are some examples of FAC policies my team has implemented:
- Virtual Tenants—Operators are scoped to management actions, reports, and audit reports just to the users in the virtual tenant to which they are assigned, i.e. Accounting. Note that the Microsoft Administrator Center cannot filter audit report events. Operators either have access to audit logs for the entire environment, or not at all.
- Workflow—Provide governance for naming conventions and settings; and additional granularity to the attribute level versus the object level – I.e. Operator may create a Teams Channel with the naming standard of [Department Code + Teams Channel Name] with the following settings [External sharing is off for all HR Teams Channels]. Workflow can be used in many different cases, cutting down on errors or missed steps if done manually.
The Path to Least Privilege Nirvana: SaaS Management
FAC is an essential part of implementing least privilege correctly. In Microsoft’s Zero Trust model, the feature functionality that Microsoft and other providers are pushing include privileged identity management (PIM) and privileged access management (PAM), and both are approaches to least privilege access. This is important because most of the time, a CISO will care most about least privilege access. If you asked 100 IT personnel, ‘Should we have least privilege access for all of our applications?’ I’d estimated that all of them would adamantly reply with ‘Yes!’ However, they don’t because Microsoft doesn’t provide the tools that would allow them to do that. You cannot do it natively within the Microsoft 365 Administrator Center.
The only right way to apply least privilege access is to extrapolate administrative access and proxy it 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 gives administrators the ability to turn on and turn off, or even apply a workflow to give time-bound access.
Fortunately, there are SaaS management tools that enable IT professionals to easily and fully batten down the M365 security hatches. There are too many signals and false security alerts for IT/security professionals to check everyone. A SaaS management service can correlate the data, enrich it, and then surface it into an easy to read dashboard and set of reports.
There are some Microsoft 365 veterans that think their administrator identities are secure if they have RBACbut not all RBAC is created equal, and even the best RBAC is no match for FAC.
The Role of the SaaS Management Platform (SMP)
SaaS management platforms (SMPs) can help M365 administrators ensure their network is secure while giving employees access to only the information they need to do their jobs. A secure M365 environment should be able to slice and dice its administration into both roles and functional areas (e.g., user managers, Teams managers, Teams administrators, or security administrators).