Learn how to keep your data secure with our webinar “Preventing Data Leaks in Microsoft Teams (and Other Collaboration Systems).” Watch here!
In the last post, we discussed how to create and test a scan policy in Compliance Guardian. As you start testing and analyzing your scan policy results, however, you might want to make some adjustments to how the scan policy works and improve the results you’re interested in.
A common example is the amount of sensitive information identified; one credit card number in a document or an email may be allowed, but ten or more instances is a red flag that you’d need to know about to investigate and prevent.
There could be situations where an employee exports an XML or CSV report containing large amounts of credit card details (perhaps from your payroll applications) and has to share or email the same file to a third party outside of your organization. The risk here is that if information isn’t properly secured, you can either lose control or have to depend on someone else to take proper care of that very same information.
From Compliance Guardian’s Scan Manager, you can identify sensitive information based on more than one criterion for sensitive information, regulatory standard or intellectual property by adding additional Templates/Test Suites.
You can also specify exact locations where you’d like your scan policy to take effect. This is useful if you’d like to test your scan policy on a smaller subset of information but also target specific use cases or locations rather than scanning the whole system.
When creating a scan policy for Exchange or Exchange Online, you’re able to select or exclude certain mailboxes from being scanned. This could come in handy when there are regulatory requirements or company agreements that must be honored.
Additionally, you can decide whether to solely scan the content of a file or the surrounding metadata as well. Scanning for metadata is useful for more advanced use cases such as when a user might want to check who the owner of a file is, when the file was created, what type of file it is, whether it contains sensitive information or not, and so on.
Microsoft Teams also has similar options where you can select whether your scan policy applies to some or all users.
Note: Some sources like SharePoint and SharePoint Online have a handy versioning functionality that can come in handy in certain situations. For instance, if a file contains sensitive information in the first version of the document and then someone deletes or removes it, versioning prevents that data from disappearing completely. It’ll still be there with the option to scan the full document history.
Action Rules
When working with the Action Rules, you can change:
- The condition of how your actions and rules are enforced
- Conditions can be based on the risk value, the item or document properties, and the sensitive information template.
- Whether all (AND) or any (OR) of the condition criteria must match our rules
- Sub-rules which grant you extra flexibility in building more advanced use cases or conditions by which your actions can be enforced.
With every rule we can automate actions to be applied and, depending on the system, there are a variety of actions you can choose from. In some instances you can chose more than one action as long as the order they’re in doesn’t conflict with others; you can change permissions and delete the file, but you can’t delete the file and then change the permissions.
In my example with SharePoint/SharePoint Online, I’ve chosen to change the permissions on a file that matches our criteria.
With every action you choose to apply, there’re additional options you can use to enhance the overall experience when working on your data protection or deciding to involve end users in a remediation process.
In my example, I’ve chosen to only keep permissions active for a specific group. I can send an alert to the person who created or last modified a document as well as specific users based on a scope that can be quite useful if you want to send specific alerts to specific Active Directory users or SharePoint groups. Additionally, Compliance Guardian has built-in users and groups with which you can associate such alerts.
While alerts are nice to have and you can customize the built-in email templates, I’ve selected the option to start an incident that will create a record and a task within Compliance Guardian for someone to later review and make further decisions on.
The incident also sends an alert and is very useful for accountability and reporting purposes. Not only have we have discovered sensitive information and protected it by changing the permissions in our example, but we can also assign a follow-up as an incident.
The above is functionality you can edit and configure from a Scan Plan, but there are other useful possibilities that can be changed from within the checks and test suites (templates), such as:
- High or low volume of content detected
- Built-in or Pointer Record classification
- Risk level
- Eliminate results such as false positives before they’re even reported in the system as a match
To see how it works, we can do this from the Test Suite Manager:
In my example, I have a check and template that we use to identify documents whether they are invoices or not with a dollar value amount. We all know that documents with high dollar values must be about something very interesting or sensitive, and from the test suite we can change or configure:
- One or multiple conditions with an option for a parent-child or sub-group of conditions
- The amount of content detected. If we find one instance of a dollar value amount in a document that might be ok since it could be my salary but if there are 100s then it could be a different story
- The result, which serves as an internal or pointer record classification you can later use for reporting or other purposes from within the product itself.
- Your checks or patterns before you even deploy your scan plan. This is very useful to try out several matches or patterns and use the opportunity and tweak your checks or expectations.
Testing before deployment allows you to see how information is being discovered. You can try it out on different file types such as images (yes, we support OCR), PDFs, and other formats. This option allows you to go back and tweak the checks and patterns you’re using to identify information, and you can combine multiple checks at the same time during your test.
Investigating False Positives
Another method we can use to improve accuracy or even false positives is excluding results that match certain criteria. Let’s say we’re interested in invoices that have more than $100k as a dollar value, but we’re not interested in purchase orders (which could be similar document types).
One way to respond to situations like these is to use the dictionary check in Compliance Guardian which allows you to set these requirements and filter out content that matches certain text or even a pattern identified by a regular expression.
From the built-in Incident Management Center in Compliance Guardian, we have the possibility to see all Scan Records and Incidents that end users can access, and if an incident is assigned to them, they have the option to:
- Resolve
- Dismiss
- Escalate
- Reopen
- Take an action such as changing the classification of the document or some of its properties
- Mark it as a false positive
Once the file is marked as a false positive, it won’t be scanned until the file or the test suite is changed or updated.
Summary
Scan policies for data discovery, classification, or protection are useful to any organization, and testing your setup or scan policies is a very low-risk activity that informs you if any actions need to be applied. You can quietly test your scan policy in Compliance Guardian as a Test Run or, from a more granular level, test your checks or patterns or even expectations from the Test Suite itself. Finally, narrowing your scope to encompass a smaller audience and fewer locations can play a major role in helping false positives become a thing of the past.
