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.
Recommendations
- Admit you have a data problem.
- Create a policy and train people to stop sending sensitive data as attachments.
- Recognize that transmitting data without controls is a data Exfiltration risk.
- Make people work around the system in order to share data.
- Get Tooling
- 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.
- Create a report blob storage area and issue links
- Create workable authorization controls.
- Possible granting of access on a temporary or time-limited basis.
- 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.
Video
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.
Comments
Post a Comment