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

50%

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

75%

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.