An all too familiar scene repeated itself two weeks ago. My good friend & CISO of a mid-sized technology company, lets call him Alok, went into a budget planning meeting and came out as a shadow of his former self. To be more precise a 85% version of the Alok that I know. He had just been handed a 15% reduction in budget.
Like most managers, Alok, started taking stock of his mini-empire and prioritizing things that he could do without. Luckily he had already expected a cut and so had planned ahead. Unluckily, he had planned for a 6% reduction not a 15% reduction. After some brainstorming and taking some tough decisions he had cut costs by 10%. Now began his quest for the elusive final 5%. His organization had started the transition from being a network security centric organization to a more application security centric organization around 15 months ago. So, a solution posed by one of his managers was to drop the security engineering process integration program and replace it with a set of static analysis tools they had just evaluated. This strategy had paid of handsomely for them in the network security field. Ron, one of the leading application architects in the organization was opposed to the idea. Thus started a turf war, which left some angry, most frustrated and everyone confused.
Unlike most managers, Alok reached out for advice. He asked me to share my experience with customers in similar budgetary situations & maturity. This is how our conversation went:
Alok: So I think the automated security tools can help us reduce risk and save us money. Unfortunately, I have to reduce budget and I’m thinking of buying <snip> tool to drive efficiency. What do you think?
Akshay: I’m sorry that you have had a budget cut. A lot of my clients have been facing a similar situation. Before I answer your question can you tell me what value you expect to derive from the tool?
Alok: We are looking to get standardized security bugs and find all the vulnerabilities that exist in our code base.
Akshay: Do you know how the tool compares to a manual security code review. I mean, what kind of coverage does it give you? And is that coverage good enough for your organization?
Alok: No, we haven’t examined that. Assume that it is. Should we go ahead? You know I can get more done with less by buying the tool and getting rid of my contingent vendor staff.
Akshay: Well, the tool that you mentioned will need to be used by both your development team and your security team. Have you considered the cost of training people to use it?
Alok: No. What other impacts and costs may there be?
Akshay: I imagine the development staff is also being reduced. I imagine that they will resist taking on additional work while having to let go off people. In my experience when clients by static analysis or other tools , a large portion of them end up as shelfware. Not enough thought is given to how to integrate this in existing into development lifecycles. Application security is fundamentally a process problem and you can’t solve it just by using tools.
In my opinion, this is a great time for forward looking organizations to re-engineer their development process to integrate security into the process. People are the biggest resistors of change. Culture change is the toughest challenge when moving to a SDL like process. The prevailing lean development team, a more malleable workforce and forward looking leadership can and should be leveraged in these tough economic times to make the organization healthier for the future.
- Akshay
