Application security is a weird field. On the one hand, most practitioners know that it plays a critically important part of any organizations security posture. We see real issues all the time, problems that cause our customers real losses. On the other hand, as a wise security leader once said:
By the time the AppSec companies get to the table, 90% of the budget has been committed to AV and Firewalls.
Further, standards have a lot of trouble capturing Application Security. I was recently diving into the NYDFS which mandates that companies have application security and found this broad statement:
Each Covered Entity’s cybersecurity program shall include written procedures, guidelines and standards designed to ensure the use of secure development practices for in-house developed applications utilized by the Covered Entity, and procedures for evaluating, assessing or testing the security of externally developed applications utilized by the Covered Entity within the context of the Covered Entity’s technology environment.
I mean, can you say vague and open ended? How do we know what to do based on that? How do we go to our stakeholders and tell them we need to do … something?
To answer this question, I looked to the Verizon DBIR, various standards like NIST CSF, etc. and I realized that so many of the ways we think about those categories don’t fit into one area or another. Consider a few areas that get called out: MFA, stolen credentials, insider threats, malware. Each and every one of these has an Application Security related angle. As a software developer, I do networks, store data, think about identity and generally cross concerns.
So how do we step back and think about the value of application security? Maybe we start by thinking about our risk models.
Do we have fraud paths in our applications? What can we gain by stopping fraud?
Are we subject to standards? Do we have partners that gate software purchases based on our security posture? In that case, security is a part of our value for those partners.
In practice, models like the OWASP ASVS, OpenSAMM and others help to give us structure to think about application security. They don’t necessarily help us know how to think about costs or appropriate expenditure…
So I guess its hard to answer this question. We can say that we have “annualized loss expectancy” or other models … we can look at a company like Equifax and see the significant changes to that company’s stock price. Generally, most models I’ve seen are speculative at best.
Through many projects building appsec programs, we have developed a practice that we can use to:
- Size a program based on stakeholders, standards and goals
- Inventory applications
- Project costs and timelines
But the assumptions we make and the framework we use to do that is reactive and based upon stakeholder feedback.
How can we learn to build a better model that provides better proactive guidance for spending on application security?