Every so often in my career someone new to security comes along whose is from a different industry, or who is, well, new to all fields, and comes up with a great idea that goes something like this: People don’t buy anything unless they have to or it has an ROI. What if we showed the ROI for security instead of just the argument of how it makes them compliant or reduces risk? That will make justifying our product easy. Then, and I swear I’ve heard this several times in several companies, they say – you see security doesn’t just reduce risk, it enables blah, where blah is something like internet use or e-commerce, or, more recently adoption of cloud or mobile. Then, the soliloquy continues, we can justify the security ROI as the ROI of being able to do blah. And then they’ll smile, because they just showed us security geeks that they know business!
Well, let me make something perfectly clear. Security is a cost. It does not enable anything. Criminals impede the ‘blah’ from above making an appropriate level of security a condition of doing business. Banks don’t have safes to enable banking. If all people could be trusted, all the money would be in a nice, organized inexpensive closet – without a lock. That would enable banking. Security budgets should be the minimum to achieve the security posture required. More security would be nice, but if there’s money for that more sales, marketing, or product, is always nicer. We should do the security we need plus the things in security that reduce cost. Full stop.
So, then, how do we justify Application Security? It’s the two reasons we use justify all security – it’s required to be compliant and for a minimum acceptable level of risk, and it reduces cost. On the compliance and risk side, there is ample evidence that successful attacks are focused on the application these days, both commons ones and so-called Advanced Persistent Threats (APTs). Most prescriptive compliance requirements that cover applications call for best practice process, education, and the use of scanning tools, including PCI (see control 6), NIST 800-53 (see control SA-8 among others), SANS 20 Critical Controls (see control 7) and many others.
On the cost side it gets more interesting. Application Security practice including SDLC, developer training, and the use of coding standards can make projects more efficient, reduce vulnerability management costs and reduce compliance costs. In future blogs I will go into these topics individually to show the application risks and compliance requirements as well as the cost reductions. Some of this information can be found in two separate independent analyst reports done on the subject by Aberdeen and Forrester, and made available by Microsoft. These are a good place to start. They are:
These are the business arguments for spending (let’s not hide it with the word ‘investing’) peoples’ time, money and other resources on improving Application Security SDLC, knowledge and tool sets.
