On Day 1 at Black Hat USA 2010, I sat-in on the Cloud Security Alliance (CSA) Application Security Findings session. According to the speaker, "Developers don't care… they're motivated to simply ship code, not secure code."
I've worked with numerous developers on application security assessments, penetration tests, and software design projects. I've never met a developer who doesn't care about security. Not a high-priority? Perhaps. Discouraged or intimidated by security jargon and FUD? Yes. But not caring? No way.
The developers I've met are smart folks. I've met coders that know the Open Web Application Security Project's (OWASP) Top-10 front to back. Others are aware, but lack a consistent approach to keeping holes plugged. They're stuck in a loop of getting burned, scrambling for a fix, and plugging the hole, only to get stung again a few weeks later by a different attack. Others know all about the risk of data breaches and credit card theft, but don't know the motives or methods behind those that pull it off. It's a problem, but isn't a high enough priority until something bad happens.
Creating secure code begins with education and awareness. It starts at the top of the organization, the C-level, and goes all the way down to the developers. Producing "hacker-proof" code certainly calls for new development skills and processes, but it also requires a changed perspective on software threats. You can send your developers to defensive coding classes, but if a healthy security attitude isn't developed, people will soon return to old habits.
I know several developers across a variety of verticals. They supplement their coding skills with these principles, to keep them sharp and their awareness high:
Getting out and staying involved. There were only two developers in a room of about 50 people during the Black Hat CSA briefing. This tells me there aren't enough developers attending conferences where they can see first-hand how the bad guys exploit flaws. You can create "secure coding evangelists" in your organization by letting one or two developers attend conferences like Black Hat, just to see how expert researchers hunt for bugs and exploit weaknesses. These are real eye-openers. For a lower cost alternative, there are security groups that focus on secure development. Checkout the Open Web Application Application Security Project (OWASP) site to see if there's a local chapter in your city.
Anticipating threats. It seems like each time a company "builds a ten foot wall" attackers put-up an 11 foot ladder." This dynamic reveals an adversary that is motivated and skilled.
Developers that know Cyber-criminals aren't going to quit place a critical eye on every piece of code they write. They also monitor current or emerging tactics and consider them as they develop. Armed with the current reality, they look for and incorporate
development techniques that make them defensive coders, versus reactive
Making no assumptions. Hackers don't use code the way a developer intends. Your functional specification, design document, and web interface mean nothing to them. Put on their hat. But first, forget thinking outside of the box; get out of the box and burn it. I watched a security researcher demonstrate how to bypass authentication in a VMWare product. While researching the bug, he realized he couldn't exploit the flaw using the software client provided by the vendor. The solution? He simply wrote his own client and gained unauthorized access to the VMWare environment. Good developers know they can't hide a vulnerability — they can only delay how long it takes before it's found.