Why "Data Classification" is paramount on how to use it

[Dan Martinez]

Overview

In any organisation data architects need to be able to report on classification given to fields in ServiceNow. This helps control how data can be handled, who can access it and what can we do with it. Not only your organisation's policies need this classification to be done, but also regulation requires it (GDPR in the EU or the CCPA in the US are good examples of this).

In this article, I will do an introduction to the the out of the box “Data Classification“ product to cover the important bits and pieces.

Classifying data

Before tracking any classification, we need to determine the different types of Data Classifications we have within our organisation. For this, we need to go to “System Security > Data Classification > Data Classes”:

Then we will see the out of the box Data Classes we have. Bear in mind this list will vary depending on the plugins installed. The options I see may, or may not be the same you see:

In my case, I have the following structure:

• Restricted:
  • Highest level of confidentiality. If this data was released publicly, it would cause a massive negative impact for the organisation. This data is typically only accessed by a reduced number of people.
• Confidential:
  • Sensitive data that not every employee should have access to as it may cause issues. (i.e:  Salaries, hiring information, firing procedures,…)
    • Personal Identifiable Information (also known as PII):
      • A special type of confidential data that would allow someone to identify an individual based on it (i.e: Social security number, Passport number, …)
    • Internal:
      • Relatively sensitive data that needs to be kept internal to the organisation. All employees should be able to access this data. (i.e: Monthly bulletin sent via email)
    • Public:
      • Data anyone can find elsewhere that is not secret at all and can be freely shared with any individual

If we access the Personal Identifiable Information record we see the following:

Under “Data Classifications” we will see any child categories. Given there’s no child Data Classification under PII this list comes empty, but in the case of “Confidential” we would see “Personal Identifiable Information”. This related list allows us to represent a Data Classification hierarchy.

Then there’s another tab called “Classified Dictionary Entries” where the fields classified this way (in this case, as PII) are shown.

We can see in the list below that 14 fields have been flagged as PII. Some examples are “email”, “street” or “mobile_phone”:

Now you may have realised there’s a link just above these tabs that says “Classify Dictionary Entries”. This link will direct you to the Dictionary to be able to classify fields as you need:

Classifying fields

To demonstrate how to classify fields, let’s create a new field and flag it the right way. In this example I will create a new field called “Secret” on the Incident table the same way I did in my previous article about Field Level Encryption.

For the sake of the example, let’s imagine this field will contain a secret code users have to share with us when the incident is registered. We should be encrypting it following the instructions in the article above, but that will not be covered here given it’s already there. After encrypting it, we will be classifying it as “Confidential” given only the user and the “itil” agents need to have access to this “Secret” field.

Here is how I have created it:

Now, we could either go to the Data Classification called “Confidential” and then follow the link mentioned before called “Classify Dictionary Entries” or we could simply stay in the dictionary list. In any case, we land on the same place. Given that we are already in the dictionary list, let’s stay there.

We now have to find our recently created field and select it on the list:

Then at the top-right corner we click on the actions available and select “Classify”:

This will show us a pop-up window where we can select one or more classifications. In our example, we select “Confidential” as follows:

After doing this, the field is now classified as “Confidential”, although it’s seen nowhere in the list. Also, bear in mind that if we click on “Classify” again, we will not see the selections we previously did. For instance, if I click again, I would probably expect to see “Confidential” as that’s what I have just selected but this is what I see:

Clearing the classifications

If for any reason you classified it the wrong way or the field changed its purpose and it’s no longer classified the old way, you should then select “Clear classification” in the list action drop-down menu we saw before:

Then clicking on “Clear” on the pop-up shown will clear all classifications. This means if you had several and want to remove one, you will remove them all and will have to reclassify it again with the data classifications you would like to keep:

Reporting on the data classifications

Now that we have our fields properly classified, we can report on them. Let’s go to “System Security > Data Classification > Overview” this time to see the dashboard that comes out of the box:

In here, under the default tab called “Tables and Columns” we can see the classified columns and how they were classified. Also, the “User reference columns”, or references from any table that points to the “sys_user” table, the “Total tables” that exist in the instance and the number of “Total columns”, also known as fields.

If we click now on “Confidential” we will see the field we have just classified as such plus two fields that were classified the same way:

 

On the second tab, though, we find a list of users by location, the number of total users in the sys_user table (“User count”) and the “User location count” which defines how many “Locations” users are related to.

Feedback

Please like 👍 and share 🌍 this article to your colleagues if you found it useful.