Here's a news flash - it's 2013 and enterprises are still struggling with software security.
While there are plenty of enterprises out there that have figured out a formula for making software security work for them, for every one organization that 'gets it' there are many times more organizations that are struggling with software security year over year, quarter over quarter, day after day. Why?
There are plenty of reasons we can blame these vast failures on ... immature tools, cookie-cutter processes, poor sentiment from the enterprise leadership ... blah blah blah ...bottom line is it's 2013 and companies big and small are still struggling with poor code quality, a negative dynamic between developer and security person, and other assorted issues.
I bring this up today because I've spent the day with a monstrous enterprise in the financial sector that is going through a transformation at the hands of a fantastic InfoSec leader in their new CISO. The new CISO "gets it", and understands that software security isn't something you can force on developers, even if you have the support of your CEO. Threats to fire developers, to hold up projects, and compliance fines just don't work ... and it seems counter-intuitive to those who feel like all the CISO needs is "power".
Case in point... let's take an enterprise, a "big bank" with a heavy online presence, billions in assets and a healthy growth curve... this also paints a big bulls-eye on their front page. From the perspective of software security, the executive ranks from the CEO down are in-line with making security a priority ...but somewhere between the senior management and line-of-business owners the message gets lost. Understandable, if you think about it from various perspectives - not 'security'.
So here we go. The CISO, in order to spark interest in security, invites for developers to take a voluntary self-assessment on software security. A challenge which yields a chance to win a prize... a prized gadget that has a street value of $400 nonetheless. Now, for the sake of round numbers let's assume there are 1,000 developers in the organization. Given this data how many developers do you suppose took the challenge? Try less than 3%
Hearing that jolted me in my seat a little today. I would have bet that the number was at least closer to 30% or something, but no it was a 10th of that! That's madness!
If a chance to win a $400 gadget isn't enough - what is? How do we properly incentivize developers, and others around them, to star thinking security? We already know the carrot vs. the stick, and why the punishment method simply doesn't work, but shouldn't the incentive method work, or at least have a greater uptake than 3%?
The answer is obvious, yet extremely difficult. We must properly offer incentives based on the culture and the task presented, and the group that is being incented. This sounds easy to say, but in practice it's extremely difficult as evident from the few organizations which have true voluntary developer involvement. I don't see this being solved any time soon, unless we finally figure out a way to properly incentivize the whole of the organization to think 'security' as an integral part of everyone's success, and collapse the 3 pillars of quality into one unit.
- Does it function? - quality organization
- Does it perform? - quality organization
- Is it secure? - security organization
Those must be collapsed into a single reporting structure, and a single 'responsibility' structure, otherwise software security will continue to be the security team's problem...
It starts with this, Total Quality Management, where quality is a non-fragmented issue, based on the 3 critical pillars...and you can't say things like "well, that is someone else's problem".