13 Ways to Get your Developers on Board with Software Security
Itís easy to understand that software security starts with writing secure code. Keep the flaws out from the beginning and youíve bought yourself several pounds of prevention. Baking security in up front is logical and makes good technical and business sense; however, getting your developers on board with security training is not necessarily going to be an easy task. At first glance, it might seem that selling software security to developers would require the same approach as getting buy-in from executive management and the average user. Itís not quite that simple.
Developers are smart and independent thinkers that 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, the following are 13 ways you can get your developers on board with software security and ongoing security training for the long haul.
- Find at least one developer that 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 to minimize software security flaws.
- Perform - or subcontract - a security assessment (automated security assessment tool and/or a penetration test) to determine where weaknesses currently exist. You can also hire a development expert that can review your current development process to determine weaknesses and areas for improvement. This is really the only way to know where you currently stand.
- 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. In their security training, 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.
- Through 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
- Give developers access to the security training they need, including 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.
- Create a development library for ongoing security training that can provide quick reference to various software security issues including:
- 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
Also, ensure that during security training your developers are informed about the following Web sites and industry organizations that can be of benefit:
- Collaborate with your developers during security training to create formal software security standards and policies along with a set of metrics to ensure theyíre properly implemented and maintained.
- Tweak your software development process where possible and try to include security training. 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 success long-term. This should include:
- Plan your high level software security goals up front
- Specify the security training requirements needed to accomplish your security goals
- Analyze security features that need to be present in the final code
- Design specific security controls to integrate into the application
- Develop the code integrating security controls where possible
- Test (via peer reviews and automated security assessment tools) to ensure the security is working as planned
- Re-test after implementation to ensure no new flaws are introduced in the process
- Perform ongoing security tests searching for newly introduced flaws
- 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.
- Make sure your developers receive security training on 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)
- 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.
- Include software security requirements in your developerís formal job descriptions. Hold them accountable via periodic reviews and reward them for when they go above and beyond whatís expected.
- Ensure thereís solid communication between marketing, product management, development, and information security. Properly setting expectations and realistic deadlines is required for effectively integrating software security. This may require having a sponsor at the executive level that can back you up when needed. Also, having an information security team member that knows software and is involved in the development process can be very valuable.
Thereís a saying that if you swing long enough and hard enough you must eventually hit a home run. Youíve got to approach getting developers on board with software security and ongoing security training as a long-term process. Itíll take time and youíll undoubtedly have pushback. Youíre not going to be able to force software security down every developerís throat - regardless of your justifications or consequences. However, if you start slowly and work towards establishing a security-conscious mindset in your organization, youíll eventually see positive results.
About Caleb Sima
Caleb Sima is the co-founder of SPI Dynamics, a Web application security products company. He currently serves as the CTO and director of SPI Labs, SPI Dynamicsí R&D security team. Prior to co-founding SPI Dynamics, Caleb was a member of the elite X-Force R&D team at Internet Security Systems, and worked as a security engineer for S1 Corporation. Caleb is a regular speaker and press resource on Web application security testing methods and has contributed to (IN)Secure Magazine, Baseline Magazine and been featured in the Associated Press.
About Kevin Beaver
Kevin Beaver is an independent information security consultant, author, and speaker with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments. Kevin has written six information security books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at email@example.com.