Deny-unless and Allow-if ACLs in ServiceNow

Introduction

In recent releases, some key updates have been made to ACLs that you may not be aware of. Fundamentally, ACLs are now broken down into two 'types', the first being Deny-Unless, the second being Allow-If. On the surface, these two terms sound pretty similar in plain English. It stands to reason that allowing someone if they have access to something is the same as denying someone is they do not. However, we need to view these terms in through the context of the ServiceNow Platform.

We now define the who can access a resource with Allow-If ACLs. Furthermore, Deny-Unless ACLs now takes care of the scenario of denying access to the resource. These Deny-unless ACLs are evaluated FIRST and act as the first line of defence for your resource that is being requested. If the conditions on the Deny-unless ACL are not passed, access is NOT granted. The ACL defines the users that will NOT be denied. If they are passed, then the Allow-If ACLs are evaluated and your level of access to the resource is determined.

Let's dive into this further.

NOTE: Whilst there are some additional complexities and considerations at play when it comes to implementation, this article focuses on a higher level overview.

The inspiration for this article came from completing ServiceNow Deltas and coming across an excellent video from Jason Nichols on the Secretary of Simplification YouTube channel. Please check it out: https://www.youtube.com/watch?v=Zl1DyGSLkTQ

Allowing Access

Let's turn to the consultants favourite tool, the analogy. Let's use a building as an example, a government building perhaps. In our analogy, the building is the ServiceNow Platform. By default, no one has access to this building unless they have a pass to get in. This is covered by authentication. Once we are in the building, we need a series of Allow-If ACLs to help determine where we will have access to within the building. Within this building there may be different roles, with different security requirements and we need to create policies in order to enforce that. With that in mind, in our analogy, based on your job function, you may have access to the West Wing (sensitive data) or the building, and/or the East Wing (personal sensitive data) of the building. To achieve this, we created TWO Allow-If ACLs. One to grant access to the East Wing, one for access to the West Wing.

Let's do a quick check in, for Allow-If ACLs we have the following:

• We have created an Allow-If policy for personal data access in the East Wing of the building
• We have created an Allow-If policy for sensitive data access the West Wing of the building

At this stage we are keeping things relatively simple. Despite this, know that the implication of there being areas that require security access means that there are probably other variables and considerations at play too. This means right now we are missing another piece of the puzzle. But for now, let's assume that there are policies in place to deny access to areas that people shouldn't, we'll dive into them next.

If we put all of this together, we can start to visualise granting our granular access to our building below.

Additionally, what we are doing here is essentially adding a another Allow-If ACL to the Non-restricted areas, and we will need "something else" to safeguard the Restricted access areas.

Let's do another quick check in, for Allow-If ACLs we have the following:

• We have created an Allow-If policy for personal data access in the East Wing of the building
• We have created an Allow-If policy for sensitive data access the West Wing of the building
• (Optional) We have created an Allow-If policy for access to Non restricted areas

Denying Access

So far, we have established the rules for accessing the areas within our government building. But there is one key component of our model that we have not yet accounted for, controlling the denial of access to areas of the building. We need to deny people, if they are not permitted, from entering certain areas. In the context of our building, that means that although we have defined Allow-If ACLs for access to specific restricted areas like the East and West Wing, there is nothing currently explicitly denying people from accessing where those Restricted Areas are in the first place. To improve our security posture, we need to fix that.

Historically, only Allow-If ACLs were available (they were just "ACLs" back then, with no distinction), and to accommodate denying access to the building a criteria would need to be added onto each Allow-If ACL, because Deny-unless ACLs didn't exist!

Imagine you have more than just an East Wing and West Wing to your building, imagine we restricted by floors and rooms too, it all starts to get pretty messy. So instead of updating many Allow-If ACLs, we can simply create one Deny-Unless ACLs to ensure only the people we want have access. The Deny-Unless ACL is like our security checkpoint.

The Deny-Unless ACL represents us allowing access in our building to where those Restricted Areas are. However, the Deny-Unless ACL itself does NOT grant access to any specific restricted areas like the East or West Wing. This is because the default model for the ServiceNow Platform is to deny access to resources until granted. Although we passed the 'initial' check to be in the right place (Restricted Areas), we are by default being denied access to the East and West Wings. Our Allow-If ACLs are the things that are going to grant that access. So we can see here how these two are working together, to enforce our building policies.

Let's do another check in, for our ACLs we have the following:

• We have created an Allow-If policy for personal data access in the East Wing of the building
• We have created an Allow-If policy for sensitive data access the West Wing of the building
• (Optional) We have created an Allow-If policy for access to Non restricted areas
• We have created a Deny-Unless policy for access to Restricted Areas within the building

In line with our previous visualisation, this is how our picture now looks.

You will also notice in the above that an additional Room level security policy was added. This is here to illustrate that even after we have granted access to a resource, within that resource there still may be additional policies in place to wholesale deny access to specific elements within the resource.

For those with a more technical mind, at this stage, instead of using the Building analogy you could replace the following with ServiceNow terms:

• The Building is an Application, or the Platform
• Non restricted areas is a table
• Restricted Areas is a Parent Table
• East and West Wings are Child Tables of the Restricted Areas Table
• Room #403 is a record within the East Wing Table

Wrapping It Up

Let's put all of this together to see where we ended up.

To meet our requirements for our building and its areas, we created the following ACLs in ServiceNow:

• We have created an Allow-If policy for personal data access in the East Wing of the building
• We have created an Allow-If policy for sensitive data access the West Wing of the building
• (Optional) We have created an Allow-If policy for access to Non restricted areas
• We have created a Deny-Unless policy for access to Restricted Areas within the building
• (Optional) We have created a Deny-Unless policy for access to Room #403 within the East Wing of the building

Whilst our example might be relatively trivial and non-complex, it helps highlight the key differences between Deny-Unless and Allow-If ACLs, and the use case for each. If your instance has been around for some time, you may have achieved the task of 'denying' access to a resource with complex scripted ACLs, a negative condition in each ACL, scripted query business rules, or some other method. If you fall into this category, it may be time to take stock of your configurations and identify the opportunities the new ACL updates may provide to eliminate a lot of technical debt.