CASE STUDY · ZERO TRUST ARCHITECTURE IMPLEMENTATION
Replacing implicit trust with continuous verification for an enterprise client.
- 70%Systems reachable per user down about 70%
- 14→3Lateral-movement test paths reduced from 14 to 3
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised enterprise client. Name withheld under confidentiality.
Access policies, micro-segmentation and device checks.
We worked out who actually used which systems, then wrote policies to match. Access was cut back to roles and groups with a business reason. Critical systems were placed in their own segments, with explicit rules for what could talk to them. Device checks were added so that access to sensitive systems needed a managed, healthy device.
- 1Broad internal access for most users.
- 2Over time, groups had grown and permissions had stacked up.
- 3A typical employee could reach a large number of systems they never used.
- 4Internal traffic between servers was mostly open.
- 5The security team knew that a single compromised account could be a way into many systems, and a recent internal exercise had shown how easy it was to move sideways.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01After the first enforcement wave, a nightly batch job failed
It used a service account that connected to a database from a server nobody had listed. Because the failure happened overnight, it was only noticed in the morning, when downstream reports were missing. We restored the rule, traced the flow, and documented the dependency.
- PROBLEM 02We then added a step to the process: service accounts and scheduled jobs are listed with their owners before a wave, and flow logs for a full cycle of batch jobs are reviewed first
Alerts now fire when a job's connections are denied.
- PROBLEM 03A second hurdle was resistance from some system owners, who feared that tighter rules would slow their teams
We answered with evidence rather than argument. We showed each owner the real list of who and what connected to their system, which was shorter than they expected, and we agreed a fast route for urgent access changes. Once owners saw that the process was quick and the data was theirs to use, most became supporters of the next wave.
- PROBLEM 04Once owners saw that the process was quick and the data was theirs to use, most became supporters of the next wave
03 · THE PROCESS
How we ran it.
System owners took part in every wave. We held fortnightly steering meetings with the security director and a weekly working session with network and identity teams.
- 01Step 1
Weeks 1 to 4: usage analysis, system classification and design of segments.
- 02Step 2
Weeks 5 to 8: role clean-up with system owners, device check policy, first segments in monitor mode.
- 03Step 3
Weeks 9 to 16: enforcement in waves, starting with the most critical systems, with a weekly review of denied connections.
- 04Step 4
Weeks 17 to 20: repeat of the internal attack-path test, tuning and handover.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Access requests are tied to roles and need an owner's approval.
- NOW 02
System owners review who can reach their systems on a regular schedule.
- NOW 03
Changes to segmentation go through review, with flow logs as evidence.
- NOW 04
The security team repeats the attack-path exercise after major changes and tracks the number of paths over time.
- 70%
Systems reachable per user down about 70%
- 14→3
Lateral-movement test paths reduced from 14 to 3
05 · WHAT WE BUILT
How it works.
- We combined three layers.
- First, identity: roles and groups mapped to business functions, with access reviewed by system owners.
- Second, segmentation: the critical systems were separated using host-based and network rules, with default-deny between segments and specific allowed flows.
- Third, device state: a check that the device is managed, patched and encrypted before access to sensitive systems is permitted.
- Flow logs showed what actually connected, so every rule rested on evidence.
- Policies were version-controlled and changes needed review, which made the whole set auditable.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Broad internal access for most users. Over time, groups had grown and permissions had stacked up. A typical employee could reach a large number of systems they never used. Internal traffic between servers was mostly open. The security team knew that a single compromised account could be a way into many systems, and a recent internal exercise had shown how easy it was to move sideways.
- What did Brandsmashers build?
- Access policies, micro-segmentation and device checks. We worked out who actually used which systems, then wrote policies to match. Access was cut back to roles and groups with a business reason. Critical systems were placed in their own segments, with explicit rules for what could talk to them. Device checks were added so that access to sensitive systems needed a managed, healthy device.
- How was the work run?
- System owners took part in every wave. We held fortnightly steering meetings with the security director and a weekly working session with network and identity teams.
- What were the results?
- Systems reachable per user down about 70%; lateral-movement test paths reduced from 14 to 3.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
