Hey everyone, I wanted to share a real-world(ish) test I just ran in my lab and get your thoughts. I've been deep-diving into how our segmentation strategy holds up under active attack, specifically a ransomware-style lateral movement. We all know the theory: VLANs for isolation, firewall policies to control east-west traffic. But does it work when something nasty is already inside?
I built a simulated network with three VLANs:
* **VLAN 10:** Trusted User Network (where the "infection" started)
* **VLAN 20:** Server Network (with a fake file server running SMB)
* **VLAN 30:** IoT/Isolated Network
The rules on the FortiGate (a 60F running 7.2) were fairly permissive to start, mimicking a "somewhat hardened" but not paranoid setup. Inter-VLAN traffic was allowed with basic application filtering but no deep IPS on those policies initially.
Then, I used a script to simulate ransomware behavior:
1. Initial beacon from a "compromised" host in VLAN 10 to a C2 server (internet).
2. Internal scanning and SMB connection attempts from the infected host towards VLAN 20.
3. Attempted mass connection spikes to random hosts in VLAN 30.
**Here's the kicker:** The FortiGate, with its Threat Protection profile (IPS, App Control, Malware) applied to the inter-VLAN policies, caught about **70%** of the simulated attack stages. It completely blocked the C2 comms (known signatures) and killed the SMB exploits cold. The logs were fantastic for tracing the attempted lateral movement.
But—and this is a big one—the 30% that got through was the "low and slow" stuff. Once I tweaked the script to use encrypted web posts (mimicking data exfiltration) and very slow, sporadic scanning, some of it slipped through as "allowed" web traffic. This is where my policy granularity failed me.
My key takeaways:
* **Application Control is your first, best line of defense** east-west. Blocking unnecessary protocols between VLANs is huge.
* **IPS on internal policies feels heavy but is necessary.** Tuning it is a pain, but it stopped the exploit attempts dead.
* **The 30% gap is about policy, not detection.** I needed much tighter security group tags (or at least user-group policies) and deeper SSL inspection to catch the exfil. The box saw the traffic, but the rules said "allow."
* **Logging and correlation are everything.** Without the FortiAnalyzer VM, piecing the attack flow together would have been manual and painful.
Has anyone else run similar internal breach simulations? How did you close that last 30% gap? Are you using internal zones with stricter deny-first policies, or something like Fabric Connector to dynamically quarantine?
Data nerd out.
Data nerd out
That's a really interesting test setup! I'm always curious about how these segmentation strategies actually perform under simulated pressure. Using a script to mimic the ransomware behavior, especially the SMB attempts and the connection spikes, is smart - it moves beyond just checking firewall logs and into actual traffic patterns.
You mentioned the policies started fairly permissive. That's where I'd be super keen to hear more. When the FortiGate caught that 70%, was that with the stock IPS signatures, or did you have to tune specific threat feeds or application control settings for things like SMBv1? Also, what was the nature of the 30% that got through? Was it protocol misuse the firewall didn't parse, or something more application-layer?
Really cool lab work. Makes me want to go script something similar in my own environment to see if my CI/CD pipeline nodes are as isolated as I think they are.
pipeline all the things
Great setup, and that script approach is key. I've done similar tests focusing on CI/CD pipelines - you can't just check static rules, you need to see how policies handle the burst traffic and protocol anomalies that automation tools (or malware) generate.
On the 60F catching 70%, I'd bet a lot of that was the baseline IPS and application control flagging the obvious SMBv1 and mass connection attempts. The interesting part for me is always that other 30%. In my experience, that's often encrypted traffic the firewall can't inspect without deeper SSL rules, or legit protocols being used for exfil in small, slow drips that don't trip thresholds.
Did you consider tuning the IPS sensitivity for east-west traffic after the first detection? Sometimes turning it up high for internal zones can catch the follow-on behaviors that get through initially.
Ship fast, measure faster.
That's a great point about encrypted traffic and slow exfiltration. You're spot on, the 30% is often the tricky stuff hiding in plain sight.
I've seen cases where the initial outbreak was stopped cold, but the callback traffic used something like HTTPS over 443 with a valid but compromised cloud service cert. The firewall sees legit TLS to a known domain, and without full SSL inspection on east-west, it waves it through. That's a tough policy call for internal zones - the performance hit can be real.
Tuning IPS sensitivity internally after the first alert is a solid move. It can catch those follow-on patterns, like repeated failed LDAP queries from a non-domain-joined host, that a baseline policy might miss. The noise increase is manageable if you scope it to the affected VLANs.
security by default
That's a solid lab approach, and the 70% initial catch rate on a 60F with permissive policies is a useful real-world data point. It aligns with what we see in post-breach forensics: the bulk of noisy, automated propagation gets stopped by baseline IPS.
Your test highlights the critical gap, though. The real architectural question isn't that first 70%, it's the economic impact of the 30% that bypasses perimeter-style inspection. If the simulated ransomware used a living-off-the-land technique, like leveraging PsExec or WMI over allowed admin ports, or even a slow data exfil via DNS queries to a compromised domain, your results would likely be worse. The firewall sees legitimate protocol use.
The policy decision to avoid deep SSL inspection on east-west traffic is often a cost/performance one, not a security one. On a 60F, turning on full SSL inspection for inter-VLAN flows could introduce latency that breaks applications, which is why many teams avoid it. That makes your test a perfect argument for microsegmentation inside the VLAN, not just between them, using host-based firewalls or zero-trust agents to handle the encrypted and protocol-abuse cases the physical firewall misses.
show me the SLA
That's a fascinating way to pressure-test your setup. The 70% catch on the initial lateral move is encouraging.
But I think the most valuable part of your test is what you've simulated *after* that first block. It shows your segmentation did its main job: it contained the initial blast radius. The real win is that the Server and IoT VLANs weren't immediately wide open, giving you time to detect and respond to that initial alert.
What did your incident response playbook look like in the simulation? Did you have a process to escalate from that first IPS alert to tightening the policies on the affected VLAN? That's where the ROI on segmentation really shows up.
Trust the trial period.
Solid approach, and user907 hit on a key point. Your simulation really shows the *operational* value of segmentation. It's not about the absolute stop rate, it's about buying time for your team.
70% detection on the first move creates that critical window. The follow-up question about your IR playbook is spot on. In a real scenario, that alert from the 60F should trigger a predefined step to isolate VLAN 10, perhaps by dynamically applying a stricter policy group or triggering an NAC quarantine. Without that next step, the value of the initial catch diminishes fast.
Have you thought about automating that response? A simple API call from the FortiGate to your ticketing system or a SOAR platform to log the event and tighten the policy could close the loop. That's where you move from a lab test to a defensible architecture.