To this end, there are many existing rights models: MAC, DAC, GBAC, ABAC, etc.

How do you understand these many different rights models in practical terms and apply them to your business?

The models differ in their degree of complexity and in the response they provide to the specific needs and constraints of an organisation or system. The most recent models incorporate issues of security, scalability and compliance in an increasingly complex technological environment.

In this article, we will follow a chronological logic, identifying how authorisation has evolved over the decades to meet the challenges faced by organisations. We will see that, like information systems, rights model approaches have become increasingly complex and now include more and more parameters for deciding whether to grant or deny access.

Models can be grouped into 3 approaches reflecting their progressive sophistication:

– Classic approach: admin-time

– Modern approach: run-time

– Forward-looking approaches: event-time

We will illustrate each of these approaches with emblematic models, highlighting:

1) The response to an initial need

2) The limitations of the model

We conclude with a chronological summary of the approaches and their models.

Classic authorisation approaches: Admin-time

In the 60s and 70s the development of computer systems, marked by the development of the first multi-user systems (Multics, HP-3000), gave rise to the need to rethink user rights.

Innovative security principles, which are still used today, were defined for these systems such as rings of protection, which aim to protect the integrity of the operating system against deliberate and accidental modifications and initiate a rethink of user access policies to resources.

In the first access rights models to emerge, the management of rights remained summary, defined in hard terms by ‘administrators’: this was admin-time, of which the DAC and MAC (60s-70s) and RBAC (90s) models are particularly noteworthy.

Discretionary Access Control (DAC) and Access Control Lists (ACLs)

As its name suggests, the DAC model – for ‘discretionary access control’ – leaves it up to each resource owner to assign permissions to users. This is the basic rights model found on Unix systems, which can be supplemented by the ACL mechanism, or ‘access control lists’. Often associated with DAC, ACLs specify, for a given resource, the users and their rights over the resource, as illustrated below using the Unix example.

Beyond Unix, file-sharing systems such as OneDrive and social networks, where the user can choose who can view or comment on each publication, are other examples of the use of DACs and ACLs.

In fact, the flexibility and granularity of this model are an advantage for local implementations centred on individuals. On the other hand, they become problematic for ensuring a correct level of resource protection on a large scale in more complex systems.

Mandatory Access Control (MAC)

The MAC model, which stands for Mandatory Access Control, is the opposite of DAC. Rather than leaving the assignment of rights to the ‘discretion’ of individual users, resource by resource, limiting system-wide visibility and encouraging errors and vulnerabilities, rules are predefined by administrators according to different security classifications and strictly enforced by a central authority, generally represented by the operating system itself.

It is particularly prevalent in government, military and industrial environments, because it allows tight control over access to sensitive data. It uses labels that characterise the sensitivity of objects and users, according to the rules of the organisation concerned:

– A resource classification level, for example: ‘Unclassified’, ‘Restricted’, ‘Confidential’, etc.

– A level of user authorisation, linked to the existing resource classification levels.

Below we describe Multics and SELinux, two fundamental examples of MAC implementation.

MAC example 1: Multics and protection rings

Already mentioned above as a precursor of multi-user systems (also known as ‘time-sharing’ systems), the Multics project, released in 1969, was the source of many innovative features, particularly in its memory management and security. It prefigured MAC even before the formulation of models such as Bell-LaPadula (1973) and its first formal definition set out in the Department of Defense’s Orange Book (1983), which established US computer security standards.

It is based on the concept of rings of protection, which Multics created, as shown by its logo (image above), and which form the basis of MLS – Multi-Level Security – systems, widely used in highly confidential contexts. It consists of a set of concentric rings representing levels of sensitivity that increase the closer you get to the centre (ring 0) – and therefore the privileges required for access. Mechanisms known as guards or gatekeepers, located at the interface between two rings, closely control the legitimacy of access in both directions, which they grant or deny.

In reality, these rings are of two types:

– Kernel protection rings are physical rings built into processors and used by the operating system to guarantee its integrity against faults (which cause the machine to crash) or modifications, whether intentional or not.

– User space rings are logical rings implemented by the operating system. This is where MAC comes in. By means of labels, each user and each resource is attached to a ring level. From there, rules define the actions that can or cannot be taken, following the example of the Bell-LaPadula model, which emphasises data confidentiality: ‘No read up’ (a user cannot read access to layers higher than his own), ‘No write down’ (he cannot write to layers lower than his own, to avoid leaks).

