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 the Code: ASP.NET Web Application Security (Syngress) by Mark M. Burnett
- The Database Hacker's Handbook (Wiley) by David Litchfield, Chris Anley, John Heasman, and Bill Grindlay
Magazines
Also, ensure that your developers are informed about the following Web sites and industry organizations that can be of benefit:
Web Sites
Industry Organizations
7. Collaborate with your developers to create formal software security standards and policies along with a set of metrics to ensure they're properly implemented and maintained.
8. Tweak your software development process where possible. Many developers and are set in their ways and don't follow a formal, structured development process, but it certainly can't hurt to provide security training and make adjustments where necessary to facilitate more secure development processes and set your developers up for long-term success. This should include:
- Planning your high level software security goals up front
- Specifying the training requirements needed to accomplish your security goals
- Analyzing security features that need to be present in the final code
- Designing specific security controls to integrate into the application
- Developing the code integrating security controls where possible
- Testing (via peer reviews and automated security assessment tools) to ensure the security is working as planned
- Re-testing after implementation to ensure no new flaws are introduced in the process
- Performing ongoing security tests searching for newly introduced flaws
9. Set new standards for all new code moving forward rather than forcing your developers to go back and fix old code. This is especially important if older code is going to be phased out in the near future.
10. Make sure your developers understand the business risks related to software security and what's at stake for your organization. This can include:
- Business principle that security and privacy are being taken seriously
- Product differentiation for added value and competitive advantage
- Building of loyal customers
- Increased customer base, which can lead to increased revenues, profit sharing, and other incentives
- Decreased business liability and increased regulatory compliance
- Direct savings through prevention rather than rewriting software down the road (see http://www.jrothman.com/Papers/Costtofixdefect.html)
11. To the extent possible, support your developers when they request a specific development platform or language to use. Many software security flaws are introduced when developers have to learn a new language or support a new platform. If there's no clear business need, then supporting developers on what they already know can be a lot safer.
12. Include software security requirements in your developer's formal job descriptions. Hold them accountable via periodic reviews and reward them when they go above and beyond what's expected.
13. Ensure that there is solid communication between marketing, product management, development, and information security. Setting expectations and realistic deadlines is necessary for effectively integrating software security. This may require having a sponsor at the executive level who can back you up when needed. Also, having an information security team member who knows software and is involved in the development process can be very valuable.
Getting developers on board with software security and ongoing security training will take time and you'll undoubtedly have pushback. However, if you start slowly and work towards establishing a security-conscious mindset in your organization, you'll eventually see positive results. As the saying goes, if you swing long enough and hard enough you will eventually hit a home run.
The ideas expressed in this article are solely those of the author and do not necessarily reflect the opinions of ITworld.com.
