I had the privilege of speaking in Dublin at this year's OWASP Core Rule Set Community Summit before then attending OWASP Global AppSec immediately afterwards.

Both were terrific events and I'd like to share some thoughts on them here, plus some key takeaways for the CRS community to consider.

OWASP Core Rule Set Community Summit

The OWASP ModSecurity Core Rule Set (CRS) is a free and open-source collection of rules for use with ModSecurity and other compatible web application firewalls (WAFs). They defend web applications against a variety of attacks, including the OWASP Top Ten. CRS is the de facto open-source WAF rule set and is widely used by WAF providers, including the big three cloud providers.

I used my talk at the recent Community Summit to put forward the perspective of a CRS integrator*, as CRS forms a part of our Enterprise load balancer product:

*N.B. A CRS integrator is a company that implements the OWASP ModSecurity Core Rule Set (CRS), as part of a larger product or offering.

The WAF conundrum

The presence of a WAF is increasingly mandated by regulatory bodies, state-run organizations, and large corporations. Project tenders often assume that a WAF will be part of the package. This will only become more common in the future. As such, WAFs are being put into the hands of a wider audience. The concern is that the person responsible for WAF configuration and operation may have little or no prior experience. That's a big deal, and something we need to address.

As an example, management might assign responsibility for WAF provisioning and configuration to the networking team, because "it's just another piece of networking equipment, like a firewall, right?" (Wrong! Show this blog post to your management if they tell you that!)

With this situation in mind, it's important to strike a balance between usability and usefulness. I've seen several commercial CRS integrations and they've all been quite different. A very usable integration might consist of a list of check boxes to turn parts of the CRS on and off. Simple, but inadequate for providing more than a mere suggestion of security. A very useful integration might give a user the freedom to implement any hand written configuration they wish. That also comes with the "freedom" to accidentally shoot yourself in the foot (and easily at that).

I proposed to have formal guidelines from the CRS project, similar to an RFC (Request for Comments) document, e.g.

“A minimal CRS integration MUST allow X, Y, and Z.
A good CRS integration SHOULD provide I, J, and K.”

This would make it clear to integrators how CRS should be integrated; currently, every integrator invents their own implementation. Guidance will be especially important as WAF integrations continue to proliferate, with every content delivery network (CDN), proxy, and toaster** seemingly shipping with WAF functionality. We want to see good new CRS integrations appearing: that will benefit users, the project, and the community.

(**I'm only half-joking: my new dishwasher contains much of the code that powers the ModSecurity WAF engine...!)

Core Rule Set and general WAF training

Training remains a difficult question, one which I'm not sure there's an easy answer to. Having a good ‘useful-usable’ balance in a WAF offering helps, but taking a team with potentially little security background from a low level up to proficiency is a tall order.

There's much ground to cover, which means a lot of time is needed for training—and time is expensive. Good documentation is available, both free and paid-for, but it's often lengthy and complex.

As an integrator, the task of the internal training of engineers can be just as difficult. Using CRS might be completely different to the rest of an engineer's duties. Unless someone is both motivated and interested, training can be pointless, especially if an engineer won't be applying their new knowledge on at least a semi-regular basis. Even 'refresher' training can end up feeling like starting from scratch again: skills fade if you don't ever use them.

OWASP Global AppSec Dublin

The OWASP Global AppSec event took place over the following two days. There were great presentations from a range of speakers. Personal highlights included:

• Hacking and Defending APIs - Red and Blue make Purple
  A real standout talk from Matt Tesauro. How can you protect APIs, and how can you probe them for overlooked vulnerabilities? An informative and comprehensive walk-through using the OWASP API Security Top 10.
• GitHub Actions: Vulnerabilities, Attacks, and Counter-measures
  They're cool and useful, but are GitHub Actions vulnerable to abuse? Unsurprisingly, bad actors have abused the system for crypto mining…
• [T]OTPs are not as secure as you might believe
  Doing the maths, exactly how secure are one-time passwords? Some thought-provoking answers. (Spoiler alert: in the name of customer usability, some OTP implementations are shockingly insecure!)
• Not your parents’ cryptography – non-traditional encryption
  A tour of some novel corners of cryptography: encryption that produces searchable ciphertext, format-preserving encryption (e.g. 16-digit credit card numbers encrypted as 16-digit numbers for ease of storage), and encryption that allows mathematical operations and comparisons to be performed on the ciphertext.

OWASP name change

And finally, some breaking news… not everyone likes whimsical nods to the past, like using the term ‘information superhighway’, and OWASP felt that the “Web” in “Open Web Application Security Project” (OWASP) was starting to feel tired and too 90s.

At the event, OWASP announced a name change: the Open Worldwide Application Security Project.

More community events!

I'm hoping there'll be a CRS community summit again next year! With any luck, it'll be bigger and better. It's always great to meet up with other CRS users, to see and hear what everyone is up to, and to share knowledge and ideas. More community events, please!