The image below summarises the principle of protection rings.

 MAC example 2: SELinux, the Linux kernel security module

Initially developed by the NSA in 2001, SELinux was proposed and added to the Linux kernel security modules (LSM, Linux Security Modules) in 2003, and is natively integrated into RedHat distributions such as Fedora.

This is another well-known example of MAC implementation: it allows administrators to assign a security context label to each resource in order to classify them and define the security policies to be applied by the operating system. Even with privileged rights, an application will see its rights restricted to the domain it needs to function (for example, the folders specified), with SELinux detecting and preventing any non-compliant action.

SELinux therefore provides an additional layer of protection in the event that a user or process manages to bypass traditional access controls.

In practice, MAC policies are rarely sufficient on their own, but are superimposed on existing DAC rules, whose flexibility they compensate for.

Two models based above all on the identity of the user or process, on the basis of which they authorise or deny access: this is known as Identity-Based Access Control (IBAC). These models are still limited to local contexts and have little resistance to scaling up.

Role-based Access Control (RBAC)

Formulated in 1992 by David FERRAIOLO and Richard KUHN, two engineers from the American NIST, the RBAC model – role-based access model – was designed to simplify the management of permissions throughout an organisation while reflecting its structure as closely as possible (hierarchy, responsibilities, departments, etc.).

Instead of granting rights directly to an identity, as with IBAC, a method that can quickly become difficult to maintain, we design business roles and the associated privileges. Users then inherit the rights associated with their role within the company, enabling them to access the various applications and enterprise sharing systems considered necessary for their internal activities.

This initial conceptual framework was completed and standardised in 2004 with the ANSI INCITS 359-2004 standard, which takes into account practical business cases and scenarios. For example, it addresses the need to separate responsibilities (SoD, Segregation of Duty), which is fundamental in financial and banking institutions, as well as the principle of least privilege and the inheritance of permissions.

Progressive and increasingly centralised adoption of RBAC

From the 80s and 90s onwards, databases, which were widely adopted by large companies and likely to contain sensitive information to which access was naturally controlled, were pioneers in the implementation of the RBAC model. They illustrate its implementation at the level of isolated applications, with no repercussions for external applications or systems.

The 2000s saw the launch of Microsoft’s Active Directory, starting with Windows 2000 Server. This centralised directory is designed to manage all the organisation’s resources (people, physical resources, applications). Although it is not strictly speaking an RBAC tool, a comparison can be made. The allocation of access rights is based on security groups – which can be perceived as roles – with permission inheritance mechanisms and the concepts of domains, trees and forests designed to represent the logical structures of the company.

Modern IAM solutions, such as Okta, SailPoint IIQ and Microsoft AzureAD, now support RBAC for heterogeneous environments, including cloud services. They illustrate the gradual centralisation of access rights management, which was initially managed locally within applications, and is now increasingly delegated to IAM solutions covering the widest possible spectrum.

RBAC assigns rights based on a business role, whereas IBAC is linked to an identity. The layer of abstraction created between the subject’s identity and an individual’s role means that it can be extracted from restricted contexts (file systems for DAC, operating systems for MAC) and adapted (at last!) to the access control needs of organisations. However, they all share the characteristic of a rigid definition of rights, based on an identity or a role.

In entities where exchanges are increasingly dynamic and fluctuating, this abstraction through roles alone may prove insufficient. New models have emerged to represent more complex organisations, taking into account additional, evolving attributes to assess access rights to a higher accuracy at a given time: we are moving from admin-time to run-time.

New approaches to authorisation: Run-time

The increasing complexity of information systems, and therefore of access, has led to the run-time approach. This approach meets organisations’ needs for dynamic flexibility and security. Unlike the ‘admin-time’ era, characterised by static permissions, the ‘run-time’ era offers real-time management at the time of the access request, based on various contextual elements. This transition to more flexible and precise authorisation models enables organisations for adapting to change and better protect their resources against today’s threats.

Graph-Based Access Control (GBAC)

The GBAC (Graph-Based Access Control) or GraphBAC model is based on the use of graphs to represent the relationships between users, roles and resources within an organisation. These 3 types of entities (users, roles, resources) and the relationships between them form the core of this model: entities can be represented by the nodes of the graph, and the relationships between them by the edges.

