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. There’s a fine balance between security, usability, and time to market.
Businesses generally focus on reaching the market as soon as possible, adopting a we’ll 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:
2
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.
It’s 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 community—providing 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 exist—some
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 quality—secure, 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.