BY Niall Rooney | 27 July 2018
The amount of data used and stored within your organization is growing at an exponential rate; it’s the nature of data. However, along with the growth of that data, comes the added responsibility of identifying and securing sensitive information that is stored within your organization, whether it is in a structured or unstructured format.
Sensitive data in today’s world includes Cardholder data, Personally Identifiable Information, Financial Information, and Health information. We are also seeing the evolution of sensitive information to include location data, genetic and biometric data too.
This is all well and good, but what happens when there is information within your data that appears to be sensitive information, but actually isn’t? How do you differentiate between what is legitimate sensitive information and what is data that may be masquerading as sensitive data?
This is where I will introduce the term ‘False Positive’, which can be defined (by Google dictionary) as follows:
noun: false positive; plural noun: false positives
When discovering sensitive data within your organization’s structured and unstructured information repositories, there is always a possibility that data may incorrectly match types of data you are searching for.
After all, strings of numbers and characters appear throughout computer systems and the combinations of these all have the potential to match sensitive data formats. One can also often encounter seemingly legitimate matches that are actually a False Positive in the context for which you are searching.
If we look a little deeper into this issue, we can also see that different numbers and concentrations of False Positives can occur according to the target data repository you are scanning, along with locations within the specific repositories.
For example, you may find differences in False Positives across your workstations, servers or user mailboxes within your environment. Furthermore, you may discover False Positives in a file location within a workstation, such as the applications directory, whereas you may see False Positives appearing in the email signatures within emails in your user mailboxes.
The above examples are just a small sample of where False Positives can be identified when performing a forensic search for sensitive data within your organization. This sample multiplied across many systems and locations housing your data can adversely affect your ability to discern the actual sensitive data which you are trying to identify, from the False Positives within your target data repositories.
So, how do you address this and ensure you don’t spend your valuable time combing through large numbers of False Positives to get to the real sensitive data?
Author: Simon Davey
Share this article!
Want to keep up with all our blog posts? Subscribe to our newsletter!
As companies all around the world continue have large portions of their workforce remote, the need to keep their data safe and protected is even more critical. To help companies navigate this new reality and mitigate security risks, we are providing a 90-day complimentary version of our flagship solution—Enterprise Recon. Learn more about it here.
Please submit the form below and we’ll contact you to schedule a discovery call. Want to skip the email? Go here to schedule a meeting directly on our calendar.