As a result of the acquisition of Breach Security (and thus ModSecurity) by Trustwave, we thought that it was a good time to run another User Survey to get a better understanding of how the community is using ModSecurity and, most importantly, how we can make it better. We ran a survey during the month of September 2010. Thanks to everyone who took the time to respond as it will help to steer the development of ModSecurity.
We plan to run these official user surveys once a year, however don't forget that you can always voice your concerns and bring up issues on the ModSecurity mail-list and also in the Jira ticketing system. Speaking of Jira, I wanted to remind everyone that you can always log into Jira to see the latest ticket/roadmap items. And taking this one step further, you can actually VOTE on an item which will help us to prioritize which issues get fixed first and also which feature requests will make it into different versions.
You can review the complete stats here. For this blog post, however, I wanted to highlight the most interesting questions/results and provide a bit of commentary.
Analysis:
As you can see, ModSecurity is being used widely across vertical markets. It is interesting to see that the top current users are now Consultants. I attribute this mostly to the emerging importance of using ModSecurity as a Virtual Patching tool to mitigate identified vulnerabilities.
Analysis:
As mentioned in the previous section, virtual patching is probably the most popular use-case scenario for initially deploying ModSecurity (or any WAF for that matter). Some other interesting benefits are blocking technical/sensitive data leakages and also increased HTTP transactional logging. Speaking of the latter, I can attest to the effectiveness of promoting ModSecurity's Audit Engine capabilities to help with operational trouble-shooting. This is how I initially pitched deploying ModSecurity to the web server admins back in the day. By showing them complete HTTP transactions, they were able to more quickly fix issues.
Analysis:
I am hoping that the @modsecurity Twitter account will pick up some more followers. :)
Analysis:
The responses to this question were pretty much as expected. There any different ways to try and address web application security issues and organizations should use them all. The combination of conducting static/dynamic web application testing and then implementing custom virtual patches is gaining momentum as there seem to be more and more scenarios where identified vulns can't be fixed in the code at all or it will take a significant period of time. In the former case, a virtual patch is about the only option, and in the latter case, a virtual patch can at least provide some level of mitigation until the source code level fix is implemented.
Analysis:
There are two main rationales for wanting custom rule sets built for a specific piece of software -
These are constant battles with "generic" signatures as they do not know of exact attack vector locations. Application rule set packages will need to either have a listing of known vuln signatures or a positive security profile created. In either case, it will require on-going monitoring of updates to public software to identify new vulns and also create new positive security profiles when new functionality is added. Trustwave SpiderLabs is researching the feasibility of creating a real-time rules feed for newly released webappsec vulns in public software. We are are also looking at adding in learning capabilities to ModSecurity by using new Lua scripts for profiling web apps.
Analysis:
The good news is that we are working on plans to implement just about all of these features/capabilities into ModSecurity :) Keep an eye out for future updates.
Analysis:
As you can see, there is a pretty wide range of the number of sites being protected. Many users use ModSecurity just to protect one local web site while there are others who use ModSecurity to protect entire server farms consisting of hundreds of systems. That is the beauty of the embedded deployment model - scale.
Analysis:
I believe that there is a misconception that ModSecurity can only be used in an open-source/LAMP type of deployment. As evidenced by the responses to this question, ModSecurity is platform/application language agnostic. It will protect any type of web application including commercial/custom coded applications that are used for ecommerce, banking, etc...
Analysis:
This question also proves the point raised in the previous section and that is that if you have an Apache reverse proxy with ModSecurity, you can front-end any back-end web applications with WAF technology. I know of many users who use this setup to protect different back-end apps including IIS/ASP.Net types of technology.
Analysis:
Woohoo! I am glad to see that the vast majority of users are using the newest ModSecurity versions. The main hurdle to upgrading is if the currently deployed Apache version is the 1.3 branch then they can't use the newer code.
Analysis:
Pretty evenly split between embedded mode vs. proxy mode.
Analysis:
Ideally, all users would be using the OWASP CRS (with local exceptions) along with their own custom rules for identified virtual patches. I would venture to guess that the main reason why the people who are *only* using custom rules is that they ran into false positive issues with the CRS. Making exceptions easier is a major goal of future ModSecurity/CRS releases.
Analysis:
The total number of rules running may become important if you start to experience performance issues such as higher latency of transactions or spikes in CPU/RAM. The total number of rules isn't usually the biggest concern but rather if you have any specific rules that are not performing well.
Analysis:
This is an interesting question when you consider how much time the average user has to review ModSecurity alerts/audit log data. Keep in mind that this number is usually impacted by both untuned rules and by the amount of attack traffic you receive. Even if you tune your rules, however, you may still get a rather large number of events if your site is actively being probed/attacked. If you want high fidelity alerts (meaning ones in which you may need to take some form of incident response action upon) then you will have to spend a bit of time up front to tune your rules.
Analysis:
Managing ModSecurity audit events is a critical issue from a situational awareness perspective. The two best options currently are:
Analysis:
This task is certainly tricky... It is often tough for the average user to confirm if a ModSecurity event is accurate or may need some level of tuning to handle authorized functionality. When I work with commercial customers who are implementing WAFs, I often refer them to the excellent OWASP Best Practices: Use of Web Application Firewall document. Specifically, organizations should make sure that they have the proper staff to administer the WAF. In this case, we are referring to the WAF Application Manager role:
Analysis:
In general, a false positive rate of >10% isn't bad. The main issue is when you fact in any blocking methods being used. If a rule is incorrectly disrupting non-malicious user activities then it can become a big problem. Interestingly, anyone who actually answered this question is more then likely in a smaller subset of ModSecurity users who actually do spend time reviewing their logs! People who don't review their logs can't answer this question.
Analysis:
The people who answered the they are in DetectionOnly mode more than likely don't have enough time to properly tune their rules to their application environment which means they have a higher degree of false positives. The users who answered that they are in a Blocking mode have been able to tune and therefore have a higher comfort level with taking action.
Analysis:
Let me ask a question - an attacker figures out some sort of evasion for your current signatures, how are you ever going to know what happened? Or look at it from this perspective - say that you identify someone attacking your site and then you initiate incident response and the CISO asks you to provide logs of *everything* that user did. Will you be able to do this? Unfortunately, most users run ModSecurity in an "Alert-centric" mode in which audit logs are only created when rules match. This is a shame as it is missing one of its greatest strengths - HTTP Auditing. If you want to do session reconstruction, you MUST audit log all transactions. Now, this being said, you can still choose to not log requests for static content (such as images, etc...) and this will drastically cut down on the number of transactions being logged.
Analysis:
While there are use-cases for utilizing different disruptive actions, I am becoming more and more of a fan simply emulating how the application responds currently to similar threats. Does it do a redirect back to the homepage or throw a 403 alerts? Whatever it is, simply mimic that response so that it is not as easy for an advanced attacker to enumerate that fact that you are running a WAF.
Analysis:
Hopefully the new "Advanced Topic of the Week" blogpost series is helping to shed some light on these features and capabilities.
Analysis:
As I mentioned in the previous section, we are trying to provide more data about how to actually use these advanced ModSecurity features.