2024 starts with a new CrowdSec release! The Security Engine 1.6 is in general availability and it’s up for grabs.
We are very proud to present quite a few new and exciting things in this release, including the long-awaited Application Security Component, which some of you have already played with as part of our Beta Program.
Let’s dig in and explore what the Security Engine 1.6 is all about.
Application Security Component
This release introduces the brand new Application Security (AppSec) component allowing you to finally turn CrowdSec into a full-featured WAF. We have been aware for some time that the Security Engine is often used to protect application perimeters from a number of threats, including scalping and the usual vulnerability scans. However, to be truly efficient in this role, the Security Engine was missing a few capabilities.
- Interception of malevolent HTTP requests: Up until now, the Security Engine relied on the logs generated by the web server and thus only reacted after the initial attack. With the AppSec Component, the Security Engine can instruct the Remediation Component to block an aggressive IP, preventing it from reaching the application.
- Ability to inspect the full HTTP request: While some elements of the HTTP request end up in the logs themselves, the relevant data to inspect often doesn’t (HTTP body, HTTP headers, etc.).
The Application Security Component in the CrowdSec Security Engine leverages our existing integrations in web servers, allowing the Remediation Component to forward the request to the AppSec Component to get a pass/block verdict.
Note: Currently, we have the Nginx and OpenResty integrations ready for the AppSec Component but HAProxy, Traefik Proxy, Apache2, and more are coming very soon.
Faithful to our mindset, the goal is to provide an easy setup with a strong focus on virtual patching and low false positives, while allowing more advanced users to create powerful rules and scenarios. You can have a look at the documentation or, even better, give it a shot at the dedicated Killercoda workshop.
The Security Engine uses Coraza for the AppSec Component itself, mostly for its compatibility with mod_security’s SecRules format. The future of Mod_security itself is rather unclear — it was planned to be end-of-life this year, however, it is now being transferred to the OWASP foundation. This uncertainly has prompted a lot of users to find a replacement. While we want people to be able to capitalize on the rules they have previously written, we don’t want new users to have to deal with SecLang. So, the rules that we are writing are using a more digest DSL that is later compiled into SecRules, hiding a lot of the complexity and tediousness that would otherwise be needed.
With that being said, the purpose of including the AppSec Component in the Security Engine is rather clear.
- We want a frictionless setup: If you’re already using CrowdSec and one of the compatible Remediation Components, you’re already set. Rules are available as collections in the Hub and are just a cscli collections install away 🙂
- We focus on virtual patching: We are committed to providing a coherent set of rules addressing the most pressing vulnerabilities.
- We focus on production-first: We prefer false negatives to false positives and we want to avoid significant performance costs. We make the necessary compromises in the recommended configurations to ensure that performance is not an issue.
- We continue to improve the capabilities of both the software, the community blocklist(s), and the CTI: While we have proved in the past the CrowdSec Security Engine can be an extremely efficient tool to deal with critical vulnerabilities hitting the masses (hello, log4j), the addition of the AppSec component will allow us to deal with significantly more vulnerabilities.
However, the AppSec component doesn’t make the fallacious claim to be an “out of the box” silver bullet for application security. We focus on the pressing vulnerabilities and take our time while our Data Science Team works on more definitive solutions. An engine like mod_security isn’t fit for that mission anyway.
So, stay tuned for more updates and improvements on the new AppSec Component.
Hub revamp & alert context
For our next order of business, I want to introduce the Alert Context feature properly. While the feature was made available in version 1.5, we haven’t talked about it much, as some of the integrations were missing. The Hub is going through some significant changes, with the support for Alert Context being the most visible one. In a very concrete way, Alert Context allows you to embed extra data in your alerts for more efficient threat hunting and alert triage. As an example, here is how an alert with added context looks in the console:
When conducting recent user interviews, we realized that this feature was largely unknown, and it’s a shame because the users we introduced it to enjoyed it a lot. If you haven’t tried Alert Context yet, we encourage you to do so, and expect more updates and improvements for this feature in the future!
Other improvements
The loki datasource is now available, and for that, we owe a big thank you to lperdereau and Mathieu Lecarme for their contribution! This has been a highly-requested data source, and we’re very happy to see a significant community contribution making its way to this release. The debugging capabilities have been vastly improved, and it should help our users deal with more advanced scenarios.
That is all, folks
You can find the 1.6 version on GitHub and the detailed changelog here.
That is all for now. We hope you’re having a great start to this year, and we’ll see you soon with more news from the CrowdSec ecosystem.
As always, thank you for your tireless support, and please don’t hesitate to reach out to us on our community platforms on Discord and Discourse.
Also, don’t forget to check out our newly rolled Beta Program if you want to be among the early birds to get to play with new features and capabilities for the CrowdSec Security Engine and the CrowdSec Console!
