The Problem: DLP Detects Loss After It Happens
A recent Cloud Security Alliance survey found that among organizations experiencing data loss, only 16% said their DLP solution blocked the incident before data left the organization. That means 84% of the time, DLP told them what happened — after it was already gone.
This isn’t a configuration problem. It’s an architecture problem.
Traditional DLP solutions operate at the network layer. They scan traffic on the wire, looking for signatures that match protected data patterns. This approach has three fatal weaknesses:
Timing: By the time data reaches the network, the application has already read it from disk. The file operation that matters — the read — already succeeded.
Encryption: Password-protect a zip file, use HTTPS, or encrypt the attachment, and signature detection fails. The DLP can’t see inside the encrypted payload.
Coverage gaps: Network DLP doesn’t see USB drives, doesn’t control local file copies, and can’t stop someone from walking out with a laptop full of unencrypted files.
The result is exactly what the CSA survey found: lots of alerts, lots of reports, very little prevention.
The Upstream Intervention: Control the Read Operation
Data exfiltration requires reading files before transmitting them. Every method — email, webmail, USB copy, cloud sync, FTP — starts with an application reading the file from disk.
Control that read operation, and you prevent exfiltration before it reaches the network layer. No signatures to match. No encrypted payloads to inspect. The application simply can’t access the data.
FileSure Defend enforces this at the Windows kernel level via a file system filter driver. It intercepts file operations — open, read, write, delete, create, rename — and applies policy before allowing them to proceed.
Here’s how it works for common exfiltration methods:
Email client (Outlook, Thunderbird): The email client must read the file before attaching it. FileSure blocks the read operation. The attachment fails before the email is composed.
Webmail (Gmail, Yahoo, Office 365 in browser): The browser must read the file to upload it. FileSure blocks the browser’s read operation. The upload never starts.
USB drive copy: Windows Explorer must read the file before copying it to removable media. FileSure blocks Explorer’s read operation. The copy fails.
Cloud sync (Dropbox, OneDrive, Google Drive): The sync client must read the file. FileSure blocks the sync client’s read operation. The file never reaches the cloud.
Encryption programs: The encryption tool must read the plaintext file. FileSure blocks the read. The file can’t be encrypted and exfiltrated.
A Real FileSure Rule Configuration
Here’s a policy that prevents exfiltration of Excel files containing financial data while allowing authorized work:
Protected files: *.xlsx in E:\Finance\Projections\
**Allowed programs:** EXCEL.EXE
Blocked operations: Read, Write, Delete
Applies to: All users, all machines
Drive type filter: Block all operations on removable drives
With this rule, employees can open and edit the files in Excel. They cannot email them (Outlook can’t read them), upload them via webmail (browser can’t read them), copy them to a USB drive (Explorer can’t read them), or sync them to personal cloud storage (sync client can’t read them).
Every blocked attempt is logged with user, program, timestamp, and operation type — giving you a clean audit trail without the noise of network-layer signature matching.
Prevention Before Detection
The CSA survey result — 84% detection after loss — reflects the limits of network-layer DLP. By the time data reaches the network, the damage is done.
Kernel-level file operation control prevents the read that makes exfiltration possible. It’s not about detecting encrypted payloads or matching signatures. It’s about deciding which applications get to read protected files in the first place.
Start a free trial at bystorm.com and see how file system operation control changes the data loss prevention conversation.
Category: Data Loss Prevention
Tags: data loss prevention, dlp limitations, kernel filter driver, file system security, data exfiltration, cloud security alliance, network dlp, file access control