A question was recently posted to the Federal Secure Software Advisory from Fortify:
“In my company, there are conflicting opinions on how much time we should spend training developers in hacking techniques versus writing solid code. What do you think? Should we spend 50 percent of the time on each? Or 20/80? I'd be interested in hearing about what others cover in developer training.”
I think it’s outstanding that companies are thinking like this. Let me offer an expanded version of my answer:
It is my practice to recommend an 80/20 to 70/30 range. But, how much time you allocate should consider the types of applications that are developed by your team. While most exploits have their roots in the same mistakes such as unchecked buffers and unsanitized inputs, etc., the mechanics of how they are exploited over the network against Linux desktop may not be time well spent for a .NET web developer focused on Web 2.0. In fact, too much information, especially for developers with limited security exposure, may dilute your training efforts altogether. This leads to a critical learning concept that I like to capture in three sentences:
Tell me and I may not listen
Show me and I may not watch
Involve me and I will learn
Catchy, but what does that really mean? It means, take advantage of how the human brain works by maximizing all the senses; not just hearing and sight, but tactile as well. And by making it personal, you make what is learned readily applicable. This is too important to miss since companies are doing more with less; developers are overworked; security is complicated – make the most of the time you’re given to get the concepts applied.
I prefer a blended training approach that combines hacking techniques with secure coding in a single training. Emphasis is placed on challenging developers to think about the code they’ve written (and will write) and how it affects security at the client, web, and data tiers. Let’s assume you have 40 hours to get your developers up to speed on secure coding. Allocate 8-12 hours to exploring pertinent web application weaknesses, how they are found, and how they are exploited. The developer should be exposed to manual exploitation. Avoid introducing complicated tools, scripts, and exploits, as the emphasis is to make them developers that code securely, not developers that can penetrate applications. If you introduce any tools at all, ensure they are ones they will continue to use after training is complete.
The techniques learned in the first 12 hours are used to stimulate conversation regarding potential weaknesses in your environment. With proper planning a “typical” internal app can be decomposed and analyzed during the training. Secure data sanitizing approaches can be taught, after which the in-house application can be evaluated for compliance with secure standards. This not only teaches the proper coding approach, but also exposes developers to the process of identifying weaknesses. BONUS: If developers feel empowered to find software weakness they won’t rely on (or assume) others will find them.
I’ve found that in-depth hacker training introduces too many concepts and tactics that are not useful in the day to day activities of developers. Developers learn something new, but find themselves wondering how to use that knowledge in a day-to-day basis. It’s not enough to know the techniques; your teams must be able to retain and quickly apply what they’ve learned.
Si
Comments