Most of the interest was around tracking firewall configuration changes and we only supported Check Point. This may seem trifling today, but our early adopters realized the business value of receiving a policy change report by email and they loved it.

Seven years later we provide full support for the five leading enterprise firewalls, a graphical network topology model, a policy analysis module that simulates how packets are matched by rules, a security risk model, rule and object usage analysis, a firewall change request system and much more.

Our 900 customers are using our solutions to streamline firewall operations, automate audits and manage the firewall change process.

Our first version in 2012, R12-1, will be released in a few days and we’ve put some nifty features into it.

First, there’s the new dashboard that allows you to see a high-level overview of your risk posture as well as recent configuration changes across your infrastructure and the policy cleanup potential. Security officers can use the dashboard to monitor their security status and identify areas that require attention such as data centers, customers and specific firewalls. The firewall operations team can continue the drill-down using the risk and cleanup browsers and pinpoint the root causes such as risky rules or redundant rules. The dashboard conveys the real-time status of complex environments and allows effective navigation to analyze and remediate problems.

The new policy analysis interface provides some functionality that many of you have been waiting for, like a fast and easy way to enter multiple IPs and Ports and to find rules that allow or block the access through one or more firewalls across the network, even with address translation (for Check Point in this release).

The network topology map now allows you to insert router configs in order to improve path calculations.

Juniper firewalls (ScreenOS and JUNOS SRX’s) can now be monitored through NSM too, and Juniper SRX rule comments are now parsed to identify and report ticket IDs. Especially for you Jeremy .

One more interesting area of evolution in R12-1 is SecureChange – the access request has been enhanced to allow easier reading and editing.  The new Designer automatically recommends firewall rules that should be modified to cater for the access request and, once designed, the change can now be saved directly to a Check Point policy. Automatic provisioning also supports adding and removing members to network and service group.

I wanted to take this opportunity to personally thank our customers and partners for working with us. Your partnership and trust is enabling us to provide better solutions and more value.

Reuven

Tweet This Post

Case in point: a November 2011 survey from Tufin of 100 firewall managers revealed that only 1.3% of configuration changes that cause network downtime or pose a security breach are identified during the quarterly audit, yet almost a third of the respondents spent 3 to 7 days per quarter of valuable network security team time on firewall audits (Disclosure: I work for Tufin). Organizations receive precious few benefits for the level of resources spent on manual firewall audits. This  is proving to be an inefficient approach to maintaining a secure network and if you do the math, an extremely inefficient use of skilled security personnel.

In general, best practices in security are mandated in standards such as the PCI DSS, DISA Information Assurance Support Environment, or healthcare’s HIPAA.   Most if not all of these regulations – and many others, either specifically mandate or implicitly require firewall audits.

The best practices of firewall audits are based on expert reviews of changes made by network and security administrators. In theory, errors are caught, corrections are made, and compliance is re-established as a result of the audit. In practice, errors are seldom caught and operational costs climb, in great part because audit teams discover security issues in firewall protection from manual audits at a very low rate.

As the discipline of IT security continues to evolve, knowing where and when to automate can make or break a CISO’s career – not to mention the morale and effectiveness of their compliance and IT operations teams. One of the important ways security teams gain efficiencies is to apply technology to evolve audit processes from disruptive quarterly or yearly events to daily standard operating procedures. The technology exists today to automatically verify compliance as firewall rules changes are implemented – ensuring continuous compliance with tight security and fewer calls to the security service desk.

The complexities of modern networks are often simply too much for a human to decipher without assistance. Not only do the best security experts have to interpret rules languages across vendors such as Check Point, Cisco, and Juniper Networks, but they must also translate application-based rules from next generation firewalls (such as those from Palo Alto, Check Point,  SonicWALL, SourceFire) to ensure compliance with security policies across the organization. The concept of independent validation of firewall configurations is a good one – the best practice is now to have a security expert craft the new rules and then automate the impact on firewalls to ensure continuous compliance.

