Network Security
The Network Security domain tests whether you can control traffic on purpose: write policy that permits exactly what the business needs, verify it behaves as written, and keep visibility where encryption would otherwise hide everything.
Core rules
- Default deny, then permit by application and user rather than by port. Port 443 tells you nothing about which application is riding on it.
- Firewalls evaluate top-down and stop at the first match. A broad allow placed above a narrow deny makes that deny dead policy - this is shadowing, and it is the most common policy defect you will be asked about.
- Segmentation limits blast radius. East-west rules between workloads matter as much as the perimeter; a flat internal network turns one phished laptop into a domain-wide incident.
- Zero trust decides access on identity and device posture instead of network location.
- Content-based controls - intrusion prevention, anti-malware, file scanning - require decryption. Exclude categories you cannot legally or technically break, such as finance and pinned applications, and document the reason.
- NAT is address translation, not a security control.
- Ship session logs off-box to a system that an attacker holding an endpoint cannot edit.
Worked example
Rule 1 is any/any/allow; rule 5 denies 10.0.0.5 access to the database on 3306. A tester reaches the database from 10.0.0.5 anyway. Reasoning: rule 1 matched first, so rule 5 was never evaluated. Moving rule 5 upward works, but the better fix is deleting the any-any and replacing it with explicit permits - otherwise the same shadowing returns with the next rule someone adds above.
Traps that cost marks
Calling NAT a security control. Writing an inbound rule for return traffic on a stateful firewall. Reading a zero hit count as "unused" when the rule may simply be shadowed. Ignoring port-shift evasion, where an application is moved to a nonstandard port to slip past a port-based rule.