Securing DevOps and Web Applications Testing
Insecure apps now a widespread problem
According to the “Analysis of Web Apps Reveals Current Top Security Threats” article, companies are struggling to contain vulnerabilities in web applications.
It takes an average organization thirty-four days to patch a high-severity web application vulnerability, according to the study of more than 316 million security incidents by tCell.
The analysis identified two main trends: attempted Cross-Site Scripting (XSS) and SQL Injection attacks, and revealed that 90 percent of in-production applications had a known vulnerability and 30 percent of applications had a critical vulnerability.
These statistics confirm the well-documented problems for web applications - companies are failing to build security early into the SDLC and to identify the correlated risks across applications and the infrastructure they run on. To make it worst, when vulnerabilities are identified, companies do not have the time or the means (–knowledge/skills) to resolve them. Our own survey revealed that 42 percent of IT professionals ignore critical security issues when they don’t know how to fix them (16 percent) or don’t have the time to address them (26 percent)
Traditional perimeter and WAF won’t protect you (from everything)
The conventional wisdom is that network firewalls will secure companies networks but won’t protect the websites and web applications behind.
They are not able to analyze web traffic sent to and from the web applications for example, and it will not be able to defend against any malicious requests sent by hacker launching SQL injection or Cross-Site Scripting attacks.
Most companies already understand that and use a web application firewall (WAF) to inspect and filter web traffic. No doubt WAF can identify attacks sent by someone trying to exploit a vulnerability and block all malicious connections; however, this solution can't prevent all potential breaches because:
- Only known vulnerabilities will be identified
- Effectiveness depends on customization and configuration, requiring precise knowledge of each application
- Scalability issue – the high spec configuration and dynamic nature of web apps demands higher operational workload than most other security solutions
- Remediation won’t be applied automatically
- As all other solution, it can have vulnerabilities
With the continued adoption of DevOps and the diminishing efficacy of WAF solutions, companies should look to the new paradigm of DevSecOps – where security is built into development from the start to prevent vulnerabilities from making into production.
How to improve web applications testing with the right tools and process
To achieve a more robust security posture for your Applications (and of course your wider IT infrastructure), in an agile, cloud-driven world an organisation needs to throw away the old legacy security handbook and embrace the new mind shift that is DevSecOps, and accept that the pace of change today means treating security in the old legacy silo’d way will not slow down the hackers.
Firstly- legacy perimeter security technologies has a part to play. If you think about it, these technologies are good at stopping the known. Using them helps you to mitigate the lower, less serious risks through virtual patching, rather than attempting to code fix or patch every single vulnerability. They can buy you some time.
Secondly, the DevSecOps movement encourages shifting left in your approach. Test often and test early in the SDLC to catch problems when they are still relatively cost effective to fix. If you just do Pen testing today, can you do it smarter? Can you add your own DAST or SAST tools to the process?
And thirdly, perhaps most importantly, the tools you choose to integrate with the Developers toolchains must allow them to become more involved in reducing the security risk. Giving them the power to run security tests, see the results without the need to look at the security tools UI or leave the comfort of their own working environment and tool sets.