Seeking continuous compliance via automation of firewall management has the additional benefit of preserving the valuable time of security experts. Instead of expending critical resources conducting manual reviews of firewall rules that are unlikely to result in improved security or enhancements to compliance, security teams are able to contribute to the business in more productive activities. Too much time – the 3 to 7 days per quarter mentioned in the survey builds up to more than one month per year – is spent conducting ineffective audits and producing documentation for compliance reports. As with many IT disciplines, finding ways to automate activity is the key to freeing time for skilled resources to be more effective. Automating the best practices of firewall compliance returns direct cost savings to the organization.

With automation, organizations discover dangerous configuration changes before the business is exposed to security incidents, generate compliance reports whenever required by the regulations, and shift audit approaches to expert reviews of the security strategy more than manual reviews of firewall rules.  Seeking continuous compliance moves the business closer to the goal of integrating security into business operations with fewer deviations from compliance that can put the business at risk. Spending significant security resources to find security problems only 1.3% of the time doesn’t make sense – if that is your ratio, then automating firewall management is a no brainer.

Shaul Efraim, Vice President of Marketing and Business Development

Tweet This Post

First off, I’d like to say that I’m very proud of the superb job done by the Products and R&D teams – I’m honored to work with such a talented group of people…

This release has been a long time in the making, and is packed with “goodies” that our customers asked for.

The key enhancements which people found most exciting are:

Enhanced Next Generation firewall support – TSS 6.0 contains tighter integration of NGFW into various parts of the product, and furthers our ability to build compliance rules for NGFW policies (enabling admins to specify restrictions based on applications and users). We currently support Palo Alto Networks, and plan to add more NGFW vendors soon.

Enhanced Network Topology Intelligence – we’ve dramatically improved our ability to automatically build a graphical map of the various network devices (firewalls, routers, switches, etc). Based on the respective routing tables and access policies, we use graph algorithms to calculate the paths between different points in the network.

Why is this a big deal? Well, there are many uses for topology intelligence within our products, but the most interesting one (in my view) is when a user requests access through a SecureChange ticket, and that access may actually span multiple network devices. This means that the firewall admin will need to make configuration changes on multiple devices. SecureChange in TSS 6.0 can use Topology Intelligence to identify exactly which devices need to be configured, and the Policy Advisor can prepare a “cookbook” of which changes should be implemented on which device, in order to complete the change request.

Another cool feature of our topology graph is that it is auto-correcting: when routes change on network devices, we are aware of these changes in real-time, and re-build the network topology graph automatically.

The third enhancement that’s worth mentioning is our new High Availability (HA) mode – customers have always asked us about HA for Tufin servers, and with the advent of SecureChange, which is a critical component in the change process, IT managers expect data synchronization and the ability to fail-over during power outages, even across remote data centers. With TSS 6.0, Tufin servers can be installed in a primary/secondary HA configuration, with continous database synchronization, to ensure reliable and consistent data state following a fail-over.

There are many more enhancements, which you can read about here.

Now that 6.0 was launched, we’re working hard on our next release – more news on that in a few weeks…

Take care,

Ruvi

Tweet This Post

By Eric Ogren, The Ogren Group

The shift to virtualization, with most organizations virtualizing more than 30% of their applications, challenges the means by which security teams implement firewall-based foundational controls. Organizations are embracing virtualization for obvious cost savings benefits when applications share server and infrastructure resources. In fact, many enterprises continue to re-architect networks to consolidate data centers, applications and IT services. For instance, the rapid provisioning of applications – running in a matter of minutes on a virtual server for a task that would take weeks with physical architectures – necessitates a rapid evolution in the security lifecycle management of firewall rules.

Virtualization forces firewall rules to change more dynamically than ever before with applications spinning up and being decommissioned upon user demand. The firewall must now manage additional complexities in a virtual environment to quickly accommodate connectivity and access requests at the speed of business without creating security holes. Here are a few ways that firewall rules management is helping to secure virtual data centers:

