Toxic Policies
What are Toxic Policies?
HelloID supports your identity governance with capabilities such as Toxic Policies. This prevents granting access rights to someone who already holds conflicting rights. It helps ensure that costly, redundant licenses are not issued. It also supports fraud prevention and reduces other unwanted behaviors by preventing people from quietly accumulating excessive rights.
Rationale for our Toxic Policies Functionality
The rationale for the Toxic Policies functionality is that HelloID uses Role-Based Access Control (RBAC) to issue and manage accounts and access rights. The basic principle is that a person’s role in the organization determines which accounts and access rights they need. We intentionally use an advanced approach in HelloID. Instead of a rigid framework in which all rights are defined per role, we use so-called business rules. These are manageable rules that, for example, in a healthcare organization, allow us to easily define that anyone with the job title 'Care Assistant level 4' is granted access to the Electronic Client Record.
The advantage is that your administrators can work with understandable policy rules without having to delve into the underlying technical structure of roles, attributes, and rights. You also do not need to link every access right to individual roles. You can simply configure your company to assign a Microsoft 365 account to everyone, regardless of their role. Many rights also apply to all employees within a particular department or location. In practice, there are usually only a limited number of rights that must be defined as truly role-specific. In a traditional RBAC model, every right must be linked to roles, which quickly leads to a role explosion and makes maintenance complex. 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 pyramid of rights.
There is an important consideration. Multiple business rules can apply to each individual employee in practice. We already provided an example of a business rule requiring every employee to receive a Microsoft 365 license. As a member of a specific department, you can also receive access to the departmental file share, which is an additional business rule. Depending on a person’s role (s) in the organization, additional rules may apply to grant the corresponding access rights. While each individual business rule is correct on its own, combinations of rules can sometimes create duplicates or contradictions. You want to prevent that; the Toxic Policies functionality is the ideal tool.
Examples of Toxic Policies
Let us make this concrete with two examples. In the first example, two conflicting business rules result in unnecessary licenses being issued. In the second example, the business rules grant conflicting access rights:
Example 1: Microsoft offers various Enterprise licenses such as E1 and E3. An E3 license provides additional capabilities than an E1 license. By default, everyone in the organization receives an E1 license (business rule 1); however, employees in specific roles must receive an E3 license (business rule 2). The business rules are correct on their own, but some employees therefore receive both an E1 and an E3 license, which is needlessly expensive.
Example 2: In an organization, there is a function to enter invoices and a function to approve them. If a rule grants someone the ability to enter invoices, that same employee must not also be able to approve them. If that happens accidentally because someone received both roles, that combination of business rules violates the separation of roles in your organization.
The Toxic Policies functionality helps prevent such unwanted combinations, reduces costs, and limits the risk of fraud.
How Do We Manage Toxic Rules in HelloID?
We will demonstrate how this works in the HelloID Provisioning module, where we apply such business rules. Consider the example with E1 and E3 licenses where everyone in the organization receives an E1 license by default, but IT staff must receive an E3 license:
Without the Toxic Policies functionality, when we evaluate issued licenses against the business rules, we see that everyone received an E1 license, and IT staff also received an E3 license. That is an expensive duplication.
You can now activate the Toxic Policies functionality and configure a new toxic combination. In it, you state that if someone is granted rights to both an E1 and an E3 license, only the E3 license must be assigned.
After you activate that toxic combination, all users who previously would have been assigned both licenses will now be assigned only an E3 license. You will also see, for the relevant users, a notification that a right has been denied, namely the E1 license.
Those settings are also enforced in the target systems. If the conflicting rights were granted earlier, the redundant E1 licenses will be revoked upon activation of this toxic combination.
Support for Your Compliance
The example above prevents unnecessary licensing costs, and you can also use the Toxic Policies functionality to support Separation of Duties within your organization.
Separation of duties is important in organizational policy and is required by many information security standards. The BIO (Baseline Information Security for Government) states that conflicting tasks and responsibilities must be segregated to reduce the likelihood of unauthorized or unintended modification or misuse of the organization’s assets. We already mentioned the example of an employee who issues invoices and, therefore, must not be allowed to approve them.
This role separation is often determined at a higher level in the organization and translated into employee-level functions, which are recorded in the HR system, for example. The IAM platform ensures that everyone receives the appropriate permissions based on their role and other attributes, such as department and location. Your IAM environment is therefore ideally suited to implement or enforce the last details of this role separation. You do this by configuring toxic combinations that apply the correct resolution to unwanted combinations; in the earlier example, a toxic combination includes the right to create invoices versus the right to approve invoices.
With the HelloID Provisioning module, we can automatically grant access rights based on attributes such as a person’s role, competencies, department, and workplace. With the Toxic Policies functionality, we can prevent an individual user from being granted excessive rights.
Use Toxic Policies or just business rules?
Why use the Toxic Policies functionality at all? Our business rules can also be configured with high flexibility. Could we not achieve the same outcome by further detailing our business rules with additional conditions? Sometimes that is possible, but it undermines the strength of the business rule concept. You want to keep your business rules as clear and simple as possible, and avoid making them unnecessarily complex with many exceptions. The Toxic Policies functionality is a perfect addition because it enables you to identify and resolve such exceptions easily.
We will illustrate this again using the Microsoft license example. For the E1 and E3 licenses, the issue is the specifics of Microsoft licensing. An E3 license is a superset of E1; if you have an E3 license, you do not need an E1 license. With another vendor that works differently, two licenses might be complementary, even if you need both. These licensing details have nothing to do with a person’s role, department, or competencies, and they complicate your role model and business rules. We solve this by letting the business rules determine only who needs which rights and functions, based on roles, role assignments, and other attributes. If it then turns out that a redundant license would be issued, Toxic Policies prevents it.
In short, the power of business rules is their relative simplicity. Thanks to Toxic Policies, you can preserve that simplicity while still allowing room for exceptions. The exception proves the rule. In HelloID, we do this with Toxic Policies.
Want to Learn More About Our Toxic Policies Functionality?
You can use the Toxic Policies functionality to professionalize account and access management, reduce licensing costs, and enforce compliance. It is therefore an important part of your HelloID governance capabilities. Do you want to learn more about the governance module in general, or about the Toxic Policies functionality specifically? Then, view our webinar or our governance page.