Blocking in Production Requires a Modern Security DevEx

I've spoken to many security leaders who are genuinely scared of blocking in production. And I totally get it - blocking is scary. Some folks have real PTSD from past mistakes.

One security leader I talked to is still explaining an outage from a bad WAF rule—an event that happened four years ago, long before they even joined the company! That’s how much damage a poorly executed block can cause. It sticks with the team for years.

Blocking in Production: Difficult, but Not Impossible

Blocking in production is no cakewalk, but it doesn’t have to be as daunting as it seems. The key lies in how blocking policies are created and deployed.

As security continues to evolve, it's clear that software engineering skills are now a key part of the job. Yet, the way security teams build and manage policies is still worlds apart from how software engineers develop code. Many security teams are stuck using outdated tools that don’t match the efficiency and ease developers enjoy with their modern toolsets. If security is going to keep up, the tools need to evolve too—offering the same smooth, intuitive experience that developers rely on every day.

What’s the answer? We need to treat blocking policies the same way we treat complex software development—with modern Developer Experience (DevEx) baked in. This ensures that we’ve built the right safety nets and processes to make blocking predictable and reliable.

What Makes a Modern DevEx for Security teams?

These  are some essentials that make up a solid DevEx for creating effective blocking policies:

A Proper IDE:

Today, security admins create security policies mostly deciding which signatures (or vulnerabilities) to look for and address.  For example, let’s say you were designing a WAF policy to stop XSS.  Here’s a PARTIAL list of all the different signatures that you have to decide whether or not to turn on from a typical cloud provider WAF.

This isn’t a great development experience - it involves a great deal of tuning and testing, and when you are complete, it’s still not easy to understand or explain what your complete security policy is actually doing to anyone else, which reduces confidence in what you’re doing. What is needed is an IDE that lets security engineers manage security policies not just as collections of rules, but also as an actual policy with a visual representation of what these rules are actually accomplishing, clear explanations of what they do and how they work together, and and ability to layer them into a cohesive strategy that makes sense for a specific business.

Standard, Popular Programming Languages:

Try showing this typical modsecurity WAF rule to an engineer who isn’t familiar with it and having them explain it to you.

‍

Tough. No one should have to deal with a cryptic, archaic language when creating security policies.  Rules rules should be written in common, well-understood languages, so they’re easier to audit, review, and debug by almost any engineer, not just specialized security engineers.

Unit and Regression Testing:

Just like any other code, security rules need unit and regression testing. This ensures your rules won’t break things or cause an outage when deployed.  The unfortunate reality of most security tools is that security policies are rarely tested.  For example, most WAF admins will write test scripts that verify that their rule is able to detect a specific new signature they have added.  (I.e. Unit testing).  However these unit tests are done manually and are rarely comprehensive.

Past that,  WAF admins have no way to actually perform any sort of regression testing other than deploying new rules into production and observing the behavior.  This type of development pattern isn’t acceptable in modern software engineering organizations, but yet for many security teams, it is the only thing they can do.

‍

Source Control

Ever ask a security vendor for version control of their rules?  The answer you’ll probably get is that they have a Terraform provider which means that version control is your problem.  This is great for managing production deployments and code, but sometimes security teams need to rapidly iterate on security policies and rules before pushing them to production, in order to fine tune their behavior.

Modern Devex means that security engineers should have source control not just in production, but also in development and in staging environments.  Unfortunately, because most security tools don’t have a modern developer experience, this concept just doesn’t exist.

If you have a very mature security engineering organization, perhaps there is good discipline around the development and testing of security policies, but more likely this is pretty ad hoc for most security teams.

Security Teams Deserve Better

For too long, security teams have been forced to rely on outdated, cumbersome tools that make their jobs harder than they need to be. While these teams are resourceful and always find a way to get the job done, the poor developer experience (DevEx) takes its toll—leading to higher maintenance costs and slower response times. It's time for security teams to have access to tools with the same modern, efficient DevEx that developers use, empowering them to work faster and more effectively in defending against threats.

For more information, please visit us at try.imp.art and follow us on LinkedIn to stay updated with our latest product announcements.

‍