Deny by default is something you check, not assume
What NIST SC-7(5) and AC-4 actually ask of a rule base, the six ways deny-by-default quietly erodes, and how to check it with objects and NAT resolved.
We built it after one too many incidents spent flipping between vendor consoles to answer a single question.
Every endpoint from every switch, router and controller, in one table you can search.
Trace a flow hop by hop and see which rule stops it.
Real configuration diffs, without the noise from counters and timestamps.
Searches run on a local copy, not on your devices.
If one controller stops answering, SAMURAI moves to the next.
IOS, NX-OS, IOS-XR, PAN-OS, FMC and ASA are detected automatically.
It checks every configuration change against what it knows about your network, so routine changes stay quiet and risky ones get flagged.
Policy suites like AlgoSec are better at rule recertification and approval workflows, and we’ll tell you so. SAMURAI covers what sits around your firewalls: switches, ACI fabrics, ISE and vCenter, in the same view as the rules.
Pull the image, start one container, add your device credentials. Nothing gets installed on your devices, and nothing phones home.
What we learned building SAMURAI: vendor API quirks, what NIST 800-53 actually asks of network teams, and why diffing configs is harder than it looks.