On Day 1 at Black Hat USA 2010, I sat-in on the Cloud Security Alliance (CSA) Application Security Findings session. According to the speaker, "Developers don't care… they’re motivated to simply ship code, not secure code. - Simon J. Herring via ubersecure.com And that's far from the first time I've heard a security professional tell me that developers don't care about security. In fact, one of the reasons I made the transition 8 years ago from Development to Application Security is that I got really tired of hearing it. Developers (and users, for that matter) certainly care about security. The problem is that there are a lot of other things they also care about… like meeting aggressive deadlines, passing functional tests, building user-friendly applications, making sure their applications work quickly and reliably, and so on. The mistaken belief that developers don't care about security leads to all kinds of wasteful, even harmful, choices:
- We try to make security "invisible"
- We give security defects an automatic high priority
- We try to test ourselves secure
- We govern security by making lists of rules
So, what are you going to do about it? The most important thing a security organization can do to promote application security is to treat security as part of quality‚ putting it on the same footing as usability, performance, and stability. That's harder than it sounds, so here are a few specific actions you can take: 1. Acknowledge that developers care about security and understand that it's not the “only thing” they care about Developers want their applications to be secure, but they have a lot more than just security on their plate. Showing developers that you understand that security is part of a larger overall quality initiative rather than an external mandate will garner significantly more trust and cooperation. 2. Be prepared to have conversations about how security fits in with other quality needs Being prepared means training developers to understand security enough to be respected participants in those discussions. Likewise, you must also train security professionals to understand how development really works. How do you expect a security professional to help a developer through a security challenge if he or she doesn’t understand the basics of development? It’s a lot like watching a chess champion trying to advise a rugby team. When you help both sides of an application security conversation understand each other’s issues, you get much more productive discussions – and that leads to much better teamwork and overall better security. 3. Provide developers with the tools they need to handle the "easy" parts of security Automation is not a panacea. But, tools can be powerful allies for developers:
- Training
- Clear, concise practice guides
- Pre-built implementations of common security functions
- Automated testing for "easy" weaknesses
Giving developers tools that give them the insight they need to help them improve the security quality of their software- tools that are well-managed, easy to use, and for which they receive adequate training- can free your security experts to help with more challenging issues. 4. Train developers to identify places where they need professional security assistance A great many serious flaws surface because:
- Developers don’t understand how a particular pattern or weakness poses a risk to their application
- Developers make incorrect assumptions about how severe a weakness might be
This isn't a surprise: developers are not, nor should they be, security experts. However, a good training program helps developers build the security skills they need to understand when their challenges can be best solved by working with a security professional. 5. Be good partners and service providers to the developers Make yourself easy to talk to and add value to discussions. The goal here is to get developers to feel comfortable reaching out when they have security challenges. And reward themfor doing so. So many security organizations inadvertently create disincentives for application teams to engage them. If any of the following are true of your organization, you're probably losing insight into risks developers know about:
- Engaging the security group negatively impacts development deadlines
- The security group makes applying for exceptions to security requirements difficult
- Teams that engage the security group are openly chastised for having security challenges
- Engaging the security group negatively impacts team performance metrics (bug counts, cost, quality ratings, etc.)
My point: developers do care about security. A lot, as a matter of fact. But they usually lack the training needed to effectively incorporate security into their quality program. And when they try, security groups often effectively punish them for doing so. These problems can be solved through education and wise usage of tools.
