IronBee Open Source
Web Application Firewall
Building a universal web application firewall engine
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.
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
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
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.
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. Qualys’s 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.