Access authorisations to a resource are determined in real time by queries to this graph database, enabling access decisions to be made based on the connections between entities at the time of the request. Users can thus obtain access to a resource according to their role and their relationships with other users or resources in the organisation.

The GBAC model is suited to the dynamic environments of large organisations, where relationships between entities are constantly evolving. On the other hand, it can be complex to implement, and the projects involved are relatively long, with significant costs. In addition, the gradual addition of new relationships can make the graph increasingly difficult to manage, complicating internal audit or recertification activities, for example.

Attribute-Based Access Control (ABAC)

In the ABAC (Attribute-Based Access Control) access model, the management of access to a resource is based on the dynamic combination of attributes. These attributes relate to the user requesting access (role, group), the resource requested (type of resource) and the context in which the request is made (time of day, type of network). This approach makes it possible to authorise or deny access flexibly and in real time.

The model was formalised in 2014 in the publication by NIST (SP 800-162) which provides detailed information for its implementation.

4 components are essential to the operation of this model: Policy Enforcement Points (PEPs), Policy Decision Points (PDPs), Policy Administration Points (PAPs) and Policy Information Points (PIPs).

After interception by the PEP, the access request is transmitted to the PDP, which is responsible for making decisions by analysing the access policies managed by the PAP and often accessible from an access policy database. The PIP provides the PDP with additional information on the user or resource from different sources, enabling it to make decisions in line with access rules. For contextual information, the information system can be connected to other tools or sources (IDS, logs, sensors) that enable this information to be collected at the time of an access request.

ABAC is a particularly interesting model in environments where access needs are varied and evolving, as it enables fine, granular management of authorisations, particularly in the context of PAM (Privileged Access Management), concerning access and critical resources.

However, this level of detail and flexibility comes with challenges such as the ongoing review of attributes and the maintenance of policies, which require constant attention to ensure they meet the needs of the business. Over time, the increasing number of attributes and conditions can make it difficult to maintain a clear and functional ABAC architecture, especially in environments undergoing constant transformation.

In current ABAC architectures, PEPs are generally designed to work only with PDPs from the same vendor, using proprietary protocols, with no support for compatibility between different vendors.

Standardizing the way these different PEPs and PDPs interact, in order to improve system interoperability and reduce dependence on a single supplier, is the aim of the OpenID AuthZEN working group.

OpenID AuthZEN: towards improved interoperability

AuthZen is a working group initiative launched in 2023 by the OpenID Foundation to standardize the interactions between PEPs and PDPs, in order to improve interoperability between systems from different suppliers.

This initiative responds to current problems where authorization services (PEPs and PDPs) are often designed to work only with solutions from the same vendor, limiting their interoperability.

AuthZen was launched to develop a standardised protocol that would facilitate integration and communication between PEPs and PDPs, reducing dependency on single vendor solutions and improving overall authorisation security.

To make these interactions more flexible and universal, AuthZen relies on existing architectures and technologies (OPA/Rego, XACML, etc.) to improve deployment, scalability and interoperability. The first two stages of this standardisation with Open ID AuthZen are the implementation of a simple ‘Request/Response’ and ‘Permit/Deny’ type protocols and a multiple decision approach in order to group several authorisation requests into a single request and receive several decisions in return.

The AuthZen think tank includes security players such as 3Edges, Axiomatic and others. It is also open to players who want to develop authorisation systems and make architectures more secure and interoperable.

Prospects for the evolution of authorisation: Event-time

A new approach to the evolution of access systems is event-time. It is defined as an implementation of dynamic authorisation where access rights are adjusted in real time in response to immediate events or changes that occur. Unlike static or attribute-based approaches, event-time is characterised by a continuous evaluation of access rights, to ensure that all access remains compliant with the policies in place within the organisation.

For example, when a user’s status changes (promotion, departure, mobility, etc.), the system automatically adjusts or revokes their access rights. This proactive, event-based adjustment approach is common in information systems monitoring and security incident management.

Event-time is based on the following key concepts:

– Listeners: system components that monitor events in time and analyse important changes (mobility, promotions, departures, etc.) from various sources, in particular HR systems.

– Triggers: actions in response to an event identified by a listener, such as the revocation of access rights on the actual day a user leaves.

– Shared Signals: enabling different systems to share information about events in real time.

– Continuous evaluation: constant checking of access rights to ensure that each action or access remains in compliance with policies.

Frameworks and standards play a key role in implementing event-time by providing a structure for implementing the concepts in systems:

