What is the Toxic Policies functionality?

With the HelloID Toxic Policies functionality you can detect and remove conflicting rights (the toxic policies) by setting rules that determine which rights should remain in the event of a conflict. This helps you both improve security and save unnecessary licence costs.

What is a policy rule

A policy rule is a clear guideline established within an organisation that indicates, for example, how a particular process is executed, who has which authorities, or on the basis of which criteria a decision is made. Policy rules form part of, or are derived from, your organisational policy and ensure that we work together in a consistent and transparent way.

What is a business rule

A business rule is generally an agreement on how a specific process or activity is carried out within an organisation. In our HelloID IAM context, it is a rule with which we can define our role model. In a business rule you can, for example, stipulate that everyone with the role ‘care worker level 3’ always receives access to the care application.

Toxic Policies: Enforce Segregation of Duties

HelloID supports your identity governance with functionality such as Toxic Policies. This enables us to prevent granting access rights to a person if they also hold other conflicting rights. This ensures, among other things, that we do not issue costly, redundant licences. It also helps prevent fraud and other undesirable behaviour because people cannot quietly accumulate too many rights.

Rationale for our Toxic Policies functionality

The rationale for the Toxic Policies functionality lies in the fact that within HelloID we use Role-Based Access Control (RBAC) for the issuance and management of accounts and access rights. The basic principle is that a person’s role in the organisation determines which accounts and access rights they need. We deliberately use an advanced approach in HelloID. Instead of a rigid framework where every right is defined per role, we use business rules. These are manageable rules in which, for example in a care organisation, we can easily define that everyone with the job ‘Care Assistant level 4’ receives access to the Electronic Client Record.

The advantage is that your administrators can work with these understandable policy rules without needing to delve into the underlying technical structure of roles, attributes, and rights. You also do not have to link every access right to individual roles. For example, you can simply specify that everyone in your company receives a Microsoft 365 account, regardless of their specific role. Many rights also apply to all employees in a particular department or per location. Ultimately, there are often only a limited number of rights that truly need to be defined as role-specific. In a traditional RBAC model all rights must be linked to roles, which quickly leads to a proliferation of roles and very complex maintenance. With business rules we keep it simple and manageable; you can focus on your policy rules and HelloID translates those rules into a consistent, coherent hierarchy of rights.

There is one point to note. In practice, multiple business rules can apply to each individual employee. We already gave the example of a business rule that generally states that every employee should receive a Microsoft 365 licence. As a member of a specific department, you can then also gain access to the departmental share (an additional business rule). Depending on a person’s role or roles in the organisation, other rules may also apply to grant the corresponding access rights. While each individual business rule is correct on its own, combinations of rules can sometimes create duplications or contradictions. You naturally want to prevent that, and the Toxic Policies functionality is the ideal tool for this.

Examples of Toxic Policies

Let us make the foregoing concrete with two examples. In the first example, two conflicting business rules cause unnecessary licences to be issued. In the other example, the business rules result in conflicting access rights being granted:

Example 1: Microsoft offers various Enterprise licences such as E1 and E3. Someone with an E3 licence has additional capabilities compared with E1. While everyone in the organisation receives an E1 licence by default (business rule 1), there are employees in a specific role who must receive an E3 licence (business rule 2). The business rules are correct on their own, but some employees therefore receive both an E1 and an E3 licence; that is needlessly costly.
Example 2: In an organisation you may have functionality to enter invoices and functionality to approve them. If there is a rule that gives someone the ability to enter invoices, that same employee must not also have the ability to approve them. If that unfortunately does happen, because someone has accidentally been assigned both roles, that combination of business rules breaks the segregation of duties within your organisation.

The Toxic Policies functionality can help prevent such unwanted combinations and thereby reduce costs and limit the risks of fraud.

How do we manage Toxic Rules within HelloID?

We show how this works in the HelloID Provisioning module, where we apply such business rules. Let us take the example with the E1 and E3 licences, where everyone in the organisation receives an E1 licence by default but IT staff must receive an E3 licence:

Without the Toxic Policies functionality, when we run an evaluation of the issued licences based on the business rules you see that everyone has received an E1 licence and that IT staff have also received an E3 licence. An expensive duplication.
You can now activate the Toxic Policies functionality and configure a new toxic combination within it. There you configure that if someone receives rights for both an E1 and an E3 licence, only the E3 licence should be assigned.
When you activate that toxic combination, you then see that all users who previously had both licences assigned now receive only an E3 licence. You also see a notification for the relevant users that a right has been denied to them, namely the E1 licence.
Those settings are of course also applied in the relevant target systems. If the conflicting rights had already been granted earlier, those unnecessary E1 licences are withdrawn again after activating this toxic combination.

Support for your compliance

The above example prevents unnecessary licence costs, but you can also use the Toxic Policies functionality to support Separation of Duties (segregation of duties) within your organisation.

Segregation of duties is important in organisational policy and is also a requirement in many information security standards. In the BIO (Baseline Information Security for Government) it states, for example, that ‘conflicting duties and responsibilities should be separated in order to reduce the likelihood of unauthorised or unintended modification or misuse of the organisation’s assets’. We already mentioned the example of the employee who issues invoices and therefore must not also approve them.

This role separation is often determined at a higher level in the organisation and translated into roles per employee, which are recorded in, for example, the HR system; the IAM platform then ensures that everyone, depending on that role and other attributes such as department and location, receives the correct rights. Your IAM environment is therefore ideally suited to implement or check the final details of this role separation. You do this by configuring toxic combinations that apply the correct resolution in the event of unwanted combinations; in the example mentioned earlier there is a toxic combination containing the right to create invoices versus the right to approve invoices.

Using the HelloID Provisioning module we can therefore grant access rights automatically based on attributes such as a person’s role, competencies, department, and workstation. With the Toxic Policies functionality we can also prevent giving too many rights to an individual user.

Use Toxic Policies? Or just business rules?

Why use the Toxic Policies functionality at all? Our business rules can also be configured very flexibly. Could we not achieve the same outcome by further detailing our business rules with, for example, additional conditions? Sometimes that is possible, but the problem is that you then undermine the strength of the business rule concept. You want to keep your business rules as clear and simple as possible and not make them needlessly complicated with all kinds of exceptions. The Toxic Policies functionality is therefore a perfect complement, because it allows you to recognise and resolve precisely those exceptions with ease.

We illustrate this again using the earlier example of Microsoft licences. With those E1 and E3 licences it is essentially about the details of Microsoft’s licensing. An E3 licence is a superset of E1; if you have E3, you do not need E1. With another supplier it may work completely differently; two licences can be complementary and you need both. These kinds of licensing details have nothing to do with a person’s role, department, competencies, and so on, and they confuse your role model and business rules. We solve this by letting the business rules determine only who needs which rights and functions based on role or roles and other attributes. If it then turns out that an unnecessary licence would otherwise be issued, we prevent that thanks to Toxic Policies.

In short, the strength of business rules is their relative simplicity. Thanks to Toxic Policies you can preserve that simplicity while still allowing for exceptions. The exception proves the rule. In HelloID we do that with Toxic Policies.

Want to know more about our Toxic Policies functionality?

You can see that by using the Toxic Policies functionality you can further professionalise your account and access management, save on licence costs, and safeguard your compliance. It is therefore an important component of your HelloID governance functionality. Would you like to know more about using the governance module in general, or specifically the Toxic Policies functionality? Then view our governance page.