Firewalls, IDS/IPS and Secure Access

Firewalls, intrusion systems, and secure access. This lesson covers the controls that police the traffic within the network architecture from the previous lesson.

The scene. Three questions surface in a network review. The firewall rules have grown into hundreds of allow entries no one can explain. The intrusion system logs alerts that no one reads, and it turns out it could never have blocked anything anyway. And staff connect to internal systems from airport Wi-Fi with nothing but a password. Each is a different control doing less than it should.

Start with the firewall. It enforces a boundary between networks, permitting or denying traffic according to a rule set. The strong posture is default deny: nothing passes unless a rule explicitly allows it, so access is granted deliberately rather than by omission.

And it is the network’s gatekeeper, deciding what may cross. It is not an encryption tool, an anti-malware scanner, or a backup, all common wrong answers when a question asks what a firewall does.

Those hundreds of unexplained allow rules are a real finding. A rule base that has accreted permissions no one can justify has drifted far from default-deny, and each stale rule is a hole. Firewall rules need periodic review, the same recertification logic as user access.

Now the most tested distinction here: I-D-S versus I-P-S. An intrusion detection system monitors traffic and raises an alert when it sees something suspicious. It is a detective control, typically out of band, watching a copy of the traffic. It tells you something happened; it does not stop it. An intrusion prevention system sits inline in the traffic path and can actively block or drop malicious traffic in real time. It is a preventive control.

So the whole difference is alert versus block. Detect-and-alert is the I-D-S; detect-and-block is the I-P-S. The scenario’s system logs alerts no one reads and could never block, so it is an I-D-S, and its value is further undermined because detection with no one responding is detection wasted.

Next, untrusted networks. Staff on airport or hotel Wi-Fi are sending traffic across a network the organisation does not control and cannot trust. A V-P-N, a virtual private network, addresses this by creating an encrypted tunnel between the remote device and the organisation, so anything crossing the public network cannot be read or altered in transit.

The same principle drives secure protocols generally: encrypt in transit. HTTPS, using T-L-S, rather than plaintext HTTP; S-S-H rather than Telnet, so credentials and data are not exposed to anyone watching the wire.

So the clear-text failure is sending sensitive traffic in the open over an untrusted network. A firewall or a password does not protect data in transit; a V-P-N and secure protocols do, by encrypting it.

And one more time, because it matters: an intrusion system that only alerts is useless if no one reads the alerts. This is the silent-failure problem from Domain four again, the signal fired, and no one was listening. Detection is only a control when someone responds to it.

So carry this away. An I-D-S detects and alerts, while an I-P-S is inline and can block, and the exam turns on which one acts. A firewall is a reviewed, default-deny boundary, not an encryption or anti-malware tool. And a V-P-N and secure protocols encrypt data in transit so it cannot be read or tampered with over untrusted networks.