6 Ways to Evaluate Firewall Change Requests to Ensure Security and Compliance and Prevent Risk Creep
Firewalls are like Roach Motels – rules check in but they don’t checkout. When you look at a firewall with thousands (or tens of thousands) of rules you have to wonder if they are all still needed. Join Ultimate Windows Security and FireMon to find out how to automate the work flow of firewall change requests, capture and document rule changes, evaluate the impact of rules and compare rules to the characteristics of the actual packets being passed by those rules.
Firewalls are like Roach Motels – rules check in but they don’t checkout. When you look at a firewall with thousands (or tens of thousands) of rules you have to wonder if they are all still needed. But when you see something like
Where do you start? What systems are behind these 2 IP addresses? What application is communicating over https? Are the systems still active? Or have they been decommissioned? Just because the IP address answers a ping doesn’t mean it’s the same system as when the rule was created. Answering those questions definitively could easily take hours and drag into days while you wait for different departments and teams to respond to emailed questions.
A build up over years of outdated rules is bad enough for security and performance, but it turns out that a lot of rules added to firewalls are bad from the beginning. Here’s several ways that happens:
1) The requesting team or department specifies broad port or IP address requirements leading to overly permissive rules.
2) Exact port requirements are not understood but immediate network access is required. A temporary rule goes in, allowing any kind of traffic between specified IP addresses. Rule is never revisited.
In this real training for free session, we will look at 6 ways to enhance your firewall change process to address these problems.
1. Peer check for technical mistakes
2. Documenting responsible party (owner) of rules, host lists, service definitions and other FW objects
3. Documenting creation date of rule (this alone is surprisingly helpful)
4. Instead of just accepting literal IP and port designations, require more descriptive information to allow validation, risk analysis and allow future re-evaluation
5. Analyze actual traffic being passed by seemly broad rule in order to identify actual requirements
6. Compare change requests to network security architecture and written security policies
7. Identify unintended or obscure consequences
8. Implement a reverification program with rule owners
The firewall experts at FireMon are sponsoring this webinar and I think you’ll love it when Tim Woods briefly shows you how FireMon can automate the work flow of firewall change requests, capture and document the information above, and help you evaluate the impact rules and compare rules to the characteristics of the actual packets being passed by those rules.