Why WAFY exists.

WAFY was founded by Graham Mattingley, who has built well over 1,000 F5 ASM policies protecting some of the world's leading and most critical applications.

The problem

Effective WAF management sits at the intersection of three disciplines.

The problem is not simply finding somebody who knows F5 ASM. Effective WAF management sits at the intersection of three different disciplines.

It is unusual to find all three in the same person. A security specialist may understand the vulnerability. A developer may understand the application. An F5 engineer may understand how ASM can mitigate it. WAFY brings those three perspectives together.

14 years F5 ASM experience

How to configure, tune and enforce the protection.

20 years application-security and OWASP knowledge

What the vulnerabilities are and how applications are attacked.

30 years application-development experience

Where those vulnerabilities come from and how applications actually behave.

How the work really happens

ASM isn't a full-time job. It is a continuous one.

An ASM policy is not something you build once and finish.

You make a change, observe real traffic, review the resulting learning suggestions and then decide whether the policy needs tightening or loosening. Then you observe again.

That cycle continues for as long as the application continues to change.

This creates an awkward staffing problem. Most individual policies do not require somebody working on them all day, but they do require somebody to return to them consistently. Hiring a full-time specialist only makes economic sense when there is enough ASM work across a very large number of policies to occupy that person continuously.

WAFY is built around the way the work actually happens: recurring specialist attention across a portfolio of policies rather than a full-time engineer waiting for the next thing to change.

The gap we close

Applications change. WAF policies often don't.

In many organisations, the application and the WAF are owned by different teams.

Developers release new functionality. Parameters, URLs, payloads and behaviours change. But nobody makes the corresponding decision about what the ASM policy should now allow, learn or enforce.

The predictable response is to leave the WAF looser than it needs to be. That makes deployments easier and reduces false positives, but it also means protection gradually falls behind the application it is supposed to protect.

WAFY closes that gap by continuously reviewing what ASM is learning from real application traffic and adjusting the policy as the application evolves.

A rare advantage

We can talk to developers as developers.

When a WAF blocks legitimate application traffic, fixing it properly requires understanding more than the F5 violation message.

With decades of application-development experience, WAFY can look at the request in application terms: the URL, query string, parameters, payload, data types and the behaviour the application is trying to implement.

That means we can explain an issue to a development team in their language rather than simply reporting what ASM blocked, which gives security, infrastructure and development a much clearer conversation and a better decision about whether the application or the WAF policy should change.

The real benefit is a much faster route to mitigation. Because the issue is understood on both sides, the F5 and the application, we resolve it on the WAF immediately while the proper application fix is worked out, instead of waiting for a change to be built in pre-production and promoted to production.

We test, stage and adjust the enforcement on the F5 there and then, pin down exactly what the application requires, and mitigate in production straight away. The agreed fix is normally ASM first, application second: short-term we restage or relax the specific piece of enforcement so legitimate traffic flows again; long-term we work with the developers on the permanent change.

Because we hand the development team the exact requirement, already proven on the F5, they are not guessing. Their non-prod, pre-prod and production promotion is drastically shorter, because the fix is known before it ever enters their pipeline.

When a deployment breaks something

When a deployment causes a problem, we own the WAF side of it.

Applications change through releases, CI/CD pipelines, configuration changes and new functionality. Sometimes those changes collide with an existing ASM policy.

When that happens, WAFY takes responsibility for resolving the WAF issue.

First, we restore legitimate application traffic quickly. That may mean temporarily restaging an entity or relaxing a specific piece of enforcement.

Then we investigate what changed and make the proper policy adjustment so that the required application behaviour is allowed without leaving the policy unnecessarily loose.

Restore the application first. Understand the change. Then tighten the policy back around the new requirement.

Get started

Let us run your Advanced WAF.

Tell us about your applications and the state of your policies. We'll tell you which tier fits and how quickly we can pick them up.

Book a call See what you'd get