First off, this is about all your firewalls – not just the firewall separating your network from the Internet. That’s an important one (most organizations actually have multiple such) but in this context, we mean everything on your network with an ACL that imposes restrictions on the flow of packets. You do have some amount of internal segmentation within your network, don’t you? Not to mention rules limiting traffic flow to clouds and partner networks.
If you count all of those firewalls up and total up all the rules on those devices, a medium organization will end up with hundreds of rules, a large organization with thousands and a global enterprise with hundreds of thousands of rules. Many individual firewalls have thousands of rules – no joke.
With that amount of complexity, who would assume those policies actually work? The fact that people are getting their work done and required systems communicating with each other only proves your firewall policy isn’t too restrictive – it makes no statement about the preventive controls for which the firewall actually exists.
How many people would you trust to read several thousand rules, comprehend them, and thereby “manually” assess the firewalls efficacy at blocking unwanted traffic? Don’t trust me to be able to do that and you probably wouldn’t trust yourself either.
But the idea of verifying any set of configurations through cognitive evaluation is just wrong. Rule 2 of IT is “Assume Incorrect/Buggy Until Tested”. (Rule 1, of course, is Backup, Backup, Backup). In any kind of IT, when you make a configuration or code change and walk away from it without testing – you inevitably get a call or ticket later pointing out that you missed something, or the change didn’t work the way intended. Likewise, in software development, a professional never releases new or modified code without ever testing it – no matter how many times and how many people have manually reviewed. It just isn’t done.
Yet, in talking to an experienced firewall engineer who has overseen very large and complicated firewall fleets, I was shocked to learn that many organizations simply do little to no testing of their firewalls to prove that they really do stop traffic that should be stopped.
In this real training for free webinar, we will explore what it takes to test your firewalls and prove they actually do what you intend. We aren’t talking about a simple pentest or vulnerability scan from the Internet. And in this session, I’ll explain why that is insufficient.
Here’s some of what we’ll cover:
- Identifying the various zones on your network that put boundaries on traffic
- VLANs
- Network segments
- WLANs
- Subnets
- Choosing the target zones to test and the vantage points to test from. With firewalls testing, the vantage point is just as important as the target. But with a network of any size you can’t really hope to test every combination of test and vantage point – it’s not a so-called NP-Complete problem but the impact is the same – you have to be satisfied with results from a finite amount of effort, so prioritization is important.
- Tools to speed up firewall testing
- How to test firewall policy without touching the actual hosts behind the firewall
- Understanding and avoiding false test results caused by dependencies on host configuration external to the firewall policy
I have the perfect sponsor for this real training for free event – FireMon. Tim Woods will briefly show you how FireMon allows you to automate firewall testing – without even sending a packet or deploying a scanner to vantage point. And that’s just the beginning.
The more I’ve explored this topic, the more interested I’ve become in it. Please join me for this fascinating deep dive.