TM Labs · Policy hardening
Every device category that already had a specific reason to talk to something now also has an explicit reason to talk to nothing else.
01
What was possible before today
TM Labs' cameras had a permit rule to reach the NVR subnet — and nothing telling them they couldn't reach anywhere else. A compromised camera beaconing out to iot-c2-relay.xyzwouldn't have hit a single deny rule on its way out. Same story for badge readers and NVRs: one narrow permit each, no floor underneath it.
02
Each device type gets the same two-rule shape: the narrow permit it already had, and a new deny-all-else beneath it, both scoped to that device's own tag so nothing else in the org is affected.
Cameras → NVR
egress · 10.10.2.0/24
Cameras — Deny All Else
egress · 0.0.0.0/0
tag: camera
Badge Readers → Corporate LAN
egress · 10.50.0.0/16
Badge Readers — Deny All Else
egress · 0.0.0.0/0
tag: badge-reader
NVR → Corporate Backup
egress · 10.50.0.0/16
NVR — Deny All Else
egress · 0.0.0.0/0
tag: nvr
03
Higher weightevaluates first — confirmed against real WFP behavior this session, correcting netra's own docs, which had it backwards. That's why each permit sits at 800–900 and its floor sits at 50: the specific rule always gets first look at matching traffic, and the deny-all-else only fires on whatever falls through unmatched.
A policy with zero assignments does nothing, no matter how it's configured — each of these three is assigned via a device-tag, not left bare.