Challenges with Firewall Rules

Over the course of my career, I’ve worked at several different firewall companies. Each one of them used the same approach to firewall rules, which was to start with a basic kit of core signatures, then send in professional services to manage, maintain, and customize those signatures to meet the needs of the customer.

Here’s what didn’t work about this legacy approach:

• Rule control – Customers could not easily write their own firewall rules because of the use of proprietary languages (i.e. ESI or iRules) that most teams weren’t familiar with unless they received specialized training, or behind walled gardens only accessible by vendor staff.
• Rule management – Customers couldn’t easily manage rules because all rules were stored in giant lists of config files without any source control.
• Rule ordering – Customers couldn’t manage rule dependencies, which meant that rules that ran out of order would cause false positives, or the rule configuration files would get so long that it was impossible to manage the order.
• Rule Testing – Even if a customer managed to get all the training to figure this out, rolling out rules was a problem because it is very difficult to test rules, especially blocking rules, in production without impacting production traffic.

Making Firewall Rules Better

Due to all the traditional rule building-based challenges outlined above and the pain we saw from practitioners, we at Impart Security were highly motivated since day one to make life easier for our customers. Introducing Runtime Protection Rules intentionally built with the following principles in mind:

• Composability – Since so much of a security team’s time is spent maintaining and customizing firewall rules, we wanted to make sure we made that process as efficient as possible. We did this by making it so that security teams could create adaptive rules that responded to real-world situations, rather than having to write rules based on guesswork of what-if scenarios or based on previous attacks. To do this, we built our rules engine with an overarching principle of composability where the rules themselves could reference each other and be easily assembled. Here’s a simple example: instead of relying on third-party threat intel feeds of bad IP addresses, our rules can dynamically create an update of their own ACLs (Access Control Lists) based on whether or not an IP address was observed acting maliciously.
• Runtime Integration into the Full API Lifecycle – We wanted our runtime security policies to  consider all of the relevant context when making decisions about API requests. This context comes from multiple places, such as the developer team, the application security team, the platform engineering security team, and the security operations teams.  While other solutions try to bring this context together from a reporting or monitoring standpoint, none of them are able to do it where it matters —in runtime.
• Developer Experience – At most firewall companies, rule management is, in reality, a professional services engagement using proprietary in-house tooling. As a result, if customers wanted to make a change themselves, they wouldn’t be able to due to lack of functionality in the product. Instead, they’d have to call a professional services team to make a change, which took days or weeks which was extremely aggravating. With Runtime Protection Rules, we wanted to give security teams the same empowerment as we have in house. What that means is we’ve built our Runtime Protection Rules experience to have the same developer experience standards  as the best developer tools on the market today, such as building first-class code editors, built-in functions and methods, source control, IDEs, testing harnesses, and LLMs instead of simplistic form-based rule editors that you see with most firewall products.

Taking the time to build a runtime rules engine this way is a long, yet rewarding journey. It is a lot easier to build a firewall by bolting on some open-source ModSecurity rules to a web server, hiring some professional services staff to help customers with anything they need beyond that, and glossing over the clumsiness of it all with a reporting interface.  However, when built correctly, the capabilities of a composable, developer-friendly rules platform with full decision-making context integrated into the runtime exceed the capabilities of any other architecture.

Impart’s Runtime Protection Rules Give Control Back to Security Teams

Runtime Protection Rules are one of the most powerful features in Impart’s API security platform.  We’ve taken all the lessons learned from decades of experience in the firewall space and created a solution that works for modern security teams.

Impart’s Runtime Protection Rules are composable firewall rules that allow security teams to quickly create powerful security policies, with reusable and modular rules that can be dynamically put together to provide powerful and easily customizable runtime security policies.

Unlike legacy firewall rules, which are implemented using large configuration files loaded on a firewall server, written in outdated and proprietary programming languages, and extremely difficult to maintain and manage, Impart’s Runtime Protection Rules are built using a composable architecture that offers security teams all of the perks of the most modern developer tooling, such as a native security functions, an in-product IDE,  rule testing, revision control, and integrated LLMs for summarization and recommendations.

With Impart’s Runtime Protection Rules, security teams can easily:

• use a library of built-in security functions (such as a weak password evaluator) at any phase in the an HTTP request/response flow, allowing for extremely intelligent detections of both request and response headers and bodies
• utilize math operations to customize responses and adapt to attacker behavior, enabling advanced deception techniques
• dynamically create or modify typed lists of API endpoints, IP addresses, or any other pattern, enabling adaptive security policies that respond adaptively to increasing security risk
• create rule chains to implement recursive security logic, such as managing user journeys through an e-commerce checkout or payment flow
• safely test rules before production to ensure they are behaving as expected, enabling confident deployment to critical API endpoints

‍

What’s Next for Runtime Protection Rules?

Thanks to our initial investments in a first-class developer rule-building experience, we’re now in a position to rapidly iterate and innovate on them. Adding LLM enhancements on top of our Runtime Protection Rules experience is where we are focused next, and something we’ve already started doing with improvements, such as our API firewall rule explainer.

The core work that we’ve done makes our rules more easily integrated with AI and LLMs than other other firewalls on the market, and you’ll be hearing a lot from us in this area coming soon.

To learn more about Runtime Protection Rules, contact us at try.imp.art.

‍