What Is the Principle of Least Privilege in a Zero-Trust Security Model?
President Joe Biden’s May executive order on cybersecurity “directs agencies to focus on meeting key baseline security measures across the government, such as universal logging, multi-factor authentication (MFA), reliable asset inventories, and ubiquitous use of encryption, and to adopt a zero trust architecture,” as the Office of Management and Budget’s draft zero-trust guidance notes.
To do this, the agencies’ cybersecurity architecture “must avoid implicit trust in devices and networks, assume networks and other components will be compromised, and generally rely on the principle of least privilege,” the guidance states.
Zero-trust security models are exactly what they sound like: Instead of extending trust as a matter of course, users need to actively demonstrate that their requests can be trusted. In practice, this means deploying tools capable of identifying known users based on characteristics such as passwords, login details or biometric data.
These systems then verify users by evaluating current behavior — such as time of access or type of request made — against their typical actions and ensuring their current permissions level allows access to the data they want.
The principle of least privilege further limits the scope of access by ensuring users only have access to the tools and technologies they need to do their job right now. If projects end or roles change, access privileges should be modified.
Sushila Nair, a member of ISACA Emerging Trends Working Group, notes that this is a significant departure from traditional access frameworks. “Access originally used implicit trust,” she says, “but under this kind of static policy, it’s either full access or no access.”
Jay Bretzmann, IDC’s program director for security products, echoes this sentiment.
“Back in the firewall days, when employees worked onsite, a lot of IT and operations people would overprovision resources just so help desk calls about people not being able to do their work wouldn’t occur very often,” he says. “Now, most security teams are taking the time to better define roles and access using more sophisticated IAM software.”
Bretzmann puts it simply: “Least privilege is really all about limiting the blast radius when data starts to leak.”
DIVE DEEPER: What comes next for the federal government on zero trust?
What Is Role-Based Access Control?
Role-based access control offers a way to streamline security by defining specific roles based on factors such as current job role, project assignment or position within the organization.
“RBAC has been around for a very long time,” says Nair. “Today, we use it pretty much everywhere. You create a group, give permissions to the group and that should be good. It’s the most common mechanism that we apply across access operations.”
Still, it’s not perfect. Nair notes that putting people into the right access groups often requires substantial work, and over time people may gain too many permissions. This “permissions creep” becomes more problematic the longer staffers stay with the same organization — as they move from one position or project to the next, they tend to pick up more permissions along the way until they have broad access that undermines zero-trust objectives.
Bretzmann, meanwhile, points out that “roles change pretty frequently, and organizations can end up with hundreds of definitions — a lot of them obsolete and a security vulnerability when they aren’t deleted.”
EXPLORE: Learn why network behavior monitoring is key to zero trust.
What Are the Three Rules of RBAC?
There are three broad rules that govern RBAC deployments:
- Role assignment. Role assignment helps define the scope of access granted to users. Roles are typically tied to user credentials within the network, such as usernames and passwords. It’s worth noting that users can possess more than one role depending on their job requirements; while this introduces a measure of complexity, it also helps reduce permissions creep by segmenting access.
- Role authorization. Role authorization ensures that users cannot simply assume new roles if they require greater permissions. Instead, they must obtain authorization from administrators who both approve the change and update RBAC frameworks.
- Transaction authorization. Transaction authorization ties resource operation to role. If a user attempting to access systems, download data or make system changes doesn’t have the correct role, the request will be rejected.
RELATED: Why is role-based control central to zero trust?
Benefits of Role-Based Access Control
RBAC is now “more or less the industry standard approach for any organization that moved beyond homegrown tools for managing user identities, and limiting resource access by role is very useful for any organization with compliance mandates,” Bretzmann says.
It makes sense: With due diligence now a key component of effective security frameworks, RBAC helps reduce the risk of unsanctioned and undetected access.
RBAC is also “the most widely used system and built into the most tools,” Nair says. “People understand it clearly.” This makes it both functional and familiar, in turn reducing employee pushback when new systems are deployed.
In addition, RBAC offers a way to improve remote and hybrid work security. By defining users by role and further refining access by location — for example, staffers might be prohibited from viewing classified files unless they’re in the office or are using an approved VPN — agencies can reduce the risk of accidental compromise.
Nair does offer a word of caution when it comes to RBAC, however. “We should always front-end it with information governance and administration (IGA) tools to ensure people end up in the right group. You need a well-defined user management process to get the most from RBAC.”
“Otherwise,” she says, “it’s garbage in and garbage out.”
Steps for Role-Based Access Control Implementation
With a host of RBAC tools and technologies now available, federal organizations should have no trouble finding a solution that’s vetted, approved and ready for implementation. But it’s one thing to have the solution in hand and another to effectively deploy it across existing networks.
Bretzmann points to five key steps:
- Define your roles. First, agencies need to broadly define access roles and which services and data each role will access.
- Review system usage. Next, it’s critical to review system usage and assign roles based on current positions and projects.
- Reassign roles as needed. Role evaluation and reassignment follows. Inevitably, some staff will have too much access and some too little, prompting a need for adjustment.
- Redefine roles based on data. Role redefinition comes next. Roles can be fine-tuned to meet the needs of specific users or reduce specific risks.
- Add and delete roles. Finally, agencies can add new roles if current segmentation isn’t granular enough, or delete roles that are no longer in use.
This isn’t a one-and-done process. Effective RBAC implementation requires a cyclical approach that sees organizations continually defining and redefining roles to ensure access frameworks match the reality of remote and hybrid operations while simultaneously limiting total risk.
