We sat down with Ben Zilberman, Application Security Director, Radware to discuss trends and insights from the company's recent The State of Web Application and API Protection Report.
How has remote working changed web application security?
When the pandemic hit, most organizations were still only testing the waters with regard to remote working. The pandemic accelerated the migration of cloud infrastructure, adding security complexities mostly around access management, role-based policies and permissions in a short period of time. To support remote workers, scalability is imperative. As such, new servers, datacenters or environments or virtual private clouds all have to be protected. Tokens, keys, and certificates are scattered all over the network. It has become increasingly difficult to control home networks and browsers that are used to access the enterprise’s business applications. The pandemic left no time for proper planning, testing, and optimizing security solutions, resulting in an increased risk of insecure data.
How does an organization's use of the cloud affect web application security?
The migration to the cloud affects web application security in different ways and having cross-environment consistency and visibility is key. Each Infrastructure as a Service (IaaS) provider requires some adjustments and customizations that makes applying coherent security across all platforms more difficult. Industry analysts’ research suggests that for the box-checkers, default application security is nowhere near that of a specialized provider. As previously mentioned, the need to scale up magnifies the need for additional security measures, but that can’t be done in an instant.
Especially, in the public cloud where enterprises are using more advanced development and delivery practices. The IaaS providers are making it easier for them to adopt to these emerging ways, so they can achieve better productivity, efficiency and scale. Microservices, serverless architectures and other API-based backend system integrations accelerate development and delivery, but often at the expense of visibility and control into security events. Transactions are made, data is exchanged and processes run without proper supervision, leading to more blind spots as far as application protections are concerned."
What are your top 3 concerns for web application security?
My three top concerns for web application security are API Protection, Bot Management, and cross-environment consistency and visibility.
DDoS is still a very common and cheap attack for hackers to execute. How does an organization protect against DDoS attacks?
In recent years we recognize a shift in DDoS attacks from targeting networks to targeting applications directly. These are sometimes harder to detect and to mitigate, and partnering with security experts is never a bad idea. As companies think about protecting from their application servers from DDoS attacks, following are some key considerations.
Start with the application code – validate inputs, make sure the app doesn’t allow too long tasks, or sends an abnormal chunk of data back to the user.
Rate limit HTTP and HTTPS requests
Add a cloud service to back you up against massive traffic volumes
Measure request and response times of TCP connections and timeout extremely slow ones to prevent low-and-slow attacks.
Block sources that consume too much memory, disk or CPU
Do not compromise quality: Look for solutions that block attacks without limiting legitimate traffic.
Automation is key: With today’s dynamic and automated attacks, the solution should not require customer intervention to keep them protected.
What advice would you have for CISOs developing a web application security strategy?
I always say, be humble and assume that security normally comes second to productivity. Take a “help me, help you” approach with your development team. Make sure you are engaged early on in the environment design stage, know the level of secure coding practices, and be picky when selecting security tools. Choose those that really integrate well into the CI/CD pipeline. Remember, you want to find the holes yourself first, and not leave it to the hackers. Battling your dev team is nothing close to what it’s like to handle a post-breach battle.