IronBee Open Source

Web Application Firewall

Building a universal web application firewall engine

www.ironbee.com

Introduction
Qualys is announcing the development of IronBee, a new open source project to build a universal web
application security sensor. Our desire is not only to build the code and the rules, but also to focus on
building a community around the project. In fact, we believe that building the community is the most
important aspect of the project and the only way to ensure that it has a long life.

The Need for Web Application Security Monitoring

Why do we need to monitor our web applications and provide additional protection measures? Because
software today is inherently insecure, and we need to manage the situation. Consider the following
contributing factors:
Software engineering is immature
We still have a long way to go until we learn how to build robust software in a predictable and
repeatable way. We are making good progress when it comes to best practices, but the average
developer still struggles.
Technology moves at a very fast pace
Innovation drives companies forward, but features often come first, and security is an
afterthought. We are playing catch-up all the time.
Businesses must move quickly
Security plays a relatively minor role in the success of a business, with many other factors having
far greater influence. Theres a fine balance between security, usability, and time to market.
Businesses generally focus on reaching the market as soon as possible, adopting a well secure
it if it succeeds attitude.
Legacy applications
Not only do we have a large backlog of existing applications, but because of the very fast pace of
development, our new applications become old virtually as soon as we deploy them.
But what does manage the situation mean? The answer depends on whom you ask. These are some of
the common use cases for application security monitoring and defense:
Compliance
Virtual patching (usually for custom applications)
Protection against known exploits (usually for well-known applications)
Application hardening (raising the bar)
Real-time application security monitoring (also known as situational awareness)
Passive continuous vulnerability assessment

Toward a Universal Web Application Security Sensor

We are proposing that the security community design, build, and deploy a universal application security
sensor. We envision a flexible framework that will be used as a foundational building block by all those
concerned with application security monitoring.
Standardization will bring the following advantages:

Higher quality and development cost savings

Developing an application security monitoring sensor is not a trivial job. It requires substantial
understanding of the key concepts, sustained development effort, and security knowledge, as
well as years of making and fixing mistakes. It is an effort that requires extensive collaboration
with everyone in the security community. It is a job that is too big to do more than once.
Universal availability
Organizations often incorporate diverse components into their infrastructures using different
software products. They also outsource parts of their infrastructure to others. Having the same
application security framework available across the board is the most efficient way for an
organization to retain security control.
Portability of security logic
With universal availability of a common framework, we can approach the ideal of write once,
use everywhere. For example, a rule that defends against a known problem in a popular web
application can be deployed everywhere, no matter what platform the application is deployed on.
Information exchange
By being able to target a single platform and freely exchange information on application security
attacks and defenses, we hope to create a thriving ecosystem for information exchange.

Its All About the Community

The success of IronBee depends on our ability to create the right conditions for the community to form
and to inspire others to join it. If we succeed, IronBee will flourish.
There are two key aspects to this success:
Liberal open source license
For a community to form and grow, everyone must be equal. Viral open source licenses often
exclude those with commercial interests and create inequality (for example, when copyright
assignment is required in order for some code to become part of the official distribution). IronBee
uses the business-friendly Apache 2.0 software license and requires no copyright assignment.
Sustainable community
The license makes us community-ready, but we are also taking the next step toward making the
project fully public and transparent, as a proper open source project should be. Furthermore,
we are structuring the project to support a variety of challenges and implementation tasks
designed to match the variety of interests and skills of the communityproviding opportunities
for everyone.

Key Technical Directions

These are our key technical directions:
Diversity of deployment modes
There is no best way to deploy an application security sensor. Some people love the embedded
sensor approach for its scalability; others accept only the reverse proxy approach because it
provides full isolation. There are many reasons why different deployment modes existsome
technical, some philosophical. The truth is that the real world is messy and that we must
deal with it. IronBee will look at a variety of deployment modes: passive, embedded, reverse
3

proxy, command-line (for batch processing), and out-of-process (in which traffic is shipped for
inspection outside the process or server of origin).
Portability
We use abstractions to make the bulk of the code independent from environmental variations.
Porting IronBee to a new environment (e.g., web server or proxy) should require only the
implementation of a very small interface layer that deals with data acquisition.
Modularity
Modularity is important for two reasons. First, new developers should be able to implement their
ideas quickly, without having to understand how the project as a whole works. We will enable this
ease of usage with good APIs and documentation. Second, deployment-time modularity allows
end-users and packagers to customize the sensor to perform well in their own environments.
Powerful functionality
We are not forgetting the users. After all, the product must address the core user needs in order
to be successful. We are going to do this by offering a range of features, each suitable for a
particular requirement. We will equally address security and usability needs with an easy-to-use
configuration language, advanced features for advanced users, and many time-saving features
on a high level of abstraction.
Technical quality
At the end of the day, it is very important that the sensor is of high qualitysecure, robust, and
efficient. Our source code is just that, with fully automated cross-platform builds and unit and
regression testing.

Key Functional Directions

IronBee implements a robust framework for application security monitoring and defense. It provides a
layered set of features at different levels of abstraction, enabling its users to choose the approach that
works best for the work they need to accomplish.
What follows is our vision of the operation of the framework, which we will use as a starting point for
determining the exact features we will implement:
1. Flexible data acquisition options (i.e., deployment modes)
2. Personality-based data processing that matches the parsing quirks in the back-end
3. A persistent data model that mirrors real-life entities such as applications, sessions, users, and
IP addresses and that allows both short-term and long-term activity tracking
4. Aggregation of historical data (from the internal data store) as well as the information from
external data sources, such as:
a. Geolocation information
b. IP address reputation
5. User agent profiling
6. An efficient data retrieval and transformation engine that provides transparent optimization
and rule prequalification, ensuring that no time is spent on needless or repetitive work
7.

Multiple pattern matchers and support for streaming inspection

8. A choice of approaches to implement custom security logic:

a. Flexible rule language suitable for 80% of all work
4

b. A high-performing scripting platform (based on Lua) for the next 19%

c. Support for compiled modules for the 1% of cases in which performance is of the highest
importance
9. Inbound and outbound traffic analysis of:
a. Protocol compliance (blacklisting and whitelisting)
b. Common attack techniques
c. Evasion techniques (on the protocol and application levels)
d. Known exploits
e. Protection for vulnerabilities in popular applications (via whitelisting)
f. Virtual patching (via whitelisting)
g. Information leakage
h. Error message detection
10. Higher-level security modules:
a. Behavioral monitoring of IP addresses, sessions, and users
b. Brute force detection
c. DoS and DDoS detection
d. Cookie encryption and signing
e. Content security policy enforcement
f. Passive vulnerabilty scanning
g. User experience monitoring
h. XML parsing and validation
11. Policy decisions
12. Tailored defense
13. Interaction with external security systems (e.g., firewalls) and data exchange

Rules
Having a good framework is great, but it is important to couple the framework with an effective rule
set that brings value to users across a broad spectrum:
Complete security coverage
Rules should provide reasonably complete coverage of application security issues.
Effectiveness
Rules should achieve their targets of detecting and preventing attacks, making it impossible (in
some cases) or substantially more difficult (in others) for attackers to succeed.
Low rate of false positives
There should be a minimal and tolerable number of false positives to handle.
Ease of use
Choosing what rules to run, how to respond to events, and how to create exceptions should not
be a burden on administrators.
5

Documentation
All rules should be well documented, with their purpose, coverage, and side effects clearly
explained.
Traceability
Every rule must be traced back to a need, which will allow users to make an informed decision
about whether that rule is needed in their environment.
Whenever possible, we will aim to remain compatible with existing solutions.

Status and Next Steps

At this time, we are looking for early adopters and those who wish to participate in shaping the project:
Developers to work on the IronBee core and on the security modules
Application defenders to tell us what they need and to provide feedback on our proposed
solutions (e.g., configuration language, signature language)
Application security researchers to exchange attack information, to write signatures and rules,
and to design new detection and protection techniques
Web server and proxy developers to help us make IronBee work in their environments
Distribution maintainers to package IronBee to run on their systems
Infrastructure and cloud providers to help make IronBee effective for embedding into their
infrastructures
We are very excited to have this opportunity to work on a critical piece of security infrastructure in
partnership with other members of the security community. We hope that you will share our enthusiasm
and join us.

Schedule
Our development roadmap is located in the IronBee wiki. We are not assigning deadlines to milestones,
but, roughly, we are working toward a goal is to have a robust version ready by the mid-2012.

About Qualys
Qualys, Inc. (www.qualys.com) is the leading provider of on-demand IT security risk and compliance
management solutions delivered as a service. Qualyss Software-as-a-Service solutions are deployed
in a matter of hours anywhere in the world, providing customers with an immediate and continuous
view of their security and compliance postures. The QualysGuard service is used today by more than
3,500 organizations in 85 countries, including 40 of the Fortune Global 100; QualysGuard performs
more than 200 million IP audits per year. Qualys has the largest vulnerability management deployment
in the world at a Fortune Global 50 company. Qualys has established strategic agreements with leading
managed service providers and consulting organizations, including BT, Etisalat, Fujitsu, IBM, I(TS)2,
LAC, SecureWorks, Symantec, Tata Communications, TELUS, and VeriSign.
Copyright 2011-2012 Qualys, Inc. All rights reserved.