Today, applications are arguably the most important entity to keep up and running on an organization’s networks: these are the business-critical apps that allow the company to generate revenue, serve customers, and keep employees happy.
This is why it is critical that they also remain protected. As such, application security has evolved from a domain in which the focus on writing hardened code has expanded to include attention to the controls that shield apps from unauthorized use, modification, and other exploits. Web application firewalls (WAFs) have become the main category for such protection, supported by API protection. RedShield, an eight-year old security company founded out of New Zealand, has modified and supercharged the concept of the Cloud WAF. Andy Prow, CEO and Co-founder of RedShield, spoke with us recently about the company’s unique approach.
TAG Cyber: Application vulnerabilities are becoming hard for businesses to resolve. What are the more common complaints you hear about application security from your customers?
REDSHIELD: Most published breaches are caused by the exploit of vulnerabilities organizations are already aware of. This is primarily due the real-world constraints organizations face. For organizations with dedicated development, patching, and SecOps teams executing mature processes, rapid remediation of threats against applications is realistic. (Note that the average time from vulnerability disclosure to proof
of concept exploit is 2 weeks, source: Kenna Security). However, a typical organization may have 5% of their applications in this state.
For the other 95%, meeting these timelines is impractical. Development teams’ priorities, limited access to or experience with source code, patching dependencies, compliance restrictions, and tight budgets are reasons that discovered security code defects remain in development backlog and risk registers for too long. Then on the SecOps side, cleaning malicious traffic is an endless job. New issues are published every day and require continual tuning and deployment.
Nonetheless, blocking masks should not block legitimate transactions; change management and testing is a nightmare. In reality, risk acceptance becomes the norm.
By deploying custom code objects (shields) that RedShield’s developers write and maintain on the FaaS (function-as-a-service) architecture we operate, RedShield fixes vulnerabilities that are usually reserved for software developers, without touching a single line of application code. It’s no problem for us to fix legacy applications, third-party apps, API’s—all sorts, and we do this at speed.
One of the more current challenges organizations are faced with is balancing the need to maintain security while more aggressively focusing on digital transformation efforts—likely with resource constraints. To do this effectively, organizations need to enable security and development resources to focus their time on digital transformation and innovation efforts and limit the time they’re distracted by patching application vulnerabilities.
Shielding vulnerabilities helps in this regard as it removes vulnerability risk straight away and gives organizations time to decide when they might remediate the application itself. And it means development and security resources’ time isn’t constantly distracted so they can focus on more commercially productive tasks.
TAG Cyber: WAFs don’t typically include vulnerability remediation, but the first step in RedShield’s process is guided remediation. Can you explain exactly what this entails?
REDSHIELD: When supplied with a list of security defects, RedShield provides a Shielding Plan that highlights how our developers would fit each problem with the code objects that we would either get from our library or custom develop. We send the customer development team our recommendations, and they can choose to take that advice and develop the fixes themselves or have our team deploy the software object shields.
A WAF examines traffic—it has nothing to do with the functioning of an application; fundamentally it looks to protect rather than to fix. There is a small area of overlap where application-specific tuning may appear to address reported exploitable flaws, however this overlap is much smaller than many vendors state.
We, too, include WAFs as part of our solution, but we take operational responsibility for tuning both for compatibility and effectiveness whilst adhering to customer change management. We use purchased and built AI tools to assist in decision making, then automation and orchestration to ensure accurate and complete process execution. We can also provide skilled engineers and analysts to resource-strapped companies, providing our customers mature processes 24x7.
Our approach is in line with risk treatment practices developed during the industrial revolution for health and safety: Eliminate, control impact, restrict access. In our world, it looks like this:
- Eliminate: Remediate vulnerabilities right away
We’re able to deploy a code object shield for applications, often in a matter of minutes rather than the weeks, months, or even multi-year timelines typical with software remediation. This is because, over the years, we have written thousands of code objects (shields) that fix all kinds of vulnerabilities. This shield library means we can, in the majority of instances, immediately remediate vulnerabilities on companies’ risk registers without touching the application’s code. And for any unique shields that might be required, our team can write those specific shields right away (and then add those shields to our customer community shield library). - Control impact: Add further protections
We then provide a further suite of protection to reduce remaining threat surface without impacting experience. We detect and block the constantly-evolving barrage of malicious traffic without blocking customer transactions, and also test our remediation to ensure that the effectiveness of the solution and functionality is retained weekly. - Restrict access: Hunt attackers
We use both community intelligence and observed behavior to identify malicious bots or human actors. We simply stop them from being able to perform any action on web apps.
TAG Cyber: What not just block or quarantine bad apps?
REDSHIELD: That is certainly an option: turn off apps with known vulnerabilities, quarantine them, block them, etc. However, depending on the application, it has a bearing on the validity of such an approach. What if the app has business importance; can you afford to take it offline or limit usage? What if your web app is critical for taking orders and you take it offline?
For instance, a European commodities trader approached us with a trading portal which was found to have issues. Due to GDPR concerns, their legal department demanded it be taken offline immediately. As a result, the company had to revert to email, phone, and fax to convert trades. The developers stated that fixes were possible within a 6-18 month timeframe—because it is a financial trading platform, there are technical, audit, and compliance hurdles to launching a new portal. However, even at six months, that is a long time for the traders to not have a working platform. Instead, RedShield was able to fix their platform and make it fully compliant in 48 hours.
Another example we had was with a large payment provider that offers credit card and EFT-POS payments. Their software had 300+ issues; not fixing them would have resulted in either a breach (with some probability) or failed compliance. In turn, this would mean that banks would not have allowed the provider to hold client credit card details and their value as a business would have been reduced. It took six weeks for RedShield to fix all of these issues—and biggest lag was sharing information about the details of the finding. In our opinion, it’s better to shield or remediate problems rather than just blocking communication from happening. Instead, if you fix the problem, you reduce the threat surface.
Using shields, we perform functions to remediate vulnerabilities—without the client needing to involve developers, without touching application code, and we do this at speed and scale.
At RedShield we’ve also mapped our process and tooling to the framework developed by the National Institute for Occupational Safety and Health in the United States—the NIOSH risk reduction hierarchy. They know a thing or two about managing and optimizing risk, they have 150 years of experience!
To illustrate the point around blocking bad apps, let’s take at a metaphorical example of a hazardous liquid spill. Now, you could cordon off the area to make sure workers don’t go near the spill. You could produce warning signs and place them in front of the area as a warning. Or you could provide better safety boots—which would be most akin to deploying a WAF on a network. While these are certainly good steps, and they improve the immediate safety of workers, they should be done only as part of the larger hygiene sequence.
RedShield cleans up the spill, puts in new flooring to prevent future spills, updates workplace protocols, and then also provides the newer boots. You’re not only better protected than before, but you’re better protected in a safer environment.
TAG Cyber: How is a shield different from a next-gen firewall?
REDSHIELD: A next-gen firewall examines network traffic and filters traffic based on signatures or heuristics, often using IPS or signature matching technology. The first problem with IPS technology is that through encoding, padding, splitting, or encryption the payloads can be easily obfuscated and hence slide past the inspection engine. To address this, fifteen years ago the industry introduced a web application firewall (WAF), primarily designed to achieve the same outcome. WAFs typically include an internal web server, which means that the full application request is first decrypted and aggregated before the analysis step is performed. However, like IPSs, WAFs have become security tools that disrupt legitimate transactions and absorb limited resources to maintain. Their chief problems are:
- They don’t secure any insecure application transactions, causing failed audits and missed launch dates—dev teams still have to fix these;
- The controls a WAF uses, limiting what a user is allowed to do, are able to be bypassed, and these controls unavoidably lead to false positives. This second limitation led to the genesis of NG-WAFs, where the focus is to detect and block bots; real-time threat protection is no longer the goal.
NGFWs or NG-WAFs can’t resolve exploitable elements within an application, they only see as far as the rule set with which they’ve been programmed to filter traffic.
The task of resolving underpinning code or logic issues remains the responsibility of developers, and without these fixes, audits are failed, project deadlines not met, and fundamental legacy systems are forced from production.
A shield is a block of code that modifies application behavior to fix a known exploitable vulnerability. They are nano-services that become a functional part of the application. For the exploitable flaw to be secured, all traffic must flow through the shield, hence traffic is forced through a reverse proxy hosting the shield, placed in front of the application.
By ostensibly eliminating the vulnerability and thus reducing the threat surface that an attacker can exploit, the issue is resolved without the need of a development team to engage in software remediation. A shield is an in-path solution where all HTTP traffic for the application travels through RedShield, where additional protections are added before passing through to end users. Shielding doesn’t limit what a user can do, but rather changes the application transparently so that anything malicious has no effect and doesn’t disrupt the user experience.
Instead of just filtering like a WAF, shields actually fix the issue by changing the application behavior, without changing the underlying code itself. The flawed application is rendered safe while retaining its functionality—attacks are stopped, but transactions aren’t.
So while a WAF promises to protect through increasingly complicated policies, shields address the root of the problem. For example, if your app accepts weak passwords, WAF policies might be deployed to check geolocation, frequency of attempts, the method of access, time of day, or countless other data points. The problem is, as compatibility issues inevitably come to light and the challenge of constant updates and maintenance becomes apparent, most businesses make their controls less and less effective to maintain app functionality. A shield implements better behavior for the application.
TAG Cyber: You ran a pen testing company for ten years; what inspired the transition to building a security product?
REDSHIELD: After starting and building NZ’s largest pen testing company, I found that when we visited our clients to check in and re-test their applications, we found the same vulnerabilities again. Clients often found it too difficult to clean up their risk register for various reasons and were left in a situation where their security posture kept getting worse. After a while this became frustrating. RedShield was born out of this experience. Remediating all vulnerabilities found from a human pen test quickly and at scale is an area no one else is really addressing and we wanted to take on this challenge.
About Andy Prow, CEO & Co-Founder, RedShield
Andy has been in the IT industry since ‘94, starting life as a C++ programmer in the UK, going on to work as a lead developer and solutions architect for IBM NZ, Vodafone UK, Ericsson UK, and Telecom NZ.
Andy went on to found and was the managing director of Aura Information Security, New Zealand’s leading IT security consulting company, until he sold Aura to Kordia in 2015.
Andy co-founded RedShield in 2009, and is focused on accelerating the global growth of the innovative web application and API security solution.
