Security: Moving Beyond Firewall Configuration Management

For over 20 years, the firewall has been the cornerstone of TCP/IP (Internet) security.  In fact, the firewall has crossed-over from the geek to the chic as it has appeared or starred in print, television, and movies.  While the battle between hackers and security vendors rages on, firewalls have become more sophisticated and complicated to operate and manage. Further adding to the complexity is the increasing trend to build firewalls into routers, switches, unified chassis, and more.

Over the past few years, companies like Tufin, AlgoSec, SecurePassage, Skybox Security, and more have created products that analyze firewalls configurations, rules, and policies to alert security personnel to possible issues.  They have the ability to manage multiple firewall vendors as well as analyzing configurations from multiple firewalls deployed within an organization.  These products are essential to managing and maintaining an ever complex and changing security posture that requires automation to augment and compliment human interaction.  However, to completely understand an organizations security posture we must move beyond the firewall.

While firewalls are complex, they represent only a fraction of the total number of network devices within an organization.  Security personal routinely issue changes to routers, switches, IDS/IDP, and more that impact the entire network infrastructure.  Adding to the complexity are new devices and technology, such as WAN acceleration and virtualization, which are becoming mainstream.  These changes are important to maintain security and regulatory compliance within an organization.

However, the broad impact of these changes (access control lists, port security, network access control, VPNs, and more) may never be fully understood until after the changes are made. High availability and disaster recovery only adds to the complexity as they require synchronized changes/configurations across multiple devices and manufacturers.

Of course, using modeling software from companies like OPNET coupled with internal testing/procedures will aid organizations in making these changes.  The issue is how fresh the information obtained is and the time allotted to make the change given the severity/urgency of the security issue.

Imagine building a security software management platform that allows security and network engineers to jointly view, analyze, and document all security changes while coupling them to a sophisticated and easy to use GRC engine.  A proposed firewall change would trigger a review of the firewall policies followed by a warning that an ACL must be changed on 2 downstream routers while suggesting a re-ordering of said ACL to mitigate a potential security risk and alerting that a HA router must be updated. Next, the GRC engine would require documentation to ensure PCI compliance is maintained.  The coup de grace would be wrapping the entire platform within a visual interface that allowed for layered views of all security/network devices.

Is this farfetched?  Perhaps, but the recent uptick in stories about cyber warfare and cloud computing security threats have created an environment that is ripe for change and innovation.


4 thoughts on “Security: Moving Beyond Firewall Configuration Management

  1. Platen,
    I love your approach, a paradise for network admins. Full control, no surprises and everything integrated into a beautiful GUI: Security, risk, compliance and business continuity.
    There are two known approaches to achieve this kind of goal: a monster solution that does everything and a mix and match of good tools in different areas (best of breed).
    Personally I believe in the 2nd approach but this depends on the ability of solutions to work with each other.
    Security and security management vendors will only open APIs for interoperability if the market demands it.
    So my advice is to the users – rather than asking your vendors to do more, tell them to work together.


    1. Reuven,

      When will the market finally learn that one-stop-shopping and frameworks rarely produce remarkable results? Simply put, customers must demand products that solve today’s and tomorrow’s challenges. In the age of SOAP/XML and HTTP(s) GUIs, vendor integration should be the normal not the exception. APIs must be fully functional and well documented, not just a check-box for a RFP.



  2. Fully agreed – as noted by others, in a perfect world things work like that.
    In our marketing director-driven world however, vendors seem to believe in products offering expanded and “impoved” functionality with every update draw customers – hence improving cash flow and bonuses. As for the bonus-part they may be correct, as for fit-for-purpose and let alone interoperability, they fail miserably.
    The first vendor that offers a modular (not just modularly licensable) set of well-engineered tools that integrate -through Open Standard API’s or other types of “gateways”- well with other vendor’s tools will have to stick out itś neck yet… and imho will never stand up.
    We’ll have to deal with that, I’m afraid.

Comments are closed.