Published on
This post was written by Chris Romeo during his tenure at Security Journey.
Developers are everywhere because software is everywhere. Try to think of an organization that doesn’t employ at least a few developers to maintain their code. The challenge with developers is that most are not security people. By "security people," I don't mean that they need to be lifelong security enthusiasts that live threats and love firewalls. They just need a foundation in application security. Deep down inside, they want you to teach them.
The primary problem with software is security vulnerabilities. Vulnerabilities are easily traced back to a bad decision made during coding and could span all the way back to a bad design decision. Vulnerabilities exist because of a mistake made by the developer at some point in the past. Vulnerabilities continue to rise because history repeats itself as developers commit the same mistakes, over and over again. The reality is that our applications live and die through ten simple things, outlined in the OWASP Top 10. The problem is that most of your developers do not understand enough about security to modify their behaviors to prevent these problems.
Why is security such a stretch for developers? Because the average developer lacks understanding of the real ramifications of their decisions. This is clouded by the fact that developers are sometimes stubborn people who think they already know all that they need to know. In actuality, they do not understand the vulnerabilities that open up within their application when they fail to use parameterized SQL queries (SQL injection) or forget to validate all input (think cross-site scripting). That lack of understanding is not deliberate. It is just that most developers have not been taught the foundational lessons of application security.
"Developers are not monsters. They want to do the right thing. The main problem they have is that they do not know what the right thing is for application security."
To reach your developers with the message of security requires a four-phase process of application security connection. Open their eyes, fill their brains, task their hands, and embrace the gathering to truly get your application security program moving forward with developers who understand the foundational lessons of application security and how to apply those lessons in their code.
1. Open developers' eyes to security
The first phase is to open their eyes. This begins with the concept of application security awareness. This is different from generic security awareness training, where you teach everyone not to click on links or allow tailgaters to follow them through the office doors. Application security awareness is a foundational layer that teaches the basics of application security, such as security vocabulary, the business case for security, and who the bad people are that wish to compromise your web applications. You start with a layer of awareness to frame the problem and open their eyes to the ramifications for the development decisions they make. By understanding these basics, developers are primed for the next phase, where you fill in more of the details.
Action item: Determine the basic, foundational application security lessons that you must impart to all your developers.
2. Fill developers' brains with app sec
The second phase is to fill their brains. This process provides the next level of learning they need to apply application security to their specific role.
Filling their brains begins with knowledge. Role-specific knowledge prepares them to make the right security decisions. If you have C and Java programmers, you’ll need slightly different lessons for each. They both need the fundamentals of secure coding, but with language-specific examples. Teach them the techniques they need to be successful, and always explain why they should care. Modern-day e-learning often misses out on the most important question in a developer’s mind: Why should I care about this? Answer the "why" question by demonstrating the ramifications of a lack of security.
The second part of filling their brains is history. Developers tune out when you show an example of the latest vulnerability in OpenSSL, but if you provide an example from the product or web application that they support daily, they will lean in and pay much closer attention. Revisit the past to enhance the future, searching through your bug database to understand the types of security vulnerabilities that cause the most struggles for your organization. Empower your developers to fix the future by demonstrating what has gone wrong in the past and teaching them the methods for not repeating history.
Action item: Determine the individual development roles in your organization and specify the specific lessons various types of developers need to learn.
3. Task developers' hands
The third phase is to task their hands, which means giving them something to do. After you have imparted knowledge and history to your developers, they must translate that knowledge into activity to truly make it stick. The activity should be a set of real security tasks to improve the things they work on. To be meaningful, these activities must be personal and real. Nobody likes to do busy work, so ensure that the activities you specify make a difference. Activity is about cementing the behavior change that you have advocated in the first two phases.
The activities may include things directly related to what they work on, such as creating a threat model for their design or executing a security test plan. You can also adapt the activities to encourage other behaviors you wish to model, such as mentoring junior folks in security or speaking in forums such as a team meeting all the way up to external conferences.
Action item: Generate a list of activities to improve the security of your offerings and incentivize your developers to perform those activities to lock in their newfound security knowledge.
4. Embrace the gathering
The fourth phase is to embrace the idea of gathering. After your developers have the foundational knowledge, role-specific knowledge, and a plan of activity for security, they need a place to connect with other security-conscious people in your organization. A security community is the connection point where developers can meet with other developers to talk security and learn from one another, and also where they can connect with the security department. Both enrichment and encouragement exist when a true security community is born. If you are part of the central security team, partner with the developers to make life better for both groups.
A security community can manifest with simple things such as regional monthly security lunches or a monthly company-wide security training meeting. It can also become more complex as your organization matures, to include hosting a yearly internal security conference, where developers from across the organization gather to share their trials and triumphs.
Action item: Strategically choose the right set of events to bolster your burgeoning application security community.
Doing the right thing
Developers want to do the right thing for security. The real challenge is that they do not understand what that “right thing” is. To truly transform the developers in your organization, follow these four steps and you will start the process of transforming developers into security people.
Image credit: Lindsay Henwood
