Best practices for creating ACL

[Ashwini Suryava]

To configure security measures that are effective, easily maintained, and scalable , ServiceNow utilizes access control list (ACL) rules to control what data users can access and how they can access it. Most ACL rules restrict or grant access by user role. Users who pass the user role requirement of an ACL rule gain access to the protected object, such as a table, field, or database operation.

What is ACL ? 

Access control rules, also known as access control lists (ACL) or access controls, restrict access to data by requiring users to pass a set of requirements before they can interact with it.

All access control rules specify:

• The object and operation being secured
• The permissions required to access the object

Objects

Each object consists of a type and name that uniquely identifies a particular table, field, or record.

Operation

Each operation describes a valid action the system can take on the specified object. Some objects such as records support multiple operations, while other objects such as a REST_Endpoint only support one operation.

Permissions

The permissions specify when someone can access the named object and operation. Security administrators can specify permission requirements by adding:

• One or more user roles to the Requires role list.
• One or more conditions.
• A script that evaluates to true or false or sets the answer variable to true or false.

To gain access to an object and operation, a user must pass all permissions listed in an access control. For example, this access control restricts access to write operations on the incident table.

Assign Roles by Group

User roles can be assigned to both groups and users. Every user in a group inherits the group's user roles. Similarly, some roles also contain other roles. The preferred method of assigning roles to users is to add users to groups that have been assigned the desired roles. 

Note : Use ACL debugging to help diagnose issues regarding security and access control rules.

Know When to Use Client-Side Security

If field security needs to change as a form is being filled out, use UI policies and client scripts, which are evaluated and run on the client, that is, the browser. For example, when a support engineer changes the incident state to resolved or closed, one or more fields change from editable to read-only to prevent additional changes.

Note: Client-side security with UI policies and client scripts is not as secure as server-side security. Most modern browsers allow users to change attributes of the data sent to the client, including read-only or hidden fields.

Use Data Policy to Enforce Data Consistency

Data policies increase the security of UI policies by ensuring that data meets certain requirements regardless of whether the data comes from the UI form or another source, such as a web service, import set, or incoming mail. For example, use a data policy to ensure that incident records always have a short description and category even when the data comes from an integration. Data policies also prevent users from bypassing client-side policies.

Using an ACL Rule-Based Security Model

ServiceNow uses a "default deny" security model that prevents non-administrator users from accessing objects unless they meet a matching ACL rule. This removes many attack vectors, such as insecure scripts. Use caution when changing the security model to assure that proper settings are enabled to secure your instance.

Ensure that High Security Settings is Activated

The High Security Settings plugin delivers a variety of settings and features to increase the security of your ServiceNow platform. High Security Settings automatically activates the Contextual Security plugin if it is not already active. 

Check the property glide.sm.default_mode to ensure it is set to deny. This directs the wildcard ACL to restrict access unless access is granted by another ACL. If this property is set to allow then access is open and the High Security Settings plugin is not as effective as it is meant to be.

Ensure that Contextual Security is Activated

The contextual security manager provides incredible flexibility and power to protect information by controlling read/write/create/delete authorization. Key advantages include:

• Contextual Security -- Secure a record based on its contents
• Hierarchical Security -- Can apply security rules to any level in our object hierarchy

Points before creating a New ACL

1. Search for all the ACL's for that particular table you want to create on and categories them for row level, field level types, never duplicate any ACL conditions which may cause error later stages.

2. Use scripting if there is a similar ACL available, say your table and field with the role is already available, you can edit it instead of creating a new one.

3. You can also verify the base table (say check for task ACLs before writing a new ACL at incident level) and check for parent child relation at ACL level.

4.Creating a new ACL will be easy for a new table but not for the existing ones. Recheck contradicting ACLs if any found, debug before going ahead.

Thanks & Regards,

Ashwini