Blocking Time Sensitive Materials from Public Exposure
By: Stevan Pierce and Jose Ramirez
Netskope DLP technologies are typically known to be used for blocking a variety of materials such as Intellectual Property, databases containing employee or customer data, hashes of data to be used in Exact Data Matching, etc, etc.
Netskope is also able to provide protection of time sensitive materials from public exposure and allow for the dissemination of the material internally. A prime use case would be blocking the ability of employees to share information about a company acquisition; and, at the same time, allow those employees to talk amongst themselves using company resources such as those which are sanctioned, i.e. Slack or Google GMail.
The example we are using to showcase this capability of time sensitive material controls is the release of an article on Forbes, Netskope – Security Transformation For Digital Transformation.
In addition to meeting the use case above, Netskope partners provide additional protection such as Mimecast restricting outbound emails.
In this paper, we will explore what it looks like to block time sensitive information from public exposure using Real-time DLP policies for CASB applications, API-enabled Protection for SaaS applications, and augmenting these services with Mimecast.
We are blocking time sensitive materials from public exposure. In order to do this, we will create Real-time Protection DLP policies for sanctioned CASB applications and general CASB categories using the following requirements:
In addition to Real-time Protection policies, we are going to further secure and restrict activities using API Data Protection policies using the following requirements:
These rules are crafted to protect the enterprise and guide persons to use officially approved applications which the organization has signed off on: Google GMail; Slack; and Microsoft Office 365. Mimecast will be used in conjunction with Netskope to provide an additional level of security.
In order to block time sensitive materials from public exposure, we have to know what we are working with. With this in mind, we need to create a DLP rule, a profile encompassing the rule, and subsequent policies.
We need to choose keywords or phrases in the article to help differentiate it from other traffic and use those in a DLP rule. The keywords or phrases below will be defined as data identifiers and named as is, except the last phrase will be called Skate and Puck:
The data identifiers will be similar to the following and will be case insensitive to avoid a capitalization issue which allows for exfiltration.
We need to add these data identifiers to a DLP rule and select a keyword or phrase to be found at the beginning of the article, known as a global data identifier. Only content will be scanned.
Since we are only scanning the article and not scanning for exfiltration of employee data, we are only looking at one (1) record.
For simplicity’s sake, this will be the “Forbes Article” in a DLP profile with the same name.
Similar to a firewall, Real-time protection policies are processed from the top down. After the first match, the rest of the policies are not processed.
With this policy, we are allowing and alerting on activities between Netskope employees using constraints when detecting movement of the Forbes article. The alerts to be seen in SkopeIT Alert Events only and not user visible.
We do not want to allow any other webmail application to send, receive, download, and other activities when it comes to this article.
With this policy, we are not concerned about using constraints to limit activities to only Netskope employees. Therefore we are using the general webmail category to block activities regardless of who is using any webmail application until Friday 8/26 at 5pm when the article will be publicly available.
We do want specific employees to be able to share the article internally over Slack but no other collaboration applications. In this policy, we are allowing activities over Slack before we block other collaboration applications as seen below.
Similar to the webmail block policy, we are prohibiting any communication using collaboration applications until Friday 8/26 at 5pm when the article will be publicly available.
With this policy we want to make users aware of their activities centered around the article and still allow for their ability to work on it, share it, etc, etc.
Since access to or licensing in Microsoft Office 365 is extremely limited, we are not concerned about using constraints and therefore will use a policy similar to Google Drive minus constraints of course.
Similar to the other category blocks, we are going to apply a cloud storage category block policy, prohibiting the use of any cloud storage applications until Friday 8/26 at 5pm when the article will be publicly available.
Unlike Real-time Enabled Protection Policies, API-enabled Protection Policy ordering is not a concern. Since access to or licensing in Microsoft Office 365 is extremely limited, we are going to exclude three users from API policies and apply them to the rest of the Microsoft Office 365 user base.
Mimecast allows us to create content examination policies for inbound and outbound mail. With this policy type we are able to search for specific content within email subject lines, headers, email bodies, and attachments through keywords, regex patterns, and MD5 file hashes. With the example given earlier, if we were to replicate this within Mimecast, to add some layered defense to our pre-existing Netskope policy, this is what the content examination definition would look like:
Now, let's start off with the “Activation Score”, this is the set amount of hits needed for the policy to take its defined action. The action can be either hold, delete, or bounce the email.
This score is made up of the amount of hits for the words/phrases within the Match list. Each entry has a score to it and each match will drive the score up until it reaches the activation score. We can then balance the weight of each match to tune the definition. In this example, we gave some of the words/phrases a larger score to guarantee the activation score will be met if the higher valued word/phrases are detected.
We can then define what sections of the email will be scanned. For this example, we set the subject line, the email’s headers, the email’s body, and any attachments in the email as sections that can be scanned (binary attachments will not be scanned unless the “Scan Binay Attachment” option is selected).
The rest of the definition can be configured differently based on the policies action.
Once the policies have been deployed and synced across the proxies we would be able to see activities related to the policies put in place earlier. Subsequently, we will be able to allow, alert, user alert, and block activities which may be harmful if time sensitive information is leaked.
These activities include the use of Google Mail and Yahoo Mail to send the article.
Other activities include the use of Slack to send internal communications, collaboration.
Conversely, we are able to block unauthorized use of Evernote to collaborate with others.
We even see the storing of the article in MIcrosoft Office’s OneDrive for Business as well as Google Drive to make the user aware through the use of user alerts.
When it comes to API-enabled protection, we are able to easily see the alerts and actions taken by Netskope.
As for Mimecast, policy events can be monitored from the Data Leak Prevention section of the Administration Console (Administration > Monitoring > Data Leak Prevention). The UI allows us to sort for specific actions, recipients, senders, subject lines, and policy names. From here we are able to get a good overview of the amount of emails being affected by a content examination policy, giving us an insight on whether the policy is too restrictive or lenient.
If the policy action is set to hold, we can navigate to Administration > Message Center > Held Messages and select the policy name within the Held Reason section of the Overview tab.
This allows us to look at the messages caught by the policy in the past 30 days, we can then look at the ‘Held Information’ field within the Details tab to learn more about the reasons the message was held. We can use the Message tab to look at the message’s contents for context and to discern the senders/recipients intentions.
Blocking of time-sensitive data is particularly relevant during mergers and acquisitions, marketing campaigns, and changes in business which warrant secrecy but require coordination of personnel to work. Netskope allows for the use of time-sensitive data by necessary persons without worrying about its disclosure.
In order to view this content, you will need to sign in to your account. Simply click the "Sign In" button belowSign In