How to create an effective application security budget

Inadequately secured software ranks amongst the most significant root cause issues in cybersecurity. The frequency and severity of attacks on the application layer is greater than that at the network layer, yet research shows that network security receives double the budget. According to Ponemon Institute, 18 percent of IT security budgets are dedicated to application security, while 39 percent is allocated to network security. As a result, organizations suffer from not having ample resources to detect vulnerabilities in applications.

Ensuring the security of software is difficult. Unlike network security, where a single control like patch management can impact large parts of a company’s infrastructure, the security of software differs with each unique application.

Improving software security involves interacting directly with internal development teams, business stakeholders and third-party vendors, rather than simply the back-end IT team. It also means integrating security into the development lifecycle in a way that doesn’t become a bottleneck to rapid release cycles or puts undue strain on available resources and existing budgets.

The growth in mobile, IoT and cloud-based applications will continue to significantly affect the application security risk landscape, forcing enterprises to broaden their view of security to address the application layer that can expose sensitive data. Not knowing how to properly budget for application security has many organizations relying on ineffective and insufficient scanners that only detect half of known vulnerabilities – leaving a gaping hole in any security program.

Here are some helpful tips on how to create an effective application security budget, one that can easily scale to meet both the application security and business goals of an organization now, and in the future.

1. Invest in metrics

Metrics drive action and allow you to quantify your goals. Don’t fall into the trap like 77% of financial institutions who rely on number of vulnerabilities. Build specific sets of security controls for each application and measure whether they are implemented. Use security testing at the end to validate the control. Invest in people, tooling, and processes that support this. Absent of relevant metrics, you will not have an effective governance process and you will not drive change in your organization’s development process.

Read “how to measure anything in cyber security risk” and determine how to shift away from ordinal risk values like low, medium and high and adopt metrics the board will understand: expected loss.

2. Educate your staff

You will face strong resistance to your application security program in its early years. From our survey, we found that every company that had effectively deployed an application security program invested in educating technology executives, business unit leaders, and engineering teams specifically on secure development. It is a necessary prerequisite to gain acceptance of further activities.

3. The three test trap

Many companies invest their entire limited application security budget in three forms of testing: SAST, DAST, and penetration testing. While all three have value, relying on them exclusively leaves you exposed. Data from Whitehat and Veracode suggests that half of all detected vulnerabilities go unremediated. Of those that get remediated, vulnerabilities remain in production for over 300 days on average. Ensure your program can deal with real time vulnerabilities in production. Use RASP, WAFs or network security products to ensure you can virtually patch your software. Apportion sufficient funds to “shift left” activities that can scale: software security requirements management and/or threat modeling with tool support so that you have fewer vulnerabilities to begin with.

4. Hire the right people

Application security is complex. Deploying any real-world process or tool begins with having the right talent in place. Ensure you are adequately staffed with the right skillsets. Employ specialized training or use third party vendors to shore up any gaps.

5. Shift the risk

Third-party software is one of the biggest risks to your organization. Significant portions of your information security budget likely go towards managing the risk from this third-party software. Take steps to shift some of that risk back. You probably have a vendor security management processes based on broad standards like ISO 27001/2. It likely has some treatment of application security, but not nearly enough to cover the breadth of secure SDLC activities you need from a software vendor. Require vendors, including SaaS vendors, to apply a more robust software security framework, such as ISO 27034, vBSIMM, or Microsoft’s SDL.

You can do this in three ways: 1. Require software vendors to adopt such a framework in contract language; 2. Include these frameworks in RFP criteria; 3. Request to see secure SDLC details from existing suppliers. You may not have sufficient leverage to get vendors to change their practices on your own, but if enough of the vendors’ clients are asking the same questions then their product management teams will take notice.