IronBee – Open Source Web Application Firewall

IronBee Logo

Qualys, Inc. just recently announced IronBee,  a new open source web application firewall project.

The project appears to be funded mainly by Qualys, Inc, but Akamai also appears to have some influence based on the press release published on Feb 14, 2011.

This new project is led by some of the same folks that originally developed ModSecurity, but appears to be more focused towards widespread usability and a “cloud” or Software as a Service design.

Why WAF?

Web Applications Firewalls (WAF’s) are not used nearly enough where they could be helpful to block web application vulnerabilities.

When I have discussed the non-usage of WAF”s with various folks that manage webservers, their answer was that they added another layer of complexity they did not want to manage.

IronBee seems to be answering many of the issues folks have had with WAF’s by offering…

  • Ease of implemenation
  • Portability of rules
  • Flexibility of implementation

There are many reasons to use a WAF, and projects such as IronBee are reducing the reasons not to use one.

The Business of Web Application Security

  • I can see Akamai using IronBee as part of their WAF solution offered to customers.The flexibility of implementation may save them costs over their current WAF solutions.
  • Companies like Qualys  could offer a cloud based WAF like IronBee to help protect the customers that are already using their vulnerability scanning services.
  • Web Hosting providers like RackSpace or GoDaddy could more easily offer a WAF like IronBee as a default part of their service, or charge a slightly higher fee to protect your website with a WAF. This concept is already being used with HyperGuard on Amazon Web Services.

I’ll be keeping track of the IronBee project, and possibly offering help where I can.

PCI Penetration Testing

The Payment Card Industry Data Security Standard requirement 11.3  requires that you perform annual external and internal penetration testing that also includes application testing. Below is a guide on how to handle your testing requirements.

*Disclaimer* Every company and situation is different when it comes to PCI. Always communicate with QSA(s) when planning your testing to ensure that you are meeting all the needed requirements.

Scope –

First you have to decide how you are going to define the scope of what is going to be tested. This includes which networks and applications are to be tested. This scoping process may also include deciding what type of testing will be done such as black-box, white-box, goal based, etc… The PCI-DSS leaves this scope determination up to your company.

  • Be completely transparent on the possible ingress and egress points to your PCI data.
  • The goal is to find out your weak points, not to stump the penetration testers.
  • If you are limited by cost on the number of IP’s that can be penetration tested, then I would ask if the testers could start with the 3 sets of information below and come up with their own limited list of IP’s to test, or do this yourself.

I’ll refer to these 3 sets of information below as the 3 core vulnerability information sources.

  1. Full vulnerability scan (unauthenticated or authenticated)
  2. Firewall rule exports
  3. Network diagrams

External Network –

  • Start with the 3 core vulnerability information sources to determine your testing targets.
  • Perform specific application testing on your sites that handle any type of PCI data.

Once your sites start coming up clean regularly, you should consider moving to authenticated testing if you aren’t already doing that type of testing.

Internal Network –

  • Start with the 3 core vulnerability information sources to determine your testing targets.
  • Hand over information on any specific solutions and dataflows that handle PCI data.
  • Use those firewall rule exports so you don’t forget to test the servers that have connectivity into your PCI data network if it is separated from your other networks.


  • Focus on any applications that handle PCI data.
  • Do not limit testing to only PCI data handling applications. You should also do penetration testing on system management applications, software distribution applications etc..
  • The best application penetration test is to do a source code review in coordination with functional testing.


Once you have all the results back from the testing your real work begins.

  • Take a risk based approach to determine what needs remediation.
  • There is flexibility in your remediation under the PCI-DSS, so chose a logical and consistent manner in how you choose to remediate issues.

As always, it would be good to get your approach approved by a QSA if possible.

Final Thoughts…

The goal of penetration testing is to simulate a malicious (or curious) hacker’s attempt to access sensitive data or systems. You should view this as an opportunity to improve security and not a threat.

Be transparent, use good testers, and try to change your testers every couple of years.  Penetration testing is often more of an art than a science, so different people will often find different holes.