It’s become accepted wisdom that developers and security engineers exist on different planes, and that they’re anything but enthusiastic about collaborating. But with web application security threats proliferating and becoming increasingly difficult to address, security engineers must help developers to build secure applications.
To be successful in getting developers engaged in the process of building more secure web apps, security experts need to come to terms with some of their own misconceptions.
Don’t Call Their Baby Ugly
Ultimately, web application security is not an auditing and compliance activity; it is a code quality issue. Seen from this angle, it is easy to get developers enthusiastic about building more secure software: developers tend to naturally care about building a high-quality product. To bring developers up to speed on the skills required to build security into code, organizations should consider security training as a team-building activity, keeping it positive and fun (rather than approaching the endeavor as a punishment for past transgressions).
It’s easy for security experts to forget that their knowledge is highly specialized, developed over time and through hard, detailed work. Developers aren’t “stupid” for not knowing the basics of this increasingly arcane specialty. It’s worth taking the time to ensure that they learn about it. Building high-quality software is undeniably difficult; security engineers need to acknowledge this reality.
Give Them an ‘Aha!’ Moment
Secure development programming is becoming increasingly bland. Instead of dealing with vulnerabilities and attacks, software security is getting lost in the world of best practices, ‘control gaps’, and audit points. At this abstract level, nobody finds application security interesting. To write more secure apps, developers must learn to think like attackers, and attackers are not generally worried about political correctness or audit checklists.
The best way to achieve this shift in mindset is to teach developers to successfully exploit their own applications as an attacker would. There is no more powerful teaching moment than the first time someone sees the application that they’ve put years of effort into building dump its database contents via SQLMap.
Nobody gets excited by “alert(1)” or “OR 1=1; —.” These require an insider’s understanding of the implications of various vulnerability types. Security engineers must demonstrate the real implications of vulnerabilities. Harvesting the contents of databases, or spying on a browser with BeEF, this kind of practical demonstration of risk and impact requires a bit more time and knowledge to create, but the first time a student witnesses the real implications of a bug in their code is an electrifying moment.
Building on an understanding of risk, training developers in threat modeling provides an opportunity for them to see an entire system through an attacker’s eyes. As it’s often done today, however, threat modeling can also be too formal and abstract. The goal should be for developers to gain real insights into threats and how they evolve, not to teach them to build perfect diagrams and attack trees.
Another advantage to putting your developers through the threat modeling process is that it helps identify what I call the “secret security gurus” on the team. In my experience doing threat modeling exercises, every team has one. Generally, this person is a security hobbyist who worries that there is never enough time or budget for security. Security enthusiasts such as this can be the best resources for engaging developer teams.
Quality Code is Secure Code — and Developers Care Deeply about Quality
Flaws and possible areas for improvement in code are not that hard to spot if you know where to look. Since security defects are essentially a subclass of quality defects, it makes sense to appeal to developers’ sense of pride when it comes to the quality of their software. If we improve quality we improve security and vice versa.
As your organization considers the best ways to engage developers in security, it’s important to remember to keep the process as simple as possible. Many secure development programs fail because they try to address all problems at once, which can usher in “analysis paralysis.” The old cliche about how “a journey of a thousand miles starts with a single step” applies here. Every security defect that’s found and fixed represents progress. If you start with quick wins, measure progress, and demonstrate results, you’ll be off to an excellent start.
What Not to Do: Disempowering Developers
In many cases, organizations approach this process in precisely the wrong way. When managers confront developers with an edict that amounts to: “We know you’re busy, but here’s a bunch of other stuff you need to do, otherwise you suck at your (already complex) job,” it’s anything but motivating. The idea is to create the perception that identifying security issues is achievable, rather than one more onerous task for staff who already have a ton on their plates. In talking to developers about security, your tone should be closer to “Let’s do this!” than “It’s your job to do this.”
Identify Resources and ‘Security Champions’
It also makes sense to gather the best resources to help your development team through the process. This means doing much more than buying a tool and handing them the documentation manual. Documentation is great, but it’s no substitute for having someone to bounce questions off of when you get stuck. Plus, this approach creates a collaborative atmosphere.
What’s more, many high-quality online resources exist to help developers answer their security questions. It’s often simply a matter of creating an internal wiki with links to OWASP and best practice guidelines for security code review. Remember, techies dislike not knowing something only slightly less than they like admitting they don’t know something. If the information is easily available, developers will educate themselves.
In my next post, I’ll examine how to build security into the quality assurance (QA) cycle.