The Shared Signals Framework (SSF) is directly linked to the concept of shared signals, which enables systems via an API to share information about events in real time to ensure consistent access management. The continuous evaluation of this information is supported by CAEP (Continuous Access Evaluation Protocol), a protocol for standardising the writing of status changes. RISC (Risk and Incident Sharing and Coordination) is a generic protocol for standardising the transmission and reception of security incidents between these different systems, thereby enhancing the overall responsiveness of an information system.

Event-time is not based on a specific model such as RBAC or ABAC, but can function as a complementary access management layer to these traditional access systems, making them more dynamic and aligned with real-time situations.

The evolution of authorisation models, from traditional approaches to modern, dynamic methods, reflects the ongoing adaptation of IAM and access systems to the growing and changing needs of organisations.

Admin-time approaches laid the foundations for resource security with models such as DAC and MAC. RBAC introduced structured rights management, which is widely adopted in organisations today due to its relatively simple application.

With the advent of the runtime, access decisions became more refined, based on attributes specific to users, resources and context, as with the ABAC and GBAC models. However, these increasingly sophisticated models have led to the emergence of numerous proprietary solutions, limiting the interoperability of authorisation components and creating a dependency on specific technologies. This has led to the emergence of initiatives such as the AuthZen working group, which is working to develop standards.

The event-time approach provides real-time responsiveness, enabling systems to automatically adjust access in response to specific events. CAEP and the Shared Signals Framework facilitate this dynamic by standardising the exchange of information between systems, thereby strengthening security and compliance.

An overview of these different approaches and their associated models is presented in the timeline below, together with a summary table of the different models discussed.

By combining these different approaches, you can implement more secure, flexible and proactive access management, capable of responding to current and future identity-related challenges. These developments also highlight the importance of adopting adaptive and interoperable authorisation solutions to ensure effective protection of resources while meeting the operational requirements of teams.

These developments raise an essential question about the ability of organisations to anticipate these changes and integrate these new access management dynamics.

Whether you are still using admin-time models, exploring runtime options, or considering moving to event-time management, it is crucial to choose a model that meets your specific needs. It is also very important to anticipate the consequences for the management of this model over time (review of rights, measurement of data quality, review of policies, definition of expected reactions, etc.).  

What type of model do you use? 

Don’t hesitate to contact us to find out more and understand how to apply these authorisation models to your organisation’s context!

Cet article Access management: how is authorisation evolving to meet the challenges and needs of organisations? est apparu en premier sur RiskInsight.

Azure, in recent years, has been gaining a foothold in this sector, as Gartner has pointed out, ranking them among the visionary leaders of Industrial IoT (IIoT) platforms [1] due to its capabilities, and its almost complete coverage of all use cases and industries.

The IoT, by nature often widely exposed, even on the Internet, can be the target of attacks. It is therefore essential to put in place security mechanisms, and to apply best practices to improve the security level of the platform and the objects that connect to it, which we will explore in this article.

Before moving on to specific recommendations for protecting your IoT devices and data, let’s look at how the various Azure IoT services can be used together to create secure IoT solutions.

Presentation of the Azure IoT offer

Microsoft Azure IoT is an end-to-end platform for connectivity, analysis and visualization of data from IoT devices. It also offers interconnection with other standard Azure services such as Azure Machine Learning and Azure SQL Database.

Azure IoT offers two solution ecosystems to its customers:

• Azure IoT Central is a fully managed aPaaS, Platform as a Service application that simplifies the creation of IoT solutions. This service is responsible for connecting, managing and operating fleets of devices, and provides a management user interface. Azure IoT Central is an aggregate of different Azure IoT services such as Azure IoT Hub or Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central offers application models according to several business domains: Retail, Health, Energy, Industry, etc., and aims at a “turnkey” implementation.  

• A customised ecosystem thanks to the various Azure PaaS (Platform as a Service) services. In this ecosystem, two services; Azure IoT Hub and Azure Digital Twins are the foundations of an IoT solution. We have also combined them with Azure Device Provisioning and Azure Device Update for optimal coverage of cyber security needs.

These two ecosystems enable Azure to address all types of IoT and IIoT needs:

• Azure IoT Central offers a complete service if you want to quickly develop a low-complexity application thanks to its application template catalogue.
• If you want a custom solution, or with features not supported by Azure IoT Central: opt for an ecosystem based on Azure IoT Hub.

