My results after simulating a ransomware outbreak across VLANs. FortiGate caught 70%.

I recently undertook a project to quantify the efficacy of our segmentation and threat protection controls, specifically targeting a ransomware-like lateral movement scenario. The goal was to simulate a compromised host within a trusted VLAN (simulating an initial phishing payload execution) and measure how effectively our FortiGate 600E, running FortiOS 7.2.5, could contain the threat before it reached critical assets in other VLANs. The methodology was straightforward: we used a suite of non-malicious but highly identifiable tools (e.g., PSExec, Nmap, SMB copy) to mimic the reconnaissance, credential dumping, and lateral movement phases of a typical ransomware attack. Traffic was allowed to flow between VLANs strictly as defined by firewall policies, with all applicable security profiles (IPS, Application Control, AV) enabled.

The results were illuminating. Over a 72-hour controlled test period, the simulated attack attempted 1,243 distinct cross-VLAN transactions. The FortiGate successfully blocked 874 of these attempts, yielding a containment rate of approximately 70.3%. The breakdown of blocked events by security profile is as follows:

* **Intrusion Prevention System (IPS):** 412 blocks (47.1% of total blocks). Primarily caught exploits targeting SMB vulnerabilities (simulating EternalBlue-style propagation) and RDP brute-force attempts.
* **Application Control:** 287 blocks (32.8%). Effectively identified and blocked tunneling attempts over non-standard ports and the use of remote access tools not sanctioned by policy.
* **Antivirus (AV) / File Filter:** 132 blocks (15.1%). Triggered on the transfer of simulated "payload" files with known malicious hashes or extensions (.e.g., .crypted, .locky).
* **Explicit Firewall Policy Denies:** 43 blocks (4.9%). These were attempts to reach VLANs for which no permit policy existed, highlighting the value of a default-deny posture.

The 30% that succeeded are of particular interest for cost/benefit analysis. Most successful transactions were encrypted (TLS 1.3) command-and-control callbacks that evaded deep inspection due to our current decryption policies excluding certain subnets for compliance reasons. Additionally, several "living-off-the-land" techniques (e.g., legitimate RDP sessions after credential theft, abuse of approved admin tools) were not stopped because they appeared as sanctioned traffic. This underscores that a pure network security device, while highly effective against known threats and protocol anomalies, is only one layer of a full FinOps-for-security strategy. The 70% catch rate represents a significant potential cost avoidance in terms of isolated infections, but the 30% breakout risk directly correlates to the potential blast radius and associated incident response costs.

From a FinOps perspective, this test validates the reserved instance commitment on the 600E series for its throughput capabilities, as the IPS engine was under sustained load during the test. However, it also argues for investment in additional, integrated controls (like endpoint EDR and stricter Zero Trust network access) to address the gaps, which may have a higher operational cost but mitigate a far more expensive total network encryption event. The configuration snippet for the primary policy that caught the most traffic is below, highlighting the criticality of applying all profiles.

```config
config firewall policy
edit 101
set name "VLAN-User-to-VLAN-Server"
set srcintf "vlan.10"
set dstintf "vlan.20"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set inspection-mode flow
set ssl-ssh-profile "deep-inspection"
set av-profile "strict"
set ips-sensor "ransomware-ips"
set application-list "high-risk-control"
set logtraffic all
next
end
```