I am hearing feedback that organizations are checking out Firewall Analysis vendors to save time satisfying firewall change requests and to increase the security quality of each change (e.g. reducing errors that create gaping holes or disrupt application services). These organizations get the operational efficiency benefits, but are unsure whether to prioritize application-oriented Firewall Analysis or threat path-oriented Firewall Analysis, to use terms from my recent Firewall Analysis Saves Time Keeping Application Paths Clear report.
The answer is very clear: firewalls are in place to secure access to applications. That is job 1. Period. You should be prioritizing your evaluations on application-oriented Firewall Analysis solutions because that is what your business most needs right now and in the coming years. Firewall changes are driven by the demands of users and applications – it is simply practical to align Firewall Analysis criteria to meet these demands.
You would think the application-oriented issue would be the thousands of applications organizations need to make accessible to a large mobile user community. And to a certain extent you would be right as users will feel the brunt of application service disruptions. Ironically enough, it is the back-end complexity of applications that causes the security headaches. Applications now consist of connected web servers, databases, application engines, load balancers, and gateways – many of which are transient virtual images, deployed in corporate data centers, or distributed throughout the cloud. Leveraging your understanding of the relationships of the entire application environment in maintenance of firewall rule sets is critical in creating effective rules and in avoiding creating over permissive access which could leave a security hole to critical resources undetected for far too long a time. Application-oriented Firewall Analysis will help you secure the entire application environment and save you considerable administrative time.
On the other hand, I am not a big fan of threat path analysis as part of a vulnerability management strategy. And I want to be. The premise is that you do not have to patch key vulnerabilities in servers if threats cannot reach those vulnerabilities, or must pass through an IPS in transit. It is a security form of alchemy, sounding obvious and beautiful until you think it through a little bit. No matter how many hops you analyze, attacks are going to defeat pattern-matching security filters and somehow reach a vulnerable server tucked away in the darkest corner of your data center. They always do. And now your threat path analysis is worthless. Can you imagine your CISO telling the board that vulnerability management of sensitive servers was given a low priority because a threat path analysis vendor told him/her that an attack could not reach those servers? Me neither and I have yet to talk with any enterprise security executive that thinks this is a valid approach. Threat path analysis can help you audit your network for security AV and IPS filters, or trace where an attack may have leapt to from an infected server, but will only be able to help you once or twice a year. For vulnerability management however, I don’t buy it and neither should you.
Just think about what your most common firewall related help desk tickets say. Probably “I cannot access my application” or “My application performance is terrible” top the list. You are probably not getting a lot of requests to leave serious vulnerabilities in critical servers un-patched. If you must go with threat path-oriented vendors, know that you will only use them once a year or so to make sure all network segments pass traffic through security filters. My advice to you is to start with a strategy of application-oriented Firewall Analysis that will protect your business, keep users happy, and save you time every single day.
Receive notifications of new posts by email.