Now that we have a good understanding of the Azure IoT ecosystems, it is important to focus on securing these ecosystems. How can we effectively protect IoT devices and data when using Azure IoT services? This is what we will explore in the following sections.

Preamble: the Azure CLI tool

In order to manage Azure resources, Microsoft provides several tools, most of which can be used in CLI (Command Line Interface). The tool offering the most functionality for management is Azure CLI.

This tool, available for Windows and UNIX operating systems, allows a user who is a member of an Azure environment to manage and obtain information about Azure resources. It should be noted that the range of possibilities of this tool varies according to the rights that the user has over the resources in question.

To install it, Microsoft provides a dedicated page explaining the steps for any type of environment.

In order to use it, all you must do is connect to an Azure user account via the chosen command interface (PowerShell or Bash), then enter the desired commands. Once the use of this tool is finished, a disconnection of the account is recommended.

A typical use of this tool is shown below:

The documentation of this tool, presenting and explaining all the possible commands, is available at this address.

This tool will be used later in the example of technical manipulations.

1st security vector: authentication of objects

Device authentication is crucial for an Azure infrastructure as it ensures that only authorised devices can access cloud resources. Azure IoT services support two main means of authentication for IoT devices:

• A SAS Token (Shared Access Signature) is a string of characters used to authenticate devices and services. An SAP token has the following structure:

This type of authentication has a defined validity period and permissions, which are assigned based on an access policy, on a given perimeter. The signature, on the other hand, is a crucial element because it is responsible for guaranteeing the security of communications between the object and Azure services, but also for proving the identity of the device. This signature is generated from a secret that must be specific to each device.

• An X.509 certificate [2] is a digital certificate allowing strong authentication of the object. It contains information about the entity issuing the certificate, the validity period of the certificate and the identity of the subject (e.g. the object). One of the strengths of certificates is the ability to create chains of certificates, and thus create trust relationships:

X.509 certificates offer a higher level of security, assuming a state-of-the-art cryptographic algorithm, as they allow trust relationships to be represented. However, the management and use of certificates can involve additional complexity for an IoT project.

In order to force the use of X.509 certificates to authenticate connected objects, it is possible to prohibit SAS tokens for an IoT Hub. Indeed, Azure IoT Hubs have three properties related to the use or not of SAS tokens: disableLocalAuth, disableDeviceSAS and disableModuleSAS. Therefore, the best practice associated with disabling SAS tokens is to set these three parameters to True. This can be done using the Azure CLI tool:

Checking the values of these same parameters can also be done using the Azure CLI:

In the example response below, the disableDeviceSAS property has been set correctly, but the other two have not.

The Azure portal also allows you to perform this verification:

The choice of authentication method for Azure IoT will depend on the security requirements of your solution. If you need strong security and have the infrastructure to manage certificates, then X.509 certificate authentication is a good option. However, if you are looking for a solution that is simple to manage and use, the SAS token may be more suitable for your needs.

2nd security vector: RBAC and alerts

The assignment of roles on your Azure IoT infrastructure must be thoughtful and defined according to the needs of the users. A precise definition of roles and permissions makes it possible to limit access to resources and to the various functionalities available on the platform. The various Azure IoT services provide a multitude of pre-configured roles that can be adapted to your needs and your organisation. Secondly, applying the principle of least privilege, and limiting the number of accounts with important privileges, allows you to improve the security level of your Azure IoT infrastructure.

Azure CLI allows you to list the users with rights to the desired Azure IoT resource and their associated roles. The following command allows you to perform this action

It is possible to use string selectors (Select-String for PowerShell, grep for Bash) to retrieve only the desired information.

In the example below, names, types and roles were the only items retrieved using Select-String:

The Azure built-in roles feature is available on this page.

Configuring alerts based on the metrics of your Azure IoT services is another tool to consider. Alerts can be configured to detect suspicious behaviour or anomalies, allowing for rapid investigation of your infrastructure. Azure provides its customers with a large collection of signals to define alert conditions. It is also possible to define custom alert signals via the query language used by Azure Log Analytics.

The Azure Portal is the easiest way to set up alerts based on the data collected by the IoT Hub. For example, to define a log alert rule, you need to:

1. Go to the management page of the desired IoT Hub;
2. Go to the Logs sub-category of the Monitoring category;
3. Choose a rule using the Azure Log Analytics language;
4. Add an alert rule related to this query;
5. Choose the operator, unit, threshold value, check recurrence and time period for the rule