• Streamline firewall rules management workflow by automating the checking of compliance rules before a manual review. Security and network teams can be overwhelmed with requests for modifications to the firewall rules sets. Firewall rules management can automatically validate that requested changes do not violate corporate security policy or compliance mandates. In some cases the manual review overhead can be eliminated with a “compliance acid test” saving time and money.
• Reduce the complexity of managing rules as firewalls are consolidated into virtualized servers. Organizations are placing multiple instances of firewalls on individual virtual servers, adding significant complexity to firewall rules management. For example, organizations deploying Check Point VSX need to deploy rules changes while evolving the virtual architecture, and must manage multiple firewall rule sets existing in a single security device. This is a new challenge for security teams – having the right tool for keeping effective firewall rules within a sophisticated device, tracking and auditing changes, and managing workflows associated with firewall lifecycles is critically important.
• Although organizations prefer to keep applications within a data center to avoid changing IP address assignments, the use of VMware vMotion across data centers and geographies – perhaps to support a mobile work force using smartphones and tablets – requires consistent firewall rules to avoid disruptions in business. Firewall lifecycle management can help security teams ensure that users can access applications, and that applications do not fall out of compliance, as capabilities such as vMotion shift applications. This capability becomes particularly important in high availability and disaster recovery scenarios.

Security is still catching up to the demands of virtualization. Firewalls are particularly vulnerable in virtual environments because the speed of change is accelerated over traditional physical architectures, leading to increased risk of business disruptions and security incidents. Enterprises embracing virtualization can save themselves a lot of pain by checking out firewall rules management products.

Tweet This Post

Think about how much your organization spends annually on firewall hardware, software licenses, and management. Now think about watching all that money washing down the drain because a single poorly implemented rule circumvented all of the other firewall-based protections. Sounds a little alarming, but if you’re a firewall administrator, you know how real that possibility is.

In a previous post we took a look at “shadow rules” and why investing in automated tools that help eliminate them can be a solid business, not to mention security investment. But eliminating redundant, outdated and ineffective rules is only part of the problem.  For many firewall administrators, the bigger challenge is handling the day-to-day requests for firewall rule changes without introducing vulnerabilities or exposure points.

Firewalls aren’t static sentries that are set up once and run without change for years. Most firewalls have a fluid set of rules and are frequently updated to support new services for the business. While there’s nothing fundamentally wrong with change, how that change occurs can have significant security repercussions. When an admin is being pressured to make a change outside of the normal change management lifecycle and without proper risk analysis, problems occur.

Consider a business unit owner that is in a rush to have a couple of ports opened on the firewall so an external software development company can set up and test their application on the company servers. Chances are the business owner doesn’t know the technical reasons why these ports need to be opened or the risk associated with allowing traffic through newly opened ports, he just knows the developer said to open them.  Because the owner doesn’t understand the potential risks associated with the change, he sees the firewall rules as nothing more than an annoying and unnecessary impediment to getting his application running.

This lack of understanding about how firewalls work can lead to requests for risky rule changes. For example, sometimes the application or business owner doesn’t know which ports should be opened or which services or servers the should be opened for, so they ask for overly permissive rules with ANY that allow all traffic, good and bad, through. Some permissive requests are allowed for a short time for testing purposes and are supposed to expire after the test window. Unfortunately, setting and managing rule expiration dates on multiple firewalls and routers is no easy task. So it’s not uncommon to find permissive rules that were supposed to expire weeks or months earlier, still in effect well after the testing period is complete.

If the business unit owner works in an organization with a robust change management lifecycle, he will need to submit the change request and follow certain procedures to have the change approved and implemented. A typical change management process includes writing up the business justification for the change request, a technical assessment of direct or indirect impacts from the change, and an analysis of the risk trade-offs. For example some of the questions that may be answered during this process include:

• Will the change cause the company to be in violation of a legal or industry mandate?
• Will the change put other systems in the organization at security or business continuity risk?
• Can the business requirement be met with an alternative solution?

