Overview
Back in 2023 I talked about the “Data Filtration” plugin, but ServiceNow have decided to retire it in favour of Security Data Filters, which come enabled by default in new instances. These will allow you to filter data depending on the circumstances.
Context and real-life usage
In this article we will talk about hiding admin accounts for regular users, but this feature is especially useful for hiding sensitive data on tables that need to be consumed by automated accounts (i.e: integrations). I will talk about a real-life scenario to help you understand how this could be efficiently leveraged.
Not so long ago I was asked to allow an integration account read from the Assessment-related tables (surveys sent by end-users). This table contains feedback from all sorts of tasks including ITSM, HR, SecOps or Customer related. This means if an ITSM integration would require to read from there, they could read feedback from other departments, potentially leaking sensitive information. For example, someone could write information on an HR Case that could help someone understand what happened. If we allowed the ITSM integration account to read all assessment-related tables, any malicious user might derive what happened on the HR Case, putting at risk their confidentiality.
We could start building ACLs or query Business rules for this purpose, but it’s less efficient and can drive our instance towards a massive maintenance debt due to its complexity. Security Data Filters add an extra layer of filtration that can remove rows from the results in a cleaner way than query Business Rules and that won’t overlap or collide with other ACLs.
Defining the use case of this article
Admin accounts are displayed Out of the box to any user who has access to the backend. For instance, if an ITIL user went to the “User” table, they’d see the System Administrator:
Let’s say we want to hide all admin accounts from anyone who’s not an admin to increase security in our instance. In this article we will see how to do that.
Knowing about Security Data Filters
First of all, we need to remember that this feature, as far as I can see in the several instances I have access to, comes enabled by default and can be found under “System Security” as shown below:
This is the lit of OOB Security Data Filters:
Even though we can see them, we cannot edit or create them unless we elevate privileges by making use of our “security_admin” role. In case you still don’t know how to do so, here’s how:
Once we act as a security_admin, let’s create a new “Security Data Filter” by clicking on the “New” button we can see now on the list:
This is how the form looks like OOB. We need to highlight a few things. First of all, we can enable or disable a “Security Data Filter” by clicking on “Active”. There’s a flag called “Show in UI” which will display an info message telling the user data has been filtered. We will see at the end how the message looks like.
Given there’s no “Short Description” we should enter a long-enough Description not to create a filter nobody knows what it is for.
Then the “Mode” field has two options:
- Filter unless security attribute condition met
- If the condition set below the mode applies to the record, then it will hide everything except for the records that meet the criteria
- Filter if security attribute condition met
- If the condition set below the mode applies to the record, then it will hide all records that meet the criteria
In this case, we want to hide all admin accounts, so we will select the second option and will define a condition as follows:
“Name does not contain admin”
Think of this as an extra “WHERE” condition on the SQL query, as this is what ServiceNow does underneath according to the official documentation. So in this case we append “WHERE name NOT LIKE '%admin%'”.
Last but not least, we need to specify who will have this Security Data Filter applied. There is a list of Security Attributes Condition that come OOB we can choose from. The options everyone should know about are the following:
- Always
- Everyone will have it applied
- Never
- Nobody will have it applied. It makes no sense for Security Data Filters, but bear in mind that Security Attributes are used across several features.
- HasMaintRole
- Users who have the “maint” (maintenance) role will have it applied. This translates into ServiceNow employees
- HasAdminRole
- Users who have the “admin” role
- UserIsAuthenticated
- Any user who has logged in
If there’s no Security Attribute Condition we can leverage, we can still create our own. In this case, we need one that specifies that the user doesn’t have admin, instead of “HasAdminRole”. We will, therefore, create a new one called “DoesNotHaveAdminRole”. For that, we need to click on the magnifying glass and click on “New”:
Then we need to select the “Type” to be “compound” and enter in the “Condition” field “Role is not admin” as shown below:
This means if the user visiting the list does not have the “admin” role, this attribute will apply.
Now that it’s created we need to select it in the Security Data Filter we were creating:
Testing the results
Given we are using our “admin” account, this filter will not apply to us, so we need to impersonate a non-admin user, such as the “ITIL User” for instance:
Now we visit the Users table and try to find any user whose name contains “admin”. As shown below we are unable to see any admin account.
Finally, before we mentioned the “Show in UI” checkbox but said we’d show the result at the end. Here’s how the message looks like if the checkbox is enabled. This is to warn users rows may have been removed. Unlike ACLs, it doesn’t say how many rows were removed, so there’s no risk of leaking sensitive information as it used to happen before the “query_range”-type ACL.
Please like 👍 and share 🌍 this article to your colleagues if you found it useful.