These actions are summarised in the screenshots below:

It will then be sufficient to choose an action group linked to a type of action (sending an email, SMS, etc.).

The example given will lead to an action if the number of failed connections of connected objects to the IoT Hub concerned exceeds 10 failures in 10 minutes or less.

A detailed guide in the form of a tutorial is available on the Azure documentation. Note that this service is available at an additional cost.

3rd vector of security: the service itself

Finally, setting up proper configuration of Azure IoT services is a key element in improving the platform’s cyber maturity level. This includes options such as routing rules or setting the minimum version of TLS used by devices to connect to Azure IoT Hub.

Routing rules are used to redirect messages from IoT devices to an endpoint (storage, services, database, etc.) and are configurable by routing requests. It is recommended to filter incoming messages, via routing requests, to increase the security of your IoT solution.

Checking the minimum TLS version accepted can be done using the Azure CLI: indeed, an IoT Hub has the minTlsVersion attribute to check this property. This check is performed using the following command:

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification

If this command returns nothing, or returns a value less than 1.2, then the configuration is not satisfactory.

The Azure portal also allows you to perform this check:

En synthèse

Security is a major issue for IoT projects: Microsoft, with its Azure IoT product, provides an IoT platform that meets the majority of IoT needs in a secure manner, provided that it is configured correctly. In this article, we have discussed recommendations for improving the security of your Azure IoT infrastructure.

It is important to keep in mind that other attack vectors exist, such as hardware and software vulnerabilities and the networks used by IoT devices.  Securing an IoT infrastructure is a complex challenge that requires an end-to-end approach.

With the help of Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Improving the security of your IoT infrastructure: configuration tips and best practices on Azure IoT est apparu en premier sur RiskInsight.

DAC, RBAC, OrBAC, ABAC or GraphBAC? Flagship authorization models evolve regularly and each one brings its share of challenges, promises, and complexity.

Over the last twenty years or so, during which the RBAC/OrBAC models seem to have prevailed, the difficulties of designing, implementing and maintaining an authorization model have remained the same, and there are few examples of perfectly satisfactory achievements.

There are many questions about designing or redesigning one’s authorization model. In these two articles, we try to answer the most frequent ones.

Before we do that, let’s go back to some basic notions about authorization models.

What is an authorization model?

A layer of abstraction…

An authorization model is a layer of abstraction that comes above technical entitlements (application rights, transactions, groups, etc.). It is made up of carefully defined objects (roles, profiles, etc.), with a name in natural language, and often organized hierarchically.

… which simplifies the management of authorizations…

This layer of abstraction makes it possible to rationalize the number of objects to handle.

For the business, it becomes easier to understand the available authorizations and to request or validate the appropriate rights.

For IT and support teams, the burden of allocating authorizations is reduced overall. The implementation of automation tools can support a large part of the daily requests, allowing specific requests to be processed more carefully.

… and improves security

Beyond the regulatory and normative dimensions of authorization management, often highlighted by Auditors during their work, the lack of control of authorizations is an open door to intrusions and misuse of the information system.

Knowing one’s authorizations is a prerequisite for securing them, and the implementation of a model makes it possible to simplify the controls, particularly during review campaigns. It is indeed much easier for a manager to validate the allocation of a meaningful business role, rather than of a transaction with a very technical name.

Overview of possible models

DAC: Discretionary Access Control, aka no model at all!

What if the best model was the absence of a model? In some limited cases, especially if the number of authorizations or users is very limited, one can very well do without designing a model that would add an unnecessary layer of complexity. This implies, however, that the authorizations are sufficiently meaningful.

RBAC: Role-Based Access Control

The RBAC model allows to group the authorizations required to perform a function within a company (business, mission, project…) in “roles”. These roles are then assigned in lieu of discretionary authorizations. They can be organized hierarchically, for example by subdividing “business roles” into “application roles”.

OrBAC: Organization-Based Access Control

The OrBAC model is a variant of the RBAC model in which the entities that make up a company are one of the modeling dimensions. Each user then has one or more roles depending on which team(s) they belong to.

ABAC: Attribute-Based Access Control

The allocation of authorizations via the ABAC model is handled through a set of rules based on attributes related to users, resources themselves, or the environment. This allocation is often “dynamic”, meaning that the authorization to access an application or part of an application is evaluated at the moment the user tries to access it. In practice, it is possible to set up an ABAC model that takes advantage of user’s roles, as in the RBAC model.

