Firewalls and detection: verify allow, block and alert separately

Different controls have different jobs

A firewall controls traffic according to policy. An IDS observes and alerts. An IPS can block traffic on its path. Products may combine these abilities, so check deployment location, mode and rules rather than relying on a product label.

A honeypot can provide clues from interactions with a decoy asset, but its view is also limited. Although the module follows the official chapter structure, this introductory unit focuses on defensive validation and supplies no procedure for bypassing real monitoring.

Further reading: NIST SP 800-41 Rev. 1: Firewalls and Firewall Policy

Put expectations and observations in one table

List source, destination, protocol, action and expected result, then record actual allowance, blocking and alerts. Blocking a legitimate service affects availability. Allowing prohibited traffic violates policy. An event without an alert may indicate a detection or collection gap.

With no alert, check whether the sensor saw the event, whether a rule applies, and whether clocks and forwarding work. A quiet dashboard is not proof of no attack without those checks.

Example: allow web traffic, deny an administration port

A fictional policy allows visitors to 443, denies them an administration port and logs denials. Synthetic results show both blocked, with only the administration-port denial logged.

Blocking administration matches policy; blocking 443 breaks legitimate functionality. Testing only prohibited cases would miss it. Log completeness must also be compared with the stated logging requirement.

Conclusion: Include at least one allow case, one deny case and evidence for both.