This piece outlines the challenges associated with data loss prevention (DLP) and offers advice on how to architecturally segment your data to ease this process.
All DLP solutions can be problematic and there is no silver bullet. The emphasis and priorities DLP software expects and is built for may not match your organization. Often, DLP alerting is based on obscure rules that are not obvious to the
individual administrator, so data can end up leaving anyway. In addition, data tagging is an onerous task, and the amount of new daily data makes labeling and tagging almost impossible to scale.
Challenges of DLP
For DLP purposes, all existing data must be classified and tagged, and all new data must be tagged on creation. In addition, maintaining that data with the appropriate controls wrapped around it is an extremely non-trivial task.
Third-party partners and supply chain risk management do nothing but exacerbate the issue. How is control maintained around the data when someone else is accessing it?
DLP Strategy: Architectural Data Segregation
The real solution to DLP, and the prerequisite data classification issues, is to segregate all data into classification levels and then architecturally segregate the data. While this is a topic that warrants a paper in itself, a short explanation is in
order.
With architectural segregation, all data is segregated by classification level (public, internal, restricted, etc.) and then each classification of data is segregated into its own:
- Storage: Data is stored in a storage-area network (SAN), Amazon Web Services (AWS) S3 bucket or some variant of a “location.”
- Usage: Data is used on a server, virtual machine, container, or some variant of a “machine,” even if a lambda function is involved.
- Transport: Data is transported over a wire, a virtual circuit, or some variant of a “line.”
- Processing: Data is processed by an application, lambda function or some variant of a “program.”
In other words, data at any level of classification is stored, used, transported, and processed by a dedicated set of components: one location, machine, line and program per level of data. If an application is used to process data at two different levels
of classification, split the application, and spin up separate instances to separate the data classification levels.
This way, every piece of data run on a restricted system is automatically restricted, and any piece of data that traverses the line connected to a restricted system is classified as restricted, etc. Every data flow diagram becomes extremely granular.
In some cases, this presents difficulties for inter-application data flows, but those sets of circumstances should be thought through carefully in the first place.
This architectural segregation of data, into deeply separated systems, also allows for grouping of break-glass credentials and automatically classifies data as an added benefit. It’s similar to the Payment Card Industry (PCI) cardholder data environment
(CDE) segmentation, or the U.S. government’s NIPR/SIPR/High Side segregation of data.
DLP Solution Considerations
Thinking any data loss prevention solution is a silver bullet and that all paths to data exfiltration are closed is a potential pitfall. There are always ways to exfiltrate data. From camera phones, hidden cameras, and narrative clips to simply memorizing it and writing
it down later – there is always a way. The goal is to control access, segregate classification levels and maintain proper processes to handle generated or obtained data, its storage, processing, visualization, and disposal. To get started, consider
the following:
- Architecturally segregate data into systems, applications, and transport by classification levels.
- Deploy tightly written policies with some broader ones, to get a wide variety of alerts. Figure out which ones work better and keep them.
- Beware overconfidence and losing the momentum for classification and tagging.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.