Identity Conversations Part 2: Getting your authorization strategy right
- Posted on March 25, 2021
- Estimated reading time 5 minutes
Welcome to part 2 of our Identity blog series. Our first part tackled authentication and access management and we’ll be continuing the conversation around Authorization and the importance of a good authorization strategy that is cost effective and supports audit, compliance requirements and the changing business. We’ll be exploring this topic with Patrick Parker, the CEO of our partner EmpowerID.
Lets start by defining Authorization
It’s the part of the DI system that verifies that you have the appropriate privileges to interact with the resource requested once the system knows who you are.
But how important is authorization today compared to authentication? And what is its role in preventing incidents like the recent Solarigate attack?
Arno: Most hacks begin with the attacker compromising someone's credentials and then using their identity to map out the network, compromise additional credentials and systems, and then steal data or perform malicious activities. Loose control around authorization leads to users having more privileges than they actually require. This enables attackers to spread quickly throughout an organization's network and do significant damage just by compromising a single identity.
Many organizations have moved much of their infrastructure to the Cloud. What is the Cloud vendor's role in preventing such attacks?
Brandon: The cloud is a shared responsibility model with the customer clearly in charge of their authorization policies. In a recent Gartner study, Paul Mezzera predicted that through 2023 over 99% of cloud security failures will be the customer's responsibility, and at least 75% of those failures will result from inadequate management of identities and their authorizations.
Given that authorization is the customer's responsibility and crucial in preventing breaches, how can you get started to better manage authorization?
Patrick: We see that a new mindset is needed to rethink how the organization thinks about security, breaches and what can be protected. “Assume breach” is the idea that given enough time, all organizations will be breached and this cannot be prevented. Moving forward from this conclusion, an organization must minimize the damage possible when a breach occurs. The key to limiting damage is an authorization concept known as “Least Privilege.” This principle addresses authorization and states that an individual should have only the minimum access privileges required to perform a specific job or task and nothing more.
The most apparent benefit of enforcing Least Privilege is the reduction of the attack surface, making it harder for attackers to find privileged credentials and offer them fewer capabilities to perform malicious activities when using a compromised privileged account. In his now-famous response to the US Senate, AWS's CISO Stephen Schmitt stated that "even if a customer misconfigures a resource, if the customer properly implements "least privilege policy," there is relatively little an actor has access to once they are authenticated — significantly diminishing the customer's risk.".
Arno: Least Privilege is indeed an exciting concept and besides “Assume breach” are key principles of the Zero Trust principle that we see more and more organizations adopt.
A challenge we see in authorization is the struggle with “Least Privilege” and how to appropriately allocate the right amount of privilege from a coarse or fine grain control lens and how to standardize this across the organization. RBAC and ABAC models can support to determine the “Least Privilege” concept.
Can you share your thoughts on RBAC and ABAC?
Patrick: I'm glad you asked. To recap on what the various acronyms mean, RBAC stands for “Role-Based Access Control” and controls what users may access by creating roles to which users are assigned and to which the access is granted. The role concept was created to allow standardization of access for users who fit a "similar" role. RBAC is excellent for an organization's ROI and auditability. It reduces the amount of manual access management for IT staff and makes it easier for auditors to review why people have the access they have been granted.
Arno: It is good that you mentioned it. Often organizations look at DI systems only as costs, but they will actually save money over the long term. Imagine the situation for an organization that has 100 joiners and leavers each month. That would mean that these new Digital Identities have to be created, often in multiple systems, and assigned the required permissions manually. This is a lot of work and thus costs which can be reduced by implementing a good DI system with a good authorization model.
Auditability is also a good point. With a proper DI system, an organization can "with the push of a button" show and prove which permissions a person or a system has.
Patrick: ABAC stands for “attribute-based access control” and was developed later than the RBAC model. ABAC was conceived to cover the RBAC model's shortcomings when making authorization decisions for more complex real-time scenarios. Examples of ABAC use cases are a consumer performing a bank transaction or a doctor accessing a patient's medical record.
From these models, would you see a winner going forward?
Patrick: The answer to that is easy; no single approach will ever fit all scenarios. We recommend a hybrid approach where each technology is used for what it does best. Many applications do not support calling out to an external source for real-time ABAC decisions. For these systems, provisioning access via RBAC roles is the only option available. For applications that support real-time decisions and warrant the added complexity, attribute-based approaches are the best options.
Please join us for next months discussion on Privileged Account Management (PAM). You can also visit Avanade.com/security for more information on our Security Services.