Need-to-know Principle Implementation, part 4: Limitations of Security Data Filters and ACLs

[David Skowronek]

Table of Contents:

• Introduction
• Overview of ServiceNow data security capabilities
• How data security capabilities work together
• Limitations of Security Data Filters and ACLs
• Designing the need-to-know principle
• Implementation recommendations
• Practical example of implementation
• Summary and key take-aways

Limitations of Security Data Filters and ACLs

Before going deeper into the design of security solutions, it is important to understand the limitations of individual security features. Some of these features can allow partial data visibility under specific conditions, which is especially relevant when implementing a strict need-to-know model.

Deny-unless / Allow-if ACLs

Access Control rules (ACLs) are, by design, application-layer security controls. They are evaluated either:

• before a database query is executed (for example, access to a table), or
• after records are returned, to determine whether the user has permission to read or interact with a specific record.

The key limitation appears at record-level read access. Because record ACLs are evaluated per record and in the application layer, they are not applied to aggregated queries, where results are calculated directly by the database engine.

As an example, consider the User table. You may be allowed to see full details of your own user record, while all other user records are protected by ACLs. In a list view, this works as expected. However, when using an aggregated query - such as a Single-score report - you may still see how many other users match a given condition, even though you do not have access to those user records themselves. This results in partial visibility of data that is otherwise protected by ACLs.

To address this scenario, ServiceNow recently introduced two additional ACL types:

• query-match
• query-range

These ACLs allow you to restrict which attributes can be used in filters based on ACL conditions. They are effective in list views and standard filtering scenarios. However, both query-match and query-range ACLs are not applied to Single-score and similar aggregated reports. To protect such reports, you must define additional report-view ACLs.

Even with report-view ACLs, there is an important limitation: aggregated database queries themselves are still not evaluated against record-level ACL logic. This means certain Single-score reporting scenarios cannot be fully secured using ACLs alone.

There is, however, a way to address this limitation. As described later in this article, it requires combining ACLs with Security Data Filters to enforce record visibility directly at the query level.

Security Data Filters

Security Data Filters are a relatively new platform feature, introduced as a successor to Data Filtration and as a more controlled alternative to before-query Business Rules. They are, by design, database-layer security controls. When a query is executed against a table that has one or more applicable Security Data Filter rules, the underlying SQL query is automatically enhanced with additional conditions defined by those rules.

As with ACLs, there are scenarios where Security Data Filters are not fully applied. However, the limitation is less obvious than with ACLs and can result in broader data exposure if not properly understood.

Indirect query limitation

The key limitation is that Security Data Filters are not enforced in all query paths. They are designed to protect data when the protected table itself is queried or filtered. The limitation appears in indirect queries, where data from a protected table is included through a reference, but the protected table is not directly queried or filtered.

Consider the Task table as an example. You may configure a Security Data Filter that allows users to see only tasks assigned to themselves. When users query or filter the Task table directly, only the expected records are returned from the database.

However, there are related tables, such as Affected CIs (task_ci), which reference the Task table. You can create a list-type report on the Affected CIs table and include additional fields from the referenced Task records.

If such a report is executed without any filter on the Task table, the Security Data Filter on Task is not applied. As a result, the report may return Task attributes for all records referenced in the Affected CIs table. Since this table is automatically populated whenever a configuration item is linked to a task, it can contain a large number of Task references, leading to unintended data visibility.

If, however, the report includes a filter on the Task table (for example, Task type = Incident), the Security Data Filter is applied correctly, and only permitted Task records are returned.

In summary, this limitation applies when:

• data is retrieved from a table protected by Security Data Filters,
• the table is accessed only through a reference, and
• no filter or query condition is defined on the protected table itself.

Performance considerations

Another important limitation is performance impact. Security Data Filters enhance every query executed against the protected table. If the filter conditions are not designed carefully, they can significantly slow down queries and page loads.

Summary

While both ACLs and Security Data Filters have edge cases, their limitations differ in nature:

• ACL limitations appear mainly in aggregated queries. Record-level ACLs are evaluated in the application layer and therefore cannot fully protect results calculated directly in the database (for example, Single-score reports).
• Security Data Filter limitations appear mainly in indirect queries. Filters are applied at the database layer, but only when the protected table is directly queried or filtered.

For strict need-to-know implementations, this means that neither mechanism is sufficient on its own. However, combining Security Data Filters with Deny-unless ACLs provides a higher level of security, as each feature compensates for the edge cases of the other.

The following chapters provide deeper guidance on how to design and implement this layered approach effectively.

Next chapter: Designing the need-to-know principle