Deployed it for a client. The marketing claims are aggressive. Here's what we saw.
The core promise is microsegmentation via gateways and security groups. In practice, it can stop *some* lateral movement, but with major caveats:
* It's not agent-based. It relies on tagging VMs and NSG/ASG manipulation. If a resource isn't tagged correctly, it's invisible.
* The automated policy generation is noisy. You'll spend significant time tuning false positives.
* East-West inspection depends on traffic hairpinning through a centralized gateway. This adds latency and becomes a scaling/choke point.
The real test: a simulated breach from a compromised web server.
```yaml
# Example of the declarative rule needed to block the jump to the backend.
# This is more complex than it should be.
- source: tier-web-asg
destination: tier-data-asg
service: tcp/5432
action: drop
enforce: true
```
It stopped the direct SQL probe because we had that rule. It did **not** stop the attacker from using the compromised host's credentials to access Azure Storage via the management plane. That's a different problem.
Verdict: It's a cloud firewall manager and flow visualizer. It can block *network* lateral movement if your design forces all traffic through its gateways and your tagging is perfect. It does not "actually stop lateral movement" in a holistic sense. You still need strong identity controls, endpoint detection, and proper secret management.
slow pipelines make me cranky
Spot-on about the management plane gap. That's the big blind spot with so many network-centric tools. If the attacker has valid keys from the compromised host, they're just another "user" to Azure.
The hairpinning latency issue you mentioned was a dealbreaker for us in a high-throughput environment. We saw a 15-20ms penalty on east-west traffic, which stacked up fast.
Have you looked at anything that combines this network view with identity-focused posture? I'm still hunting for something that ties it all together.
You've hit on the two interconnected problems: the management plane blind spot and the performance tax. The 15-20ms penalty you measured is consistent; that hairpinning model fundamentally conflicts with low-latency, distributed application design.
On your search for something that ties network and identity together, the emerging approach isn't a single product but a combination. We've had to build it piecemeal.
* Use Azure-native tools like Azure Policy and Conditional Access for enforcing identity and resource posture (blocking token issuance from non-compliant VMs, enforcing location-based access to management APIs).
* Treat the network layer, even with something like CloudGuard, as a secondary enforcement ring for when the identity layer is already bypassed. It's a containment strategy, not a prevention one.
This separation means you accept that a tool focused on the data plane will never see the management plane activity. The integration is in the policy orchestration, not the runtime inspection. Have you explored structuring your security groups around Azure AD workload identities rather than just IP addresses?