Five Common Pitfalls in Application Protection
This post is also available in: French German Italian Portuguese (Brazil) Spanish Russian
Every year, companies spend a lot of money on the latest security technologies to protect data confidentiality and the user experience. CISOs go for machine learning, automation, orchestration of event analysis and response, and trust the public cloud providers and their system integrator. However with this mindset it’s not enough, data breaches still occur and application protection has been neglected.
1st pitfall – “I thought a WAF was enough“
Ignoring the additional threats to applications have long gone beyond exploits taking advantage of the top 10 risks to web applications listed by OWASP. Yes, injections, cross-site scripting, CSRF, session hijacking, and cookie poisoning and alike are still very valid, especially when there are so many unpatched legacy systems out there. Development teams are putting more emphasis on agility than security. However, the attack surface, and therefore exposure to risks is much greater today.
Three more threats to battle:
- Bad bots –A quarter of the internet traffic is generated by malicious bots[CB1] . With the load on networks and persistent attempts to take over user accounts, manipulate online transactions and scrape sensitive data, organizations cannot rely only on their web application firewall – or worse, waste time in creating home-grown tailor-made scripts – and start thinking about a dedicated bot management technology. Such that accurately lets good bots in and fends the nefarious ones off.
- API protection – interconnected systems and applications that exchange data via APIs. These are typically trusted and therefore can be easily overlooked. Data theft through under-protected APIs has made it to the news several times already (PaneraBread, Venmo, Boots and more). Organizations do not always know about all the APIs they have, which kind of data they are processing and who can access them. They need a good tool for discovering, classifying, and securing all their API Endpoints.
- Denial of Service – long since the days when this was a problem of the network operators. Web servers and digital assets are now frequently targeted by adversaries willing to disrupt service or take down a website. It makes total sense to integrate high-volume ddos protection as part of the application security strategy.
2nd pitfall – “I was tempted to bundle my WAF with the CDN service”
Yes, it makes total sense. If you care about performance more than your customer-sensitive data, that might be the way to go. But if you have some accountability for protecting the company and user data, you have to rethink this compromise. By the nature of the architecture, WAF at the network edge does not see the traffic per application, and therefore can’t apply any learning mechanisms, anomaly detection and positive security that result in no zero-day protection. These applications are likely to leak data as they are not protected from unknown attack techniques.
In public cloud environments, the gap is even greater as the WAF technology provided by the IaaS provider – not a specialized vendor – usually ranks low in analysts’ reports. More in our previous blog
3 pitfall – “I can enforce the same security across all platforms”
That is a real pain indeed. Willing to run the same application protection policy across all environments – data center(s), private cloud, Azure, AWS, GCP, and Alibaba or Tencent – businesses are forced to make a tradeoff. The reason is that each environment and each provider require adjustments, such as access permissions, infrastructure protection, authentication and authorization mechanisms, bot traffic controls, API security tools at the backend, and more.
If one chooses consistency (like a cloud-based managed service), then both user experience (latency) and security (see #2 above) are a compromise. Choosing security optimization will result in an endeavor to tailor the right solutions to each environment and then dedicate the time and resources to update them constantly and enforce the security policy that the CISO likes to roll out.
This unfortunate situation leads to another swiss-cheese security posture, where potential consequences can be guessed in advance. Here are some recommended practices.
[Like this post? Subscribe now to get the latest Radware content in your inbox weekly plus exclusive access to Radware’s Premium Content. ]
4th pitfall – “I thought I could do all the exception handling myself”
Web application firewalls historically suffer from bad reputations, and for a good reason. Too many legitimate rules were blocked to rules and configurations that weren’t in line with the business requirements. When that happens, the cost can be devastating – bad user experience leads to a negative stance towards the brand and diminishing conversion rates. The TCO of managing a WAF in-house can be very high due to this overhead labor required and is a matter for experts – especially when weighing in all the aforementioned security threats. The less-experienced eye will not see through the too-many-alerts coming from different point solutions. Consolidated appsec strategy managed by experts with advanced automation and actionable analytics substantially reduces the TCO while delivering security at speed.
[You may also like: How To Achieve Application Protection Behind AWS/Azure CDN]
5th pitfall – “I thought DevOps would listen”
Some attacks aren’t successful thanks to a weak, disjointed security posture due to broken processes and internal conflicts. The dynamics of today’s application development and security practices are such that security solutions and especially staff, can’t keep up. From a dev perspective, there are so many goodies available to design the perfect CI/CD pipeline with automated provisioning, testing, and orchestration tools. Agility is about running forward, next version, next patch, next bugfix – not slowing down to inspect every transaction and every module. Since productivity always comes first, security must play along. However, this is a delicate balance that every organization manages differently. As DevOps are gaining more influence on security related decisions, the information security staff has to take into account that an application security solution must do way more than just blocking attacks – it should integrate well into the SDLC ecosystem and be adaptive – tune the policy whenever a change to the application is introduced. It should also let DevOps the visibility they need into performance metrics and automation across environments. This way, we fix the process and everyone’s happy.
Avoiding these pitfalls will result in an application security strategy that is: