Risk vs. Access
So, as it relates to the firewall, every rule that permits access also increases risk to some degree.  It then seems obvious that excessive acccess (access that is not needed for any intended purpose) is unnecessary risk.  (Clearly removing this excessive access represents low-hanging fruit of risk reduction opportunities.)
Given this reality that permissive rules in a firewall represent some risk to an organization, then it must be true that to effectively manage risk at the firewall is to effectively manage the rules that permit access through the firewall.  Ok, I realize this is obvious without the previous discussion, but this is not how firewalls are managed today.
When rules are created in enterprise firewalls today, they are usually at the request of some business unit in need of additional access.  In most cases these requests go through a formal change management process and hopefully are evaluated for risk prior to approval.  There are opportunities to improve this process, but by and large, this is the correct process.  Someone in the organization has reviewed the justification for the access request and the potential risk that access will present before the new rule is created.  This is good security practice.
The significant problem with firewall management today is post-creation.  Once the rule is created, it is rarely removed.  This explians why policies grow to hundreds, thousads and in extreme cases even tens of thousands of rules.  With this many rules and associated access they represent, the firewall is no longer effectively balancing risk and access.  What is intruiging is that it is almost institutual.  Not only is there not a process in place to identify rules in need of remediation, rules that are thought to be unneeded often go unchanged for fear of blocking access.  Access is trumping security.
A solution to this problem is better rule management.  Rule management that does not stop at creation, but rather tracks, audits and assesses a rule for its entire life.  Of course it must be able to identify rules that present risk, but it must also be able to evaluate business need (justification).  This is not a one-time operation.  This is an on-going process.  So why is it not happening today?  With vendor-provided administrative tools, it is almost impossible to determine either risk or justification (and sometime even function) of a particular rule.  A management applicaiton that provides a view of the rule, risk calculation of the rule and business justification all in one location drastically reduces the effort required to achieve this goal.  It still may not be trival, but it would now be possible.
This is what FireMon eVolution Rule Documentation, Audit Log and Analysis are all about.  Of course any access presents some level of risk, but with the right management solution, you can be in control of the balance between risk and access.

The other day, I wrote about the risk associated with permitting access through a firewall (see post).  However, obviously a firewall can’t block all access (might as well just cut the cable in that case).  So how do you justify the risk of allowing access through a firewall?

Given this reality that permissive rules in a firewall represent some risk to an organization, then it must be true that to effectively manage risk at the firewall is to effectively manage the rules that permit access through the firewall.  Ok, I realize this is obvious, but this is not how firewalls are managed today.

When rules are created in enterprise firewalls today, they are usually at the request of some business unit in need of additional access.  In most cases these requests go through a formal change management process and hopefully are evaluated for risk prior to approval.  There are opportunities to improve this process, but by and large, this is the correct process.  Someone in the organization has reviewed the justification for the access request and the potential risk that access will present before the new rule is created.  This is good security practice.

The significant problem with firewall management today is post-creation.  Once the rule is created, it is rarely removed.  This explains why policies grow to hundreds, thousands and in extreme cases even tens of thousands of rules.  With this many rules and associated access they represent, the firewall is no longer effectively balancing risk and access.  What is intriguing is that it is almost institutional.  Not only is there not a process in place to identify rules in need of remediation, rules that are thought to be unneeded often go unchanged for fear of blocking access.  Access is trumping security.

A solution to this problem is better rule management.  Rule management that does not stop at creation, but rather tracks, audits and assesses a rule for its entire life.  Of course it must be able to identify rules that present risk, but it must also be able to evaluate business need (justification).  This is not a one-time operation.  This is an on-going process.  So why is it not happening today?  With vendor-provided administrative tools, it is almost impossible to determine either risk or justification (and sometime even function) of a particular rule.  A management application that provides a view of the rule, risk calculation of the rule and business justification all in one location drastically reduces the effort required to achieve this goal.  It still may not be trivial, but it would now be possible.

This is what FireMon eVolution Rule Documentation, Audit Log and Analysis are all about.  Of course any access presents some level of risk, but with the right management solution, you can be in control of the balance between risk and access.