Are you concerned about data leaks happening at your organization? Watch our free webinar “Preventing Data Leaks in Microsoft Teams” today!
In my last post on how to prevent data leaks, we went over the 30-60-90-day roadmap of how organizations can collaborate productively while protecting sensitive information. Now it’s time to take the next step towards securing your organization’s data.
Improving data discovery, modifying and updating your rules to follow organizational policies, and tagging documents with proper labels is just the beginning of a successful data loss prevention (DLP) roadmap. You might even have to refine your concept a few times towards the end of the 90-day roadmap, and that’s totally natural! Not all data is sensitive, and it’s not just the data itself that poses a risk; it’s the human factor that causes a violation to happen.
Organizations need to identify the information within a given document, item, or system as much as any surrounding elements for context (like what’s been done with the information itself). For instance, a typical DLP solution could probably identify sensitive documents containing credit card information within Finance department folders. However, you wouldn’t be able to determine if the information was at risk because there wouldn’t be any context. This is something AvePoint’s Compliance Guardian software excels at: being both content and context-aware.
The Good, the Bad, and the Nightmare Scenarios
Not all information is sensitive, and not all violations have the same negative impact on your organization. The three scenarios with differing risk factors if a violation is determined:
- John from Marketing shared a file via SharePoint/SharePoint Online outside of the organization.
- Mary from HR shared a file which contains less than 10 Social Security Numbers via SharePoint/SharePoint Online outside of the organization.
- Bob from the call centre shared a file that contains more than 10 Social Security Numbers via SharePoint/SharePoint Online outside of the organization.
In John’s example, we don’t know what the content is, but we do know that a file has been shared outside of the organization. This may or may not be a risk because sharing that content may fall into his day-to-day operations; nonetheless, it’s still good to be aware of these actions. We’ll label this example as having minimal risk (depending on who the information is shared with).
In Mary’s example, the risk may be moderate based on the action (external sharing) and the information (personal data is shared). She works in HR, so here we can assume (trust, but always verify) that it falls within her day-to-day operations.
In Bob’s example, the risk is quite high due to the action (external sharing), the amount of the information (more than 10 personal PII records), and how this type of information got into Bob’s hands in the first place (but that’s for another blog post coming soon).
How to Automate Risk-Based Data Loss Prevention with Compliance Guardian
AvePoint’s Compliance Guardian enables you to easily create and automate analysis of Bob’s scenario, and it all starts by creating a Context Check. In this case, we want to check if a document is shared externally. At the end of the process, we define the Likelihood (we are 100% certain of this activity) and the Severity (if a document is shared externally the impact may be minimal unless what’s inside of the document drives higher risk).
The next step is to add the check into a Test Suite (Template). Here we can finally start identifying Mary’s and Bob’s actions. We can ask Compliance Guardian to check for external sharing and documents with Social Security Numbers from right within our Test Suite. We could even add more asks in one Test Suite if we needed to identify multiple use cases or types of data in one go.
When creating the Test Suite, you can build a logic depending on multiple criteria such as:
- “If it is Bob’s use case (externally sharing more than 10 SSN records), classify this action as Extreme Risk,” or
- “If it’s Mary’s use case (externally sharing less than 10 SSN records), classify this action as Moderate Risk.”
The final step is to create a Scan Plan and automate security controls based on the risk from our examples. We select SharePoint as a source, include the Test Suite we created, and then start building our action rules as follows:
If the risk level is moderate (John’s scenario), automatically send a notification to IT and create an incident report to be audited and followed up on later. Note that in this case we are not stopping John from sharing the file, but are just being aware of who did what, where, and when.
Next is Mary’s scenario. We aren’t against Mary sharing files outside of the organization and, for this reason, we may simply want to quarantine the files and create an incident report for the potential risk. This scenario pops up often during the 30-60-90 day roadmap when deploying DLP solutions and requires you to consistently identify who is doing what within your organization. Remember that “trust but verify” is your best course of action in any breach, and having a mechanism to monitor, report, and prevent unwanted actions is better than not having one.
Finally, if we identify Bob’s scenario, we want to automate a delete action that prevents or limits the risk. Plus, we can create an incident for someone to follow up on and track via an audit trail.
The above examples are simple and effective, yet important when deploying a Data Loss Prevention solution. The benefit of Compliance Guardian is that it automates the discovery process in multiple systems where you can enable both content and context-aware action rules to protect sensitive data without blocking collaboration.
In the next blog post, we will discuss the question that every CISO or InfoSec individual may have: “How did Bob get access to the file with more than 10 social security numbers?
Request a demo and see firsthand how Compliance Guardian helps you keep thorough tabs on your organization’s data with powerful data classification and auditing tools.