Following a set process, like the one outlined above, gives firewall admins time to participate in the process and perform risk analysis before a change is accepted. Unfortunately this process goes awry in two very common ways: 1) The admins are not included in the risk assessment phase or 2) they are not given enough time to complete a thorough analysis. Worst case, for the sake of speed – the change is approved without any kind of formal process and the firewall admins must implement them immediately. Arguably, one of the main reasons admins and risk analysts are “left out” of the risk assessment phase is because their analysis takes too long or their recommendations are seen as too restrictive to the business.

So how can a firewall admins speed up their decision time, provide better insight into corporate risks associated with firewall configuration changes, and get back into the assessment phase?

First, security professionals need some way to model potential changes to the network environment before implementing them. This goes well beyond firewalls because a network is comprised of multiple layers of systems and services, but firewalls are the first line of defense. Any time a change is proposed, be it a new service coming online, a change to a different database platform, or a set of firewall rules to allow for communications to and from these new services risk assessment should be completed.

Having tools to help with this kind of modeling speeds up the process and may catch things a human couldn’t on their own. Tools and techniques here include network topology and mapping, penetration testing and scanning, log analysis, and the risk consoles of IT-GRC solutions.  For firewalls specifically, administrators can use a tool that parses the existing rule set against one with the proposed change and identifies potential areas for exposure or if any of the new rules causes an inadvertent override of existing ones.

Bringing all of this information together into a single report, helps security and firewall professionals assess risks associated with proposed changes more quickly and accurately. To make this information even more valuable, translate the risk into business friendly terms before presenting them back to executives. While the statement “opening port 1025 is not advised because it’s not in official assigned use with IANA and has been associated with RPC vulns in the past” sounds like “dolphin” to most people, saying  “if we open that port, an external attacker could take control of our servers” is pretty easy for all of us to grasp.

Another way to speed up the risk assessment process, without sacrificing security, is to learn how changes impact the system over time. The first time a request is made to open a port like 1025 a long evaluation may be in order. But if the assessment has already been completed, when the second (or third, or fourth) request to open that port comes in, the response time can be reduced but re-using relevant data from the previous assessments. By keeping a record of known and fully vetted requests for future reference, efficiency and cost-reduction are realized through re-use of existing knowledge rather than by skipping the knowledge gathering step altogether.

Tweet This Post

I wanted to point to it on our blog for two reasons.  First, for space reasons, the editors cut the final third of the article, that included some tips on what people could do NOW while waiting for traction for such a standard to occur.  Second, is that the conversation was continued by Fidelis Security Systems CEO Peter George, whose initial op-ed piece got me thinking about a global standard in the first place.  Check out Peter’s response here.

Peter is right – it will take way more than security executives pontificating for such a standard to evolve. Unfortunately, it will likely take some sort of breach or similarly unpleasant qualifying event for a global standard to get the attention it deserves.  Why we need to be legislated into best practices or “doing the right thing” is a whole other issue, one that is worthy of further commentary, so stay tuned!

In the meantime, here are the tips – Hopefully you find them useful!

• Adopt and enforce regulatory compliance standards like PCI DSS, even if not bound to comply.  In addition to PCI DSS, models such as COBIT and ISO 27001/17799 provide clear and useful guidance for creating and implementing enterprise network security policies.  In instances where technical standards impact the duties of non-technical people, educate them on the reasoning behind the policy and the consequences of non-compliance.
• Run regular network security risk compliance reports - Since the network is always changing, you must be able to assess risk and vulnerability at any given time – for all relevant network security devices. Automated security risk reports instantly evaluates the current level of risk and typically displays a security score along with scoring on a prioritized list of risk factors.
• Implement the industry’s best practices for maintaining network infrastructure. These practices can help you create security policies that are secure, up to date, and easy to understand and maintain. Use solutions that allow choosing from a list of vendor and industry specific best practices and select the ones that you want to implement in your organization.  Regular auditing will give you instant visibility into your compliance level along with valuable mitigation information to help you rapidly address the issues.
• Establish and enforce organizational compliance standards. The backbone of any consistent network security policy is the establishment of an organizational standard. Most organizations have a security standard in document, or even verbal form. But to make sure that the policy is carried out and enforced on a daily basis, you need a way to define and monitor it at the level of your network infrastructure.  Implement solutions that give you a simple way to translate your organization compliance strategy into a concrete policy that you can automatically monitor. Any time a configuration change violates the organization policy, alerts should be sent out so that you can maintain continuous compliance.
• Automate wherever and whenever possible:  As the first level of defense, network security technologies are, especially compared to other areas of security, mature.  Unfortunately, sometimes the cost of maturity is that the processes that worked in the beginning no longer scale.  That can lead to operational inefficiencies, which leads to network exposure and business downtime.  Across all layers of security, some of the most useful innovation is a function of automating manual processes or processes that are impossible to do manually (think SIEM.)

