Network Separation & Exfiltration Control Validation
Whether separated networks stay separate, and critical data stays in
We look for any way your critical data, such as design files or customer records, could leave the networks it is meant to stay in, and show you what to close first.
We work along every way data could leave: network separation and boundaries, cross-network transfer, VDI and remote work, and exfiltration controls such as DLP.
Are our separated networks and critical data really closed off from the outside?
For every way out: whether it held or got through, the evidence, and what to close first.
Reviewed
When it fits
- Your networks are separated, but are they really?
If you run separated networks, as in finance, the public sector or defence, we check that they are divided as designed and that cross-network transfer and remote access are open only as far as they need to be.
- Core technology and design files must stay in
Drawings, source code, research data: we start with whether the material your business depends on can leave the places it is meant to stay.
- You are worried about insider leaks
You want to know whether someone with access, such as a leaver or a contractor, could gather data in bulk and move it out, and whether you would notice along the way.
- Remote work and the cloud have changed how you work
Bringing in VDI, remote work and cloud collaboration tools opens new routes; we check that they sit inside the controls you already have.
The SAFE SQUARE approach
Starting from the data
We first set which data must be protected and where it should stay, then follow every way it could leave.
Design against reality
We compare the boundaries in your network diagrams and policies with the connections that actually exist, and find the links and routes the design never had.
Whether the controls really catch it
Using test data, we try to move it out and see whether controls such as DLP, firewalls and cross-network transfer systems actually catch the attempt and record it.
What we look at
Every organisation divides its networks and moves data differently; below are places we often check.
- SPLITSeparation and boundaries
- Whether network separation and segmentation hold as designed
- Boundary controls between development, production and external networks
- Servers and equipment connected to both networks
- TRANSFERWhere data crosses
- Approval flows in cross-network and file transfer systems
- Copying, printing and screen sharing over VDI and remote work
- Cloud collaboration tools and personal storage
- COLLECTGathering and sending out
- Whether critical documents and data can be gathered in bulk
- Routes out of the organisation, and how far controls cover them
- Removable media and printing
- CONTROLControls and records
- Whether DLP and firewalls actually catch exfiltration
- Whether attempts are logged and raise an alert
- Exceptions, and how they are approved and recorded
‘No PC on the internet network connects straight to a business-network server’
‘Every file sent across the networks leaves an approval record’
‘There is a daily limit on how many design files one person can download’
How it runs
Set the data and the boundaries
We set out the data to protect, the networks it should stay in and the approved ways out, and write them down as conditions.
Agree scope and safety
Before we start, we agree the sections and systems to test, the test data and accounts to use, what is permitted and when to stop.
Validate the routes
For every way out, we check whether the test data actually leaves, and whether the controls catch and record it.
Show what to close
For each route: the result, the evidence, what to close first and how to improve.
Tests use test data agreed in advance, and the method and the criteria for stopping are set before we start, so that running operations are not affected.
What you receive
Results by route
For every way out: whether it held or got through, with the conditions that make it so.
Connections the design never had
Links and routes missing from your diagrams and policies, gathered in one place.
How well the controls work
Whether DLP, firewalls and cross-network transfer systems caught and recorded each attempt, and where they missed.
What to close first, and what comes next
What to close first, how to improve, and what to examine next.
The research centre's design files cannot leave the research network
Target: a manufacturer's research and business networks, cross-network transfer system and VDI
| Way out | Result | Evidence |
|---|---|---|
| Cross-network transfer | Stopped | Design file types cross only with approval, and every attempt is recorded. |
| VDI copy and export | Stopped | File copy and export in VDI are switched off, as the policy says. |
| A development server on both networks | Got through | Through a development server connected to both the research and the internet networks, the test design file reached outside storage. |
| Bulk downloads | Needs work | There is no daily download limit per account, and bulk downloads raise no alert. |
| What DLP covers | Needs work | Email attachments are caught, but files uploaded to the cloud collaboration tool were outside what it checks. |
- Impact on the business
- One development server gives the research centre's design files a way out, and gathering them in bulk would be hard to notice.
- Close first
- Move the development server inside the research network and keep its internet access to an approved update route. Then add per-account download limits and alerts for bulk downloads, and bring the cloud collaboration tool into DLP.
The results show the state at the time of testing. Whether to re-test after fixes is decided as needed.