If you're in any way involved in getting developers to write more secure code, you've undoubtedly run into some roadblocks. Getting buy-in on security and secure coding practices can be like pulling teeth. Many organizations have come a long way in the past few years, but attaining the mindset of security being a development priority still hasn't been mastered. The underlying issue is simple: Most developers are smart people who are really good at what they do -- writing code -- not being security experts. That said, most know the basics of secure coding:
Whether I'm performing penetration tests or source code analyses, most of those security elements are addressed in the majority of applications. The problem is there's so much more to application security than that. There are authentication weaknesses, application logic flaws and advanced input validation issues that many developers don't have the time, tools or wherewithal to deal with. Regardless of whether developers are on board with security, these software flaws are still present, creating business risks no one can afford to ignore. But how do you get to the point where you know developers are on board and are working diligently writing code with security in mind all along the way?
As with most things when dealing with people, you've got to work smart over a longer period of time. The goal is to educate them and change the way they look at security related to their jobs. You certainly can't force any developer to immediately learn security and all of a sudden fix every application security problem. But here's what you can do:
Find an advocate
Odds are you have at least one developer who's moderately interested in improving software security. Give this person the responsibility of leading the effort and mentoring others in development and QA on what to look for and how to do things better.
Get management involved
It's one thing for a peer or a middle manager to push for better software security, but it's quite another when someone in executive management expects it. When a high-level manager such as a CIO or CTO expects secure software, it will get the attention of product managers, project managers, developers and the security team alike and help make things happen.
Get developers involved in security meetings and vice versa
Instead of creating barriers between developers and security staff, get them working together. Be it development planning sessions, security committee meetings or anything in between, at least one member of each party needs to be involved in the other's goings on. This helps ensure everyone is on the same page and expectations are properly set. Unset expectations are the root of most problems related to this anyway.
Show developers what can happen when software flaws are exploited
I don't believe in pushing security with FUD (fear, uncertainty, and doubt), but I do believe in showing people just what can happen in real-world settings. Some good vulnerability scanners, source code analysis tools and manual penetration testing are a great way to prove that the software they're putting out is not where it needs to be. All it takes is a screenshot or two showing database tables extracted via SQL injection, command prompts on remote systems, and similar exploits to get most people's attention.
Show them -- and give them -- the tools they need
Many developers I come into contact with still aren't aware of the tools they can be using internally to find security flaws during development and QA. Many tools, such as Klocwork's K7 and HP Software's DevInspect and QAInspect, plug right into mainstream IDEs to make the security testing process seamless. There's no excuse for developers to not have those tools.
Get them the training they need
It's one thing to use the more "reactive" security testing tools but quite another for developers to gain the knowledge of what not to do related to software security in the first place. This requires training and education on a periodic and consistent basis. Be it secure coding classes, security conferences, or some of the good secure coding books out there, such as 19 Deadly Sins of Software Security (McGraw-Hill) and Programmer's Security DeskRef (Syngress), the knowledge is out available. Set goals and tie developers' accomplishments related to this to their annual employee reviews and pay increases.
Set security standards
Rather than going back and fixing stuff from the past, create internal requirements that require all new code to adhere to specific security standards. A good reference to get started with for Web applications is the OWASP Top Ten Project. Sure, not all new software being developed is Web-focused like the OWASP Top Ten, but a large percentage of it is, plus many of the same concepts apply directly to client/server and standalone applications as well.
Regardless of how your role relates to developers, it's key to not force any of this down anyone's throat. It's a proven fact that most new ideas and proposed changes are best accepted when presented casually and approached over time. Work in new ideas and modes of operation slowly, and give people at least 72 hours to mull them over. If at that point you're still not being heard, well, do and do again.
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 19 years of experience in IT and specializes in performing information security assessments revolving around IT compliance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He's also the creator of the Security On Wheels series of audiobooks. Kevin can be reached at kbeaver@principlelogic.com.