Like Bruce Schneier says, Security is a process, not a product.  But there are plenty of products out there that can help you implement the processes you need to optimize the way security functions in your organization.  Use them wisely!

–Shaul

Tweet This Post

Shaul Efraim, Vice President of Marketing and Business Development

Are Your Firewalls Burning Money? Part One: Shedding Light on Shadowed Rules

By Diana Kelley, Principal Analyst, SecurityCurve

As firewall admins and installers (for history buffs, I was a firewall admin and also a TIS Gauntlet firewall installer back in the 90s), we know how much time it can take to write a truly effective list of firewall rules – and to confirm that no previous rule overshadows, contradicts, or renders ineffective a rule further down the list. But if you’re trying to explain to a manager or executive why the process is so tricky – and if done improperly can lead to large, unexpected exposures – you might be met with blank stares.  Even if a manager does have an understanding of the issue, many assume that the problem has been solved by the firewall manufacturers. Surely this can’t still be an issue in 2011?

Well, it is.   

Why?  Oftentimes, it is because it is surprisingly difficult to translate the implications to the folks earmarking funds to solve the problem.  While non-security professionals can connect to the idea of layered security, it’s easy for them to miss the big picture when it comes to the complexities of firewall rules. Personal, physical layered security might look like this: a person with valuables lives in a gated community, has an alarm system on their house, and keeps very high value items in a locked safe.  Security controls may go like this: everyone who lives in the gated community and their trusted family group members have access to through the gate. For each house, only members of that household have access to the alarm code. And the wall safe’s unlock code is known only by the owner of the house and one other person. This set-up sounds very secure and orderly doesn’t it?

Now consider a scenario where a person who gets through the gates creates an override situation on all the other security layers. Anyone that passes the gate as an authorized user can get into any house in the community, because the alarms are no longer active, and these same people can access the valuables in all the wall safes because the locks are automatically unlocked for authorized entrants that passed the gate. Sound a little crazy? Welcome to the world of firewall shadow rules.

In order to manage firewall rules in a risk reductive manner, admins need to invest time or money in manually auditing and reviewing configurations in a 3^rd party audit and analysis tool. Manual time can seem “free” to an organization because full time employees can absorb some of that cost by working extra hours yet still receiving their regular salaries. Of course the real cost isn’t “free” at all – at some point, an employee will have maxed out their available work hours and a new headcount will be required to cover the extra work. Weighing the cost of additional headcount against the cost of an automated tool can be a compelling argument for a purchase, but first that argument needs to be presented to executives in a manner that makes sense to them.

Chances are most executives don’t want to have to learn about the intricacies of firewall management, they just want to know what the data and business risks can cost the business. Our story about the gated community and the house safes is a good possible first pass at an explanation for executives, but to make it real those concepts need to be extended to more realistic business scenarios. You’ve probably got some great stories of your own, but to get us started here’s an example. The expensive perimeter firewalls have been configured with a highly granular series of rule sets to block access to an internal HR application that houses salary and health information of employees so that only authorized remote employees and critical services can access it. Problem is, there’s a rule higher up in the firewall rule set and overrides all of the subsequent complex rules and allows any system access to that HR app.

