Data Exfiltration Risks - E-mailing Reports

Users potentially leak data every time they send information as part of an email or some other message transport.  Data access controls are rendered useless by data sent as email or other attachments.  Potentially sensitive data is impossible to control or remediate once it is outside the reporting system.

Reports with incorrect data live on forever as attachments or saved to local file systems.  The data can never be fixed globally because no one knows where all the copies are.  This creates data consistency issues and potential regulatory issues

We heard this
    The new system makes it hard to mail data to my external partners.

And our answer was
    Yes, it is and you should never have been doing that.


  1. Admit you have a data problem.
  2. Create a policy and train people to stop sending sensitive data as attachments.
  3. Recognize that transmitting data without controls is a data Exfiltration risk.
  4. Make people work around the system in order to share data.
  5. Get Tooling
    1. Buy a cloud reporting tool and license the tool so that every expected user can be granted read access to individual documents or document areas.
    2. Create a report blob storage area and issue links
  6. Create workable authorization controls. 
    1. Possible granting of access on a temporary or time-limited basis.
  7. Provide a solution that is a better alternative to the users than is them creating their own Shadow IT to do it to get their job done.


Send Report Scenarios

Let's look at scenarios where data is sent by copy like we do when we send a report as an e-mail attachment.

User Sends Report

This case is pretty obvious.  A user sends a report as an attachment.  The recipient of that report is free to send the report data to as many individuals as they wish.  Email viruses can forward the email to outside parties where they can read the report/data.

User Sends Report to External Entity

Here we have the same obvious use case adding in desired data sharing with outside entities.  A user sends a report as an attachment.  The recipient is free to send the report to any recipient in any organization.

Send Link Scenarios

Let's look at scenarios that send the report data by reference instead of by copy. This could be someone sending a URL to a produced report or data set.

User Sends Report Link

Data stays under the protection of the Data Owner's Authorization policies when we create a saved report and send out that link.  Users receiving the link must have credentials to get access and make requests for access if they don't have it.   Random people that receive the forwarded link can not get access to the data.

User Sends Report Link to External Entity

Authorization-protected reports and data sets can be shared with third parties.  The third parties get access to the actual data via an authentication/authorization process.  It may be that the dataset itself or the data set drop location is protected.  Cloud drives are a common example for companies that don't have an external data portal. Not that the link has no value to anyone other than the recipient at the other company because other users activating the link won't have the credentials to see the data.

User Sends Report Link to External Entity that Copies

External companies could copy data from provided linked reports/datasets.  That copying should be forced to be an explicit action that could open them up for financial or other penalties.

It is difficult to fully stop data leaks without draconian actions.  We want to make it easy for data consumers to do the right thing by providing the right access patterns.  The systems force users to violate policies and take explicit actions that break the controls.


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs