By Richard Yew, Principal Product Manager – Security Solutions
One year ago this week, credit reporting agency Equifax revealed it had been hacked. Identity thieves took confidential information from more than 140 million Americans, including social security numbers and other personal data via a software flaw in a web component known as Apache Struts. This high-profile breach prompted executives across nearly every industry to mandate a review of their security operations to prevent a similar loss in data, consumer trust, and a decline in stock price. And with the August 22 disclosure of a new Apache Struts vulnerability, security teams are once again taking action to mitigate zero-day vulnerabilities on their software stack.
Zero-day vulnerabilities are unknown exploits that expose a vulnerability in software or hardware. These vulnerabilities create complicated problems well before anyone realizes something is wrong, but once the vulnerability becomes known, developers have an opportunity to patch their system.
The reality is that most organizations find it challenging to manage their software stack. This issue is compounded by human error, making it very difficult to get every patch right, every time. Various researchers have found that on average, it can take 60 to 150 days to patch a vulnerability.
Case in point, the first 2017 Apache Struts vulnerability, which led to the first Equifax breach, was discovered in February 2017. Apache released a patch in March 2017, but Equifax’s systems remained unpatched for months. Attackers used this time to mount a sophisticated, multilayered breach that remained hidden until Equifax noticed suspicious activity and started taking actions to lock down the web application. But it was too late, and the damage had already been done. Millions of confidential records were stolen.
A Web Application Firewall (WAF) can protect against the latest application layer attacks, providing a virtual patch and offering protection as threats evolve in near real time, and as organizations work to put those patches into production. Once the Apache Struts vulnerability was known, an updated WAF profile (assuming the WAF platform had the ability to filter at the header level) could have prevented this type of breach. Working together with your other layers of defense, a WAF can protect your web application from known vulnerabilities (such as before a patch is released), or when your organization can’t apply it at present (due to process, human or systems-induced delays).
A WAF front-ends your web application to block bad traffic before it hits your infrastructure (which is good), but can also interfere with legitimate traffic (which is not good). Blocking legitimate traffic is called a false positive. It happens when your well-intentioned WAF starts blocking real users from accessing your web application. It’s why WAF providers (including Verizon Digital Media Services) recommend testing new profiles for up to two weeks on live production traffic. Running a parallel profile on production traffic is the best way to ensure you get statistically significant sample sizes for more accurate fine-tuning.
Many organizations are reluctant to block legitimate users while testing a WAF configuration for a new rule on production traffic, so they turn off the WAF mitigation mode. Doing so protects users from being blocked by the new rule during the testing period, but also means that during the testing period, your web application is open to all vulnerabilities, because it is not actively blocking traffic due to the risk of false positives. Some security teams may opt to add the new WAF rule without testing, but this would upset your dev teams as it bypasses change management processes and could break other parts of your web application.
The competing interests of security and availability are leaving organizations hamstrung. Unfortunately, while they’re trying to decide which is more important, the next big threat occurs. Teams move on to fight the fire in front of them, and the older vulnerability gets pushed to a line item on a spreadsheet or Jira backlog to be followed up down the road. As the technical to-do list increases, so too does the risk of a breach.
The real security risk for many organizations comes from an inability to execute. Their tools don’t give them the flexibility to navigate around organizational processes and roadblocks. They are so afraid of the short-term damage of a service disruption due to false positives, taking security offline, or bypassing development processes, that they leave their systems exposed to new threats.
To help overcome this organizational quagmire we created Dual WAF mode. Our Dual WAF mode empowers your security teams to test new WAF profiles for emerging and new threats without creating gaps in your defenses. Here’s how it works:
These three simple steps can help you avoid the organizational quagmire that leaves web applications and systems vulnerabilities exposed to attackers. By utilizing our Dual WAF mode, you can keep your site protected while testing and tuning new WAF profiles, addressing zero-day vulnerabilities more quickly, with zero downtime.
Testing on production traffic changes your WAF from a static appliance to a more dynamic tool that sees more. With more active testing, you can alert your organization to new threats and even in-progress application attacks that have slipped past your perimeter defenses. When you can test rules without taking down your WAF or adding to the risk of false positives, you are more likely to test more rules, which in the end, will give you a better performing WAF and a more secure web application.