Manual review didn’t catch it and all the time spent creating the complex rules was wasted, as well as potentially incurring further expense down the road (a failed PCI audit, for example).

Will that resonate with your executives? Having executives on board with the importance of proper firewall configuration is a huge step.

Now let’s return to the headcount issue and quantify the amount of time it takes to actually get the rules right.

• How many firewalls are there in your organization?
• How much time has been spent in the past to ensure the rules are written well and working as expected?
• How many hours are spent reviewing configurations and analyzing risk each time a business unit owner asks for a change to the rules so that a new application or service can be put into production?
• And how many times are changes requested per month or per year?

Calculate out the number of hours and the cost of those hours to get a firm number.

Now calculate how much of this time could be saved if an automated tool were in use.  Subtract the cost of hours saved from the cost of the tool and create a savings sheet for a 1-5 year time frame. Another way to demonstrate ongoing value of investing in automation could be to measure the accuracy of rule changes using an automated tool v. a manual review, or as a troubleshooting tool for firewall related incident or outages. If the tool will save significant money for the company, and reduce risks from misconfiguration in the process, it shouldn’t be too hard to convince executives that it’s a worthwhile investment.

In the second part of this two-part post we’ll take a look at the change management and risk analysis costs associated with firewall configuration and management.

Diana Kelley is 20 year veteran in the field of networking and information security. She is a founding partner at SecurityCurve,  previously she was VP and Service Director for SRMS at Burton Group, a Manager in KPMG Financial Services consulting and a TIS certified Gauntlet firewall installer.  She speaks often on the subject of data and network security and is a frequent contributor to SearchSecurity.techtarget.com.

Tweet This Post

Our efforts have led to the launch of Tufin’s Guest Blogger Series, kicked off right here, right now, with the first of several posts from long time Tufin friend and colleague Eric Ogren of the Ogren Group. Eric’s bio is below, and we have some great people and content in the queue.

In marketing, we use words like “communities,” “conversations,” “influencers” and “thought leadership” all the time. Love them or hate them, blogs, Social Media, and other Web 2.0 apps have added whole new dimension to how people form and share their opinions, attitudes and beliefs. Sometimes the cyberchatter can get so loud, it is easy to forget that at the end of the day, technology is still completely interconnected with people. The people that buy it, sell it, support it, analyze trends around its use, and so on.

It’s for that reason that we are delighted to have our blog be a forum for some of the people that have shaped the attitudes, beliefs and opinions here at Tufin!

If you are interested in contributing a guest post, we’d love to hear from you!

Shaul Efraim
Vice President of Marketing and Business Development

About Eric Ogren Eric Ogren is the founder and principal analyst of the Ogren Group. Eric’s background features a combination of vendor successes and industry analyst thought leadership, including more than 15 years in enterprise security. Prior to founding the Ogren Group, Eric served as industry analyst for the Yankee Group and ESG, and executive management at RSA Security, Okena, Sequation, and Tizor. Eric is a frequent contributor to leading publications and security blogs. Ogren holds a B.S. degree in mathematics from the University of Massachusetts and an M.S. degree in Computer Science from Boston University.

Tufin gets firewall management right

I have long believed that the very best security solutions should also deliver valuable insight to network and application teams within IT.  It only makes sense – security inspects all traffic for malicious content and makes allow/block decisions on all network connections, so why not share this visibility with operations teams? That is one of the reasons I respect Tufin’s approach to firewall rules management. While Tufin is a security company first and foremost, it also realizes that it plays a significant role in helping IT operate an efficient infrastructure.

If you have been following Tufin, then you already know they manage firewall rules to ensure consistency across the enterprise, ensure network access and segmentation policies are uniformly enforced, and provide guidance for requested changes to the firewall rules sets. That’s all good stuff, and if you are a distributed organization this is a capability you should be aware of as with it, you will not even know what security holes you don’t know about. However, it also provides security with an opportunity to give operations visibility across the infrastructure that would otherwise be difficult to achieve.

