The essentials in 30 seconds
- Outbound, business pressure widens the rules: they almost never tighten again.
- Network DLP only sees what passes in front of it: the real question is where data can get out without crossing it.
- Only measurement, segment by segment and with synthetic data, turns a configuration review into evidence.
Egress filtering (or egress control) refers to the set of rules that decide which flows may leave your network, to which destinations, over which protocols and from which segments. Combined with a network DLP, it is the last barrier before sensitive data ends up with a third party. The only way to know whether it holds is to measure it with active tests, not to reread the firewall configuration.
Many organisations have invested years in inbound filtering. Outbound, the default rule is often still the same as on day one: allow everything to the Internet, with a proxy for browsing and the hope that the DLP will see the rest. This article gives you a method for checking what really gets out, segment by segment.
Why egress filtering is the poor relation of network security
Inbound filtering follows a simple logic: close everything and open case by case. Outbound, business pressure reverses the logic. An application does not work, a vendor asks for an address range to be opened, an update fails: the rule widens. It almost never tightens again.
The typical result after a few years:
- an inherited “any to Internet” rule, placed at the bottom of the policy but still active;
- proxy exceptions granted to servers “temporarily”;
- server segments that go out directly, without passing through the proxy or inspection;
- DNS resolution allowed to any external resolver.
Diagram · the paths outside inspection
The four areas to check
1. Proxies and their exceptions
The proxy is often the chokepoint where the network DLP is connected. Check three things. First, that it is genuinely mandatory: a workstation that attempts a direct connection to the Internet must be blocked by the firewall, not merely “configured” to use the proxy. Next, the bypass list: every domain excluded from inspection is a possible channel. Finally, the site categories allowed without analysis, in particular storage and sharing services.
2. Allowed protocols
HTTP and HTTPS are not the only protocols that go out. List what your policy really lets through: DNS, NTP, SMTP, SSH, application ports opened for a partner, video conferencing protocols. For each one, ask a question: is this flow inspected by a control capable of detecting sensitive data? Two cases deserve specific treatment: the DNS channel, often open by default, and undecrypted HTTPS traffic, which accounts for most web traffic.
3. Network segments
A user workstation, an application server, an administration bastion and a development environment do not have the same outbound needs. Yet the policies are often identical. Server segments are the most exposed: they hold the data, they frequently go out directly for updates, and an attacker who gains a foothold there will look for precisely that path. A database server generally has no reason to reach the Internet.
4. The “allow all” rules
They are rarely written as such. Look for rules with destination “any”, overly broad network objects (entire cloud provider ranges), and rules with no review date or owner. A firm opinion: an outbound rule with no identified owner should be considered as one to delete, not to document.
What to measure
Rereading the firewall policy gives a theoretical view. Measurement gives evidence. Here are the useful indicators, to be tracked per segment.
| Indicator | What it reveals | How to obtain it |
|---|---|---|
| Block rate of exfiltration scenarios | The share of synthetic data egress attempts actually stopped | Replay of attack scenarios from each segment |
| Detection rate without blocking | Flows seen by the DLP or the SOC but not stopped | Correlation between tests and the alerts generated |
| Egress channels outside inspection | The protocols and destinations that escape the DLP | Inventory of allowed flows cross-checked against the inspection scope |
| Time to detection | The time between the attempt and an actionable alert | Test timestamps compared with SOC alerts |
| Drift over time | Regressions after a rule change or a migration | Repetition of the same scenarios at regular intervals |
A concrete scenario: the staging server
Take a mid-sized company (ETI) that has hardened browsing on its workstations: mandatory proxy, TLS inspection, network DLP on outbound uploads. On paper, the posture is good.
An active test is launched from a staging server, with a synthetic data set imitating an extract of a customer file. Finding: this segment is not subject to the proxy, because an exception was created two years earlier for a deployment. The flow goes out directly, without inspection. No alert is raised.
The fix is not to rewrite the DLP rules, which are correct. It consists of removing the exception, forcing this segment through the proxy and allowing only the necessary update destinations. Then replaying the same scenario to prove that the egress is now blocked. Without a test, this hole would have remained invisible.
Next step
Which of your segments still get out without any control?
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.
Egress filtering verification checklist
- List all segments and, for each one, the Internet destinations that are genuinely necessary.
- Check that direct egress (outside the proxy) is blocked at the firewall for workstations and servers.
- Inventory the proxy and TLS inspection exceptions, with an owner and a review date.
- Restrict DNS resolution to the authorised internal resolvers.
- Remove or justify every outbound rule with destination “any”.
- Replay exfiltration scenarios with synthetic data from each segment.
- Compare the results with the alerts received by the SOC.
- Prioritise the fixes according to the sensitivity of the segment’s data and the ease of the channel.
- Repeat the tests after every significant policy change.
Step 6 is the one that turns a configuration review into evidence. Using synthetic data in production makes it possible to test on the real network paths without exposing any real data.
Frequently asked questions
Does egress filtering replace network DLP?
No. Egress filtering reduces the number of possible paths; the DLP analyses the content of what travels along the allowed paths. The two are complementary, and a hole in one makes the other ineffective on that channel.
Should you move to a “block all” outbound policy?
For server segments, yes, that is the reasonable goal: an explicit allow list. For user workstations, an approach based on a mandatory proxy with inspection is more realistic. The essential point is that no segment gets out without control.
How often should you test your egress controls?
After every notable change to the network policy, and on a regular basis in between. Regressions mostly come from exceptions added along the way, which an annual audit detects too late.
Can you test safely in production?
As far as real data is concerned, yes, provided you use decoys and synthetic data exclusively. The operational risk does not disappear, however: alerts at the SOC or the MSSP, load on the workstations tested. We therefore scope the scenarios with the network teams and the SOC before launch, and a campaign stops in under 5 minutes.