GraphBAC: Graph-Based Access Control

The GraphBAC or GBAC model is based on the representation of authorizations using a graph linking objects (file, user account…) through various relationships (link between collaborator and manager, belonging to a structure, possession of a file…). The authorizations are then the result of queries on this graph, which allows to give access to a resource according to its relationship with other objects.

Market vision

The table below compares in a very synthetic way the different authorization models that we have just seen.

The most common questions about authorization models

What should my empowerment model be used for?

Setting up an authorization model can be complex, costly, and time-consuming. Therefore, it is crucial to study the needs in depth and to clearly define expectations. As mentioned in the introduction, the implementation of an authorization model can help address access security issues, meet regulatory objectives, but also simplify the user experience and improve the efficiency of Identity & Access Management (IAM) processes. One of the key success factors for an authorization modeling project is the ability to express the expectations precisely, using KPIs if necessary: reducing the time required for a manager to grant accesses when an new employee joins to 15 minutes, mitigating 90% of risks considered critical, etc.

Who should I involve to build, instantiate, and keep my model alive?

Given the cross-cutting nature and scale of the transformation induced by a change or creation of an authorization model, a strong governance is necessary.

It is preferable to involve a sponsor with high visibility from the EXCOM, who will be able to provide support, and obtain strong engagement from the business, the first concerned by the changes, and from application managers, who will be heavily involved during the design and implementation phases. Key contacts can also be identified, so that they can help different teams within the organization (HR, IT, Internal Control…).

Beyond the project phase, it is also necessary to identify the actors who will be in charge of keeping the model alive. A key success factor in the implementation of an authorization model is the identification of role owners. If each role includes only authorizations from a single application, one can easily to turn to the application manager, but in most cases, each role is made up of authorizations from various applications.

The ideal is to find someone who has both knowledge of business processes, company organization, applications, and an understanding of security rules: it’s a difficult exercise! Otherwise, a small team combining the different area of expertise should be able to perform this function.

Do I have to include “fine-grained authorizations”? The “perimeters”? How granular should my model be?

The world of entitlements is as vast as the multitude of existing applications, and the use cases that an authorization model must cover are numerous.

The topic of fine-grained authorizations and perimeter management regularly comes up during the design phase: should they be included in the model or not? There is no predefined answer.

It is perfectly conceivable, in some cases, to restrict the model only to the binary access to the application (yes/no), and to leave the management of the fine-grained authorizations and perimeters in the hands of the application manager and their team. The request form may then provide a text field to provide additional information. This results in less auditability, but the management of requests is simplified.

If we decide to include the concept of perimeter, we must choose between a cross-implementation, in which we create as many roles as there are combinations between authorizations and perimeters (possibly increasing significantly the number of roles), and a separate implementation, where the authorizations are created on one hand and the perimeters on the other.

It is probably best to deal with this issue separately, even if it means creating roles combined with their perimeter in the future, depending on the real use cases: the resulting model thus has a more reasonable size.

What should I include in my model? What about physical accesses and physical assets?

Including all the authorizations within one’s model is extremely difficult, if not impossible given the wide variety of cases, and for the sake of project efficiency.

The goal of the model must always be kept in sight. For example, if the goal is to improve the user experience when requesting rights, it is better to prioritize the processing of business-oriented authorizations, which are likely to be allocated frequently, over little-used technical authorizations.

In addition, it may be tempting to include physical access (premises, specific rooms, etc.) or physical assets (badges, PCs, telephones, etc.) in its authorization model, as they are part of the means that employees must have to work, just like logical accesses.

Again, there are no major prohibitions, and some companies may well manage access to their premises within their authorization model, but as a general rule, physical access and assets are rarely part of it.

An IAM solution may however help manage them properly:

• By centralizing requests, sent to different actors or systems upon arrival of a collaborator. This “arrival package” then includes both logical accesses (accounts and default rights) as well as physical resources.
• By providing a reference source for data and events related to a person. This information, especially arrival/departure dates, is shared with badge management systems to manage the badge lifecycle.

We have just addressed four initial questions to carry out a project to overhaul an authorization model. Other questions will be detailed in a second article, to be published shortly.

Cet article Redesigning your authorization model: the key issues (1/2) est apparu en premier sur RiskInsight.