In a recent blog post, we introduced called Data Loss Protection (DLP), a security component and part of Zero Trust (ZT) architecture that is designed to help corporations protect information and avoid unauthorized data and document exfiltration.
Data Loss Protection or Data Leakage Prevention?
First, let’s clarify one thing: both methods are often referred to with the same “DLP” acronym, and are often implemented together to enhance your security posture, but they are not technically the same thing as they prevent different threats through different methodologies.
On one hand, Data Loss Protection (also sometimes called Data Loss Prevention) refers to using software tools and security methods to prevent loss of data, intentionally or accidentally, on desktop computers and servers. This typically consists of copying a bunch of documents into an external HDD or USB key or sending them as an attachment to an email address outside of the organization. This is commonly referred to as data exfiltration since the data, in the form of documents (or content, if we consider email message body) leaves the boundaries of an organization, both physically and in terms of security and control.
On the other hand, Data Leakage Prevention is about using methods to prevent sensitive data on mobile devices from flowing out of the organization to a third-party, intentionally or not. This often entails copying information (using copy/paste functionality) from one mobile application to another, allowing private, unmanaged apps to access data within corporate apps (e.g., contacts, documents), or even forwarding a sensitive work email to an external address (sometimes belonging to the employee themself, without even realizing the risks and impact associated with it).
Evidently, although the goal is the same, the approach is different, as are the tools and methods that are used.
Data Leakage Prevention
There are a couple aspects to consider that will help define your mobile DLP strategy.
The first aspect is to understand which applications employees are using to perform their daily work tasks and how they share data between them (e.g., open In, share documents, copy/paste), that is, the work mobile apps workflow.
The Second aspect is the device ownership, as this will directly dictate which rules can be used and how. On corporate-owned devices, using in COPE or COBO deployment, the device is controlled by the company, so specific policy rules can be enforced on the whole device, while with personal-owned devices used in BYOD deployments, these can only be enforced at the app level, on the managed, corporate apps only. Anything else is out of control, and a wall needs to be built around these apps to protect their data.
Finally, the third aspect is to define what data can be shared outside of the work apps, with private apps, and which cannot. This is particularly important for COPE and BOYD deployments, as anything outside of the approved works apps, in considered private, including all the native, pre-loaded OS apps like the phone app. For example, allowing personal apps, including the mobile phone app, to access corporate contacts, so calling ID works when getting an incoming call from a work contact; this seems like a simple thing, but this is an important point to consider, as this will directly affect the employee’s satisfaction and acceptance. After all, good security helps employees do their job securely.
Also, some containerized ecosystems (e.g., BlackBerry and Microsoft) can exchange data securely using a secure bus, which comes in handy when using secure containerized apps from several vendors for specific business needs.
When it comes to implementing these security rules, two specific components will be required:
- Unified Enpoint Management (UEM) solution, which is a must and the first step to manage any mobile fleet in any organization, smaller or larger, and secure said devices by enforce IT policy rules.
- For BYOD and COPE deployments, a containerized solution, usually from the same vendor as the UEM solution to guarantee optimum integration and configurability. This typically is a suite of mobile apps that have been develop especially so they gather internal security features, not included in their default, public version, that can be triggered and enforced by a UEM solution using IT policy rules. For example, lock after a specific delay, require biometrics (fingerprint, face recognition) to unlock, prevent copy/paste of data or screenshots, etc.
Data Loss Prevention (DLP)
Here, we are not dealing with data between apps on a mobile device, but rather documents or files containing sensitive data “physically” leaving the control of the organization when copied over removable media, sent by email or uploaded to an online storage provider.
It would be simply undoable to flag all sensitive content from all documents, so the first aspect to consider is what kind of information is considered sensitive? This will be different for each organization and will mostly depend on the area of business it is in, and the type of data it is handling. It could be sensitive or regulated information related to the business itself, like Intellectual Property (IP), to the employees (healthcare information) or to customers and partners (contracts, customer data).
Then, it is important to understand where these documents are usually stored (local desktop computers, central backend server, online cloud service, USB drives) and how they are exchanged with external parties, for example by emails, using secure online sharing services or other means. It is important to build a list of trusted, external domains including all company, partners and customers email domains with whom information is usually shared safely; anything else will be detected as suspicious and closely monitored. For emails, it is also possible with most DLP solutions to even scan the content an email before it sent, to ensure not only the attachments, but also the body of the message, does not content any sensitive information.
Finally, as with mobile devices, it is important to understand who the device belongs to and if it is a personal or corporate-owned computer, as a software agent (and plugins) will need to be deployed locally and this may not be possible on non-corporate ones.
In term of requirements, a third-party DLP solution will need to be integrated and deployed on all endpoints where sensitive data is stored and/or handled, to detect and prevent any unauthorized data exfiltration. If available, it is recommended to use one from your current UEM vendor, for easier integration (compatibility) and management (same/similar console).
It is recommended to monitor during the first 30-days and adjust the configuration if needed, for example of eliminate false positive (exfiltration which end up being legit information sharing) or, on the contrary, exfiltration (simulated for testing purpose) that were not detected.
Furthermore, most vendors provide forensic capacity for desktop computers, which allow your security team to monitor file activities to detect suspicious activities and perform post-incident investigation whenever you suspect an undetected exfiltration might have happened. Since all files activities are tracked and reported by the agent deployed on the endpoints, it is possible to look for a specific file, folder or repository at a given day and time, to see what happened with it and adjust your DLP software configuration if needed to ensure such situation will be detected and prevented in the future.
It’s always a good idea to periodically reassess your critical infrastructure and see where you can improve and strengthen your security. With your new knowledge of DLP, you can consider how this might be implemented in your environment and further improve the likelihood of keeping your infrastructure safe and sound. Please feel free to contact the team at ISEC7, and we can help you navigate the options available to you to help strengthen and protect your infrastructure.
(C) Rémi Frédéric Keusseyan, Global Head of Training, ISEC7 Group