Baking security into the software development process makes good technical and business sense. But getting your developers on board with security training is not necessarily going to be an easy task.

Developers are smart, independent thinkers who need better reasons to develop with software security in mind other than the worn out "because it's the right thing to do" spiel. Whether you're a Chief Information Security Officer, development manager, or compliance director, you can get your developers on board with software security and ongoing security training for the long haul. Here's how:

1. Find at least one developer who knows and values secure coding. This person will be able to lead and set a good example but also help mentor other developers by offering security training.

2. Perform - or subcontract - a security assessment to determine where weaknesses currently exist. You can also hire a development expert who can review your current development process to find areas for improvement. This is really the only way to know where you currently stand.

3. Get your developers the security training they need - on an ongoing basis. They may not admit it, but arguably the majority of developers could benefit from some security training in both development and general information security concepts. In fact, no IT professional is above needing formal continuing security training - there's just too much to know. Specifically, make sure they learn about the concept of defense-in-depth. This will help drive home the importance of not relying on external defenses to keep their applications safe. It will also translate nicely into software-centric defenses in areas such as authentication constraints, access controls, input validation, login timeouts, secure password management, exception handling, and so on.

4. As part of the security training, show your developers what national and international standards bodies are doing regarding software security. These organizations have laid the groundwork for secure development practices, which is half the battle. Well-known and widely-accepted standards are:

• OWASP Top 10 (http://www.owasp.org/documentation/topten.html)

• IEEE P1074 Workgroup - Standard for Developing Software Life Cycle Process
• ISO/IEC 12207:1995 - Information technology - Software life cycle processes
• ISO/IEC 15288: Systems engineering - System life cycle processes
• ISO/IEC 17799:2005 - Information technology-Security techniques - Code of practice for information security management
• NIST Special Publication 800-27: Engineering Principles for Information Technology Security
• NIST Special Publication 800-55: Security Metrics Guide for Information Technology Systems
• NIST Special Publication 800-64: Security Considerations in the Information System Development Life Cycle

5. Give developers access tools in the areas of software security analysis and remediation, and the often overlooked threat modeling applications. The only efficient way they can make significant improvements is to possess the right tools for the job.

6. Create a development library that can provide quick reference to various software security issues including:


Books

• Writing Secure Code (Microsoft Press) by Michael Howard and David LeBlanc

• 19 Deadly Sins of Software Security (McGraw-Hill) by Michael Howard, David LeBlanc, and John Viega
• Programmer's Security DeskRef (Syngress) by James C. Foster and Steven C. Foster
• HackNotes Web Security Portable Reference (McGraw-Hill Osborne) by Mike Shema
• Buffer Overflow Attacks (Syngress) by James C. Foster
• Hacking