Developers are cranking out code faster than ever, and the threat landscape is growing and changing at an equally fast pace – all while the number of skilled security professionals is at an all-time low. If your application security strategy is to test code after it’s completed, then scramble to fix whatever’s broken, or worse, patch vulnerabilities in code as you hear about them, you won’t be able to keep up, and you’re giving the cyberattackers an edge.
CIO Magazine found that a typical $500 million-plus enterprise has developed more than 3,079 applications. At the same time, web application attacks are now the most frequent pattern in confirmed breaches (2016 Verizon Data Breach Investigations Report), and the OWASP Top 10 list of security vulnerabilities is continually changing. Finally, CSO recently reported that there were 1 million cybersecurity job openings entering 2016 – with a projected shortfall of 1.5 million by 2019.
The solution? Start by changing the way you think about application security. You won’t keep up with the bad guys if you think of it as an activity you add onto the end of the development process. Here are four good places to start.
A Solution That Scales
The lack of security resources, combined with the rapid pace of development, means that your application landscape is growing faster than you can secure it – unless you have a cloud-based solution that can easily scale along with your growing application landscape.
In fact, a recent Forrester Research study that examined the Total Economic Impact® (TEI) of switching from an on-premises to a cloud-based application security solution found that an enterprise would spend an additional $5 million (including the addition of 15 FTEs) over three years to expand an on-premises application security solution to match the scale of a cloud-based solution.
And protecting the whole application perimeter, rather than just a portion, is key. While it’s important to test critical web applications early and often, all applications on the perimeter pose an opportunity for brand damage, and some may allow attackers to pivot to a more business-critical system once compromised. In fact, some of the most damaging recent breaches stemmed from applications deemed non business-critical. You need a solution that can scale easily to incorporate your entire application landscape, not just your most critical apps.
Security in the SDLC
Today’s environment demands that you produce secure code quickly. And when security is a gate at the end of the dev process, you’ll struggle to keep up with both your development deadlines, and with the multiplying threats. Rather than tacking security onto the end of the development process – when it’s cumbersome and expensive – work it into the early stages of development:
- Integrate security into the development process: Make the application security testing process as seamless for the development team as possible. This starts with selecting a solution that allows you to integrate security assessments into the same APIs that are used for development. By adding APIs to the development tools already being used by the programming teams (JIRA, Jenkins, Team Foundation Server), security can become so integrated into the development processes that it is seamless.
- Training dev: Over time, dev teams trained on secure coding will produce more secure code more quickly. Veracode research recently found that development organizations that leverage eLearning see a 30 percent improvement in fix rate.
If a vulnerability is disclosed in an open source component, you have a limited window of time to hunt down and update every instance of that component in your applications. Take the case of a healthcare organization’s struggle when Heartbleed was disclosed. Although the organization was aware of the OpenSSL vulnerability, it was not able to find and update all versions of the component before hackers were able to breach it through the Heartbleed vulnerability.
If your application security solution enables visibility into all of the components development teams are using, as well as the versions being used, security teams can quickly patch and/or update the component version when a new vulnerability is disclosed. Otherwise, you are left trying to work faster than the criminals, which most likely won’t end well.
Vulnerabilities will get through. You’re trying to do more with less, and the speed of development is only increasing. Maybe time-to-market pressures trumped security, or maybe an app gets updated, and that introduces a vulnerability. Adding runtime protection to your application security solution gives you some time. Runtime application protection adds detection and protection features to the application runtime environment, enabling applications to “self-protect” by reconfiguring automatically, without human intervention, in response to attacks. When your apps have shields, they protect themselves when you can’t – giving you some much-needed leeway to get vulnerabilities remediated before they are exploited.
With the rapid pace of technology innovation, and the slow pace of security skill development, tacking security onto the end of your processes means you’ll be in perpetual catch-up mode – and really, you’ll never catch up. To keep up in this environment, you have to think about security early and often, and find solutions that allow you to do so.
Want more practical advice on starting and managing an application security program? Check out our new CISO Kit for Application Security.