Our approach

We live in a world under constant cyber threat. Everything is now interconnected, and nearly every business and organization depends on applications for their critical operations. 

So, it's rich pickings for those looking to exploit application and API weaknesses and vulnerabilities. The threat landscape has increased at a frightening speed. We've moved beyond merely dealing with basic threats, to countering highly advanced and persistent attacks.  

But how bad are things, really?

The problem with traditional remediation

In an ideal world, following best cybersecurity practice, we find out that there is a vulnerability in the software we use or develop. We promptly apply a patch or remediate the issue, and the problem goes away. 

In the real world, over 63% of all reported unpatched vulnerabilities are at least two years old, according to Bitdefender. Some even date back to 2002. 

Why is this? Why do so many organizations put themselves and their customers at risk by neglecting longstanding and known flaws? 

Put simply; it's hard to stay on top of remediating. It takes time, money, and skilled resources.  

The UK's NCSC summed it up perfectly: "…is often hard to do in practice, it is time-consuming, repetitive and unrewarding, but it is the single most important thing you can do to secure your technology." 

Yet, remediating remains one of the biggest challenges for organizations. 60% of breach victims in 2019 report that they were attacked through known vulnerabilities. 62% didn't even know they were vulnerable until after the breach, and 52% were using manual procedures.

The speed of war, and the race to remediate

To paraphrase Kenna Security's Prioritization to Prediction report, it's evident that most organizations find keeping up with remediating is hard work. But it's equally apparent that cyber criminals are moving faster than ever before. 

And we agree. 

Until recently, we've been saying that the speed of war is two weeks - based on Kenna Security research saying that 50% of exploit code was published within two weeks of the publication of a common vulnerability and exposure (CVE).  

Well, that's old news. Now, say Kenna, over 50% of vulnerabilities (known to be exploited in the wild) already have code available to exploit them within a day of publication. One month after a CVE is published, 75% have been weaponized. So, the speed of war is now less than one day.  

The race starts when the CVE is reserved, not published. And this is typically three months before the patch is even made available.

The state of play according to Kenna Security research


of vulnerabilities already have code available to exploit them within a day of publication


of vulnerabilities have been weaponized one month after CVE is published

Finding a way to fix penetration test findings - faster

Andy Prow (founder of Aura InfoSec, New Zealand's largest penetration testing firm) and Sam Pickles (an enterprise security technology stalwart), and Graeme Neilson (renowned security researcher) saw organizations struggling to remediate known vulnerabilities.  

"Finding problems that didn't go away, was really the beginning of RedShield," says Prow. "Many businesses are challenged by their lack of knowledge, or budget, or having to prioritize what gets done next. So, they have to accept the risk of vulnerabilities identified by pen testing - especially when it comes to end-of-life systems - or stop everything and get developers to fix the code." 

Recognizing there was a 'bow wave', particularly in the highly exposed web application and API space, and organizations couldn't afford to wait years to address pen test findings, Prow,  Pickles, and Neilson  founded RedShield.

What is shielding?

Web Application Shields are code designed to fix an otherwise exploitable vulnerability in an application.  

When an application vulnerability is identified, our engineers determine the triggering event or events in the application traffic flow. They then develop a shield that triggers on the event. Our team have been doing this for years and now we have a library of over 14000 shields ready to go. So if you identify a vulnerability, we are likely to already have the shield ready and can deploy immediately.

The shields are built to modify or transform requests and responses in the traffic flow. They either make the vulnerability undiscoverable or nullify the associated exploit.  

And best of all, it's all done without touching your underlying application code. In fact, access to the code isn't even required, so shields can work for applications written by a third-party, frameworks, and hosting platforms.

Our shield library




Attacks mitigated by shields

What are the benefits of shielding?

Shielding addresses two of the biggest challenges your organization will face. Dealing with a lack of resources and countering a rapidly expanding attack surface.

Solving the people problem

While you may have the tools you need, so what? There's a worldwide skills shortage in cybersecurity, which means finding people with the capability even to use your tools can be difficult. 

That's why, core to RedShield's managed application security service, is not only the technical tools we use but a skilled team of application security engineers and analysts. Together, our people scan, monitor, and if they find vulnerabilities - write and deploy shields to ensure your applications and APIs remain available and secure. And because cybercriminals never sleep, they're on call 24x7.

Addressing complex vulnerabilities

As applications become more complex in their design with an increased number of sub-components enabling additional functionality and speed, so too their attack surface expands exponentially. 

Defenses need to be layered, constantly reconfigured against known threats, be multifaceted, and possess a specific logic or intelligence in the way they handle incoming data. 

Shields protect your vulnerable applications from the flood of cyberattacks, so it's business as usual until you can remediate or patch the weaknesses.

Securing cloud applications

Every cloud operator has a security 'division of responsibility' disclosure. They outline that as part of their hosting service, they will secure the infrastructure (security of the cloud). But you are responsible for securing the application and data (security in the cloud).  Meaning you still need to configure and operate these tools.

The commitment to gaining, training, and retaining the skilled staff to glue these and other tools into an outcome-based program far exceeds the tools' cost and then takes years to mature.  

Outsourcing to RedShield is an affordable and highly effective alternative. 

See how we can shield your web applications and APIs

Get your free trial or talk to one of our experts.

Free trial
Talk to us