One example of security visibility put to use to save your organization’s money occurs when users call the IT service desk with issues about application connectivity or performance. Every security practitioner that I talk with reports that the service request gets routed to the security team first thing to check out firewall rules. The reason is that the security team, by tracing firewall rules and the history of rules changes, is in the best position to investigate the problem from end-to-end. If security cannot solve the problem in the firewalls, then it usually accurately identifies the source of the problem.

This is one example of firewall rules management helping you to streamline IT operations, and reduce overhead costs. There are other examples from Tufin customers that are also important:

• Ensure a secure and orderly transition to next generation firewall vendors. Many organizations are migrating to next generation firewalls, or will upgrade existing firewalls, to operate with increased application intelligence. This creates scenarios requiring you to have accurate mappings between traditional and next generation firewall rules sets to reduce compliance gaps and maintain application performance. The consistency in firewall rules allows your business to evolve without disrupting user productivity or generating spikes in requests to resolve help desk calls.

• Automate workflow between security and network teams. I’m beginning to believe that network infrastructures are living things – they are constantly growing and shrinking with applications, users, in-house, and cloud-based services. One way for you to streamline operations is to automate an integrated workflow system between security firewall administrators and network operations. This eliminates lost job requests, lost time transitioning jobs between teams, and duplicate tracking systems to purchase and support.

Let’s get back to Tufin. Tufin has been able to embrace a very challenging concept for security vendors – keep security pedigree first and foremost, but always be prepared to implement features that support IT operations. Tufin has implemented features for next generation firewall evolution and workflow integration that allow you to evolve the infrastructure without disrupting the business or increasing administration costs. It’s a really nice achievement that positions them well for future innovations in both security and networking. The details will be exciting!

Eric Ogren – Founder & Principal Analyst, Ogren Group

Tweet This Post

If you’ve known me for long, then you already know that I don’t think there is a need for firewalls in front of certain websites.  When you’re designing a high performance or high concurrent-user web environment, the risk of a firewall often outweighs the benefits. If you build your DMZ with a screening router and front-end your web servers with a load balancer, then you do not need a firewall.

Let’s look at the technology.  Your router should employ some basic ACL filtering. Only pass the protocols you need into your DMZ; 2-3 protocols will likely do it. Your load balancer is now your connection point for clients. If the load balancer is properly configured, it will only pass the protocol through to your web servers that you have attached to your Virtual IPs (VIPs).  If you only build a VIP for HTTP(s) then you are all set – firewalling accomplished – your servers will only receive HTTP(S) traffic from the Internet.

The advantage here is that your load balancer is designed to handle many, many, many more connections than your firewall. It’s also designed to offload your webserver from handling these connection setups and thus will scale much better under a DDoS attack. The risk you have mitigated is that the firewall’s state table will fill up during a DDoS attack and cause an outage to your website. You will sacrifice some things as well – you will not be using the latest application level filters in today’s firewalls, and you will not be writing granular access rules. ACLs on routers need to be short and fast.

Truth is, I’ve been recommending and building web farms using this method for years.  We just tell the auditor the load balancer is the Policy Enforcement Point (PEP) and never use the word firewall.  If they ask about firewalls, I always refer back to PEPs.  The fact is, many things are actually firewalls; they control connections, limit risk, and provide boundaries for trust. For example, your SPAM filter is simply an application level firewall for email, so why not use a load balancer as your web farm firewall?

So when the risk of the firewall outweighs the rewards of its filtering rethink your solution. Does this mean you should stop using firewalls? No way. They are your defensive perimeter.  Web farms without firewalls in front of them had better have firewalls between them and the rest of your infrastructure.

Think I’m crazy, completely disagree with me, let me know.  Use the comments to give me you ideas, or to completely agree with me.

-Michael

Tweet This Post

We’ll keep you updated from the show – check out our twitter account and our facebook page.

If you’re attending please drop by our booth and say hello!

Reuven

Tweet This Post