The essentials in 30 seconds
- Detecting exfiltration means raising an actionable alert early enough when data leaves the scope through an unauthorised channel.
- Time to detection breaks down into collection, correlation and qualification: each segment has its own fix.
- Replaying scenarios with synthetic data gives you a known T0 and turns a written rule into a validated rule.
For a SOC, detecting exfiltration means spotting that data is leaving the company’s scope through an unauthorised channel, then raising an actionable alert early enough to limit the leak. The quality of that detection is measured above all by one indicator: the delay between the start of the data leaving and the qualified alert. That delay cannot be guessed. It is measured by replaying attack scenarios with synthetic data.
Most SOCs have exfiltration detection rules. Far fewer can say, with evidence, which ones actually fire, and how long they take. This article proposes a method for moving from the written rule to the validated rule.
Start from use cases, not tools
A common mistake is to stack up rules supplied by the SIEM vendor without tying them to a specific risk. Start instead with a short list of use cases, written from the point of view of the attacker and of the data being targeted. The MITRE ATT&CK framework and its Exfiltration tactic help structure that list, without excusing you from adapting it to your own context.
A few use cases that almost always deserve a dedicated rule:
- Abnormal outbound volume: a workstation or server sending noticeably more than its usual baseline.
- Upload to personal cloud storage: files sent to a service the company has not sanctioned (see data leakage through personal cloud and collaboration tools).
- Hijacked channels: unusually long or numerous DNS queries, encrypted traffic towards young or rare destinations.
- Data staging: mass compression or encryption of files just before a transfer, a typical signal of double extortion.
- Behaviour of a trusted user: bulk download from a business repository by a legitimate account, outside its usual habits.
The data sources you cannot do without
A rule is never better than the logs that feed it. Before judging a detection, check that the telemetry arrives, that it is complete and that it is timestamped correctly.
| Source | What it lets you see | Classic blind spot |
|---|---|---|
| EDR / endpoint logs | Process behind the transfer, file access, use of removable media | Unequipped workstations, degraded agents |
| Proxy and web gateway | Destinations, volumes, URL categories | Traffic that bypasses the proxy, partial TLS inspection |
| Firewall and network flows | Outbound volumes per host, ports and destinations | No application or user context |
| DNS logs | Abnormal resolutions, recently registered domains | External resolvers used directly |
| DLP, CASB, email | Sensitive content detected, external shares, attachments | Alerts not forwarded to the SIEM, policies in audit mode |
| SaaS and cloud logs | Shares, exports, public link creation | Delay before the provider makes the logs available |
The last point is often underestimated. Some cloud logs arrive with a delay specific to the provider, sometimes a significant one. Your time to detection can never be shorter than that delay. Better to know it than to discover it during an incident. The blind spots of encrypted traffic inspection are detailed in our article on HTTPS exfiltration.
Measuring time to detection
Defining the right timestamps
Talking about “time to detection” without breaking it down is pointless. Distinguish at least four moments:
- T0: actual start of the data leaving.
- T1: arrival of the event in the SIEM.
- T2: rule firing and alert creation.
- T3: qualification by an analyst (confirmed true positive).
Diagram · time to detection broken down
T1 minus T0 measures your collection chain. T2 minus T1 measures the correlation logic, in particular the time windows of the rules. T3 minus T2 measures the human organisation: alert priority, team workload, clarity of the context provided. A long overall delay can come from a single one of these segments, and the fix is not the same.
The T0 problem
In a real situation, T0 is almost always reconstructed after the fact, and only approximately. That is precisely why reliable measurement relies on replay: when you trigger the scenario yourself, you know T0 to the second. You then get a figure that can be compared from one month to the next, which turns an impression into a posture indicator.
Validating rules with replayed scenarios
A rule that has never fired can be silent for two reasons: no attack has taken place, or the rule does not work. Only an active test can settle the question. The principle is simple: replay, in production, realistic exfiltration techniques with synthetic data that looks like your sensitive data, then check what the SOC sees.
Example scenario
On a Tuesday at 10 am, a test workstation in the finance department drops a decoy file imitating a payroll export onto a personal storage service. Three questions guide the analysis:
- Did the event reach the SIEM, and how long did it take?
- Did the rule “sensitive data uploaded to an unsanctioned cloud” fire?
- Did the alert contain enough context (user, file, destination) to be qualified without a lengthy investigation?
Validation points
- Every use case has at least one replayable scenario.
- Scenarios use decoys only, never real data.
- The replay is announced to a restricted circle, so that the human reaction is measured too, without disrupting the team.
- Results are recorded per segment: collection, correlation, qualification.
- Scenarios are replayed after every notable change: migration, new agent version, policy overhaul.
- The gaps found feed a prioritised list of actions, each with an owner and a deadline.
Next step
How long does it take your SOC to see data leaving?
A 30-minute guided demo, on pre-built result sets: the campaign across the 8 channels covered, the report and its detail, nothing to install. The POC then replays one standard scenario with synthetic data, from a representative machine in your network, through your real egress controls. What actually gets out through your egress paths is what the pilot shows you.
What to fix first
Faced with a series of findings, do not start by rewriting the rules. Check collection first: a perfect rule on a missing log detects nothing. Then fix the rules that do not fire on the most critical use cases. Finally, address the qualification delay, which is often improved by better alert enrichment rather than by extra headcount. The triage logic is developed in our article on prioritising remediation.
To place this approach within the discipline as a whole, the reference page on data exfiltration testing presents the complete method.
Frequently asked questions
What time to detection should you aim for on exfiltration?
There is no universal target. First establish your current delay, measured by replay, then set a target per use case according to the sensitivity of the data. An indicator tracked over time is worth more than a theoretical target.
Can exfiltration scenarios be replayed in production without risk?
As far as real data is concerned, yes, provided you use only synthetic data and controlled destinations: no real data leaves, and yet the test reflects the environment attackers are targeting. Other risks remain, alerts at the SOC or the MSSP and load on workstations: we frame them in writing, with the SOC notified 48 hours in advance and a stop possible in under 5 minutes.
How often should detection rules be validated?
Continuously for critical use cases, and systematically after any change of infrastructure or policy. An annual validation lets silent regressions settle in for months.
Should the SOC know that a test is under way?
Not necessarily the whole SOC. Informing one point of contact is enough to avoid an unnecessary escalation, while still measuring the analysts’ real reaction.