Addressing ServiceNow ACL Complexities with the Best Practice Engine
Updated: Mar 17, 2022
Security is always a priority
In the modern digital era, security should never be an afterthought. There are bad actors in every corner of the world and if there is anything the recent hacks and breaches have taught us, global geopolitical factors can have unknown effects on your critical system infrastructure and protection. Cybersecurity planning and protection is a necessary evil and unfortunately, one that isn't going away anytime soon. We call Security an 'evil' because it is often assumed that cybersecurity protection will slow-down innovation and prohibit progress. But it doesn't have to be that way.
In the corporate IT world, Software as a Service (SaaS) is transforming the enterprise. For every SaaS offering (ServiceNow included), security is critical. As these systems grow larger and more complex, even just configuring effective security measures becomes a formidable challenge. Professionals who have years of experience are bound to let a few issues through the cracks.
ServiceNow and Security
Let's take a look at one recent example. ServiceNow aligns itself with the principle of least privilege, meaning that a user should be given the lowest number of permissions needed to fulfill their duties. ServiceNow’s security model uses a combination of Role-Based Access Controls (RBAC) and Access Controls (ACL) to enforce authorization to data.
Access Control (ACL) - Rules that restrict access to data by requiring users to pass a set of requirements before they can interact with it.
Role-Based Access Controls (RBAC) - ACLs that are organized based on specific roles.
According to a AppOmni**, nearly “70% of (tested) ServiceNow instances had ACL misconfigurations” related to over-assigning permissions to external or guest users. User roles are evaluated against ACLs to ensure that the proper criteria are met before granting access. ACLs operate on a two-gate system*. First user permissions are verified for field-level access, then table-level access. The checks performed by ACLs operate on a scale of very specific (table name.field name) to general (any table.any field). Finally, all ACLs specify the object/operation being secured and the permissions needed to access that object.
These misconfigurations usually occur during the initial implementation phase of the software, or even during regular updates. Due to how intricate and flexible SaaS platforms like ServiceNow can be, the solution isn’t as simple as adjusting a few property settings. Systems must be monitored continuously to ensure that they are implemented and updated free of misconfigurations. Additionally, permission settings related to external users are of the utmost importance. The question remains, how does a company continually ensure that the right users are getting the right access at the right time?
Best Practice Engine tackles Access Control Oversight
To answer the question above, an organization simply can’t – or at least it is becoming more and more difficult to do. That’s where the Best Practice Engine (BPE) comes in. BPE addresses the challenge of continuous monitoring with its nightly instance scans, reducing the burden of the team managing their platform’s security. If any violations do occur, BPE empowers the platform team with the steps to resolve the issue.
For example, one of the main issues we see is that users, especially external users, have access to information they are unauthorized to have. The Best Practice Engine can help. BPE has several rules built in to counter against this including 'UI Pages should have an associated read ACL', 'ACLs should be enabled for Live Profile Details', 'AJAXGlideRecord ACL Checking should be enabled', and more.
Another issue with ServiceNow ACLs is that they can be very complex depending on the size of your instance and the information you have. And with how flexible ServiceNow is, just starting is an issue. BPE has a rule in place that enables the user to get a jump start to setting up security. 'Access control should be enforced' outlines that the user should activate the Security Jump Start (ACL rules) plugin. The Security Jump Start plugin has to be activated to achieve Security compliance. It creates some basic ACLs automatically that secure system tables instead of creating then manually for each system table that comes with a fresh instance. This is helpful when the newly created instance needs to quickly move into production.
How can the Best Practice Engine help?
BPE reigns in the complexity and flexibility that come with security access on ServiceNow by providing specific Best Practice Definitions designed to flag violations when configuring ACLs. BPE Customers also have the flexibility to create ACL definitions (or any definition) that meet their own business requirements! Customers can sleep better at night knowing BPE is always on, always scanning for issues that may but undetected in their instance.
From the vast library of definitions BPE offers, 93 are security related and 13 definitions are specifically related to ACLs. Several of the definitions are specifically related to prohibiting user access to data they either don’t need or shouldn’t have. BPE is ensuring the right users are getting the right data – and the wrong users aren’t getting the wrong data. Entrusting BPE to strengthen your security posture is a significant step in augmenting the inherent complexities that come along with a ServiceNow enterprise implementation. Sources