Software Security Education
Most of my time is spent talking with customers about using technology to help fix software vulnerabilities. Technology is a very small piece of a software assurance program. Buying static analysis or dynamic analysis products just shows you your problems. The more human elements around fixing and preventing vulnerabilities can’t be bought via a technology buy.
The root cause of software security vulnerabilities typically start with developers (minus issues created by poorly configured production environments and such), but it’s really not their fault. We train software developers to think functionally. If I click this button, this action occurs. What we don’t teach developers is what if a user clicks the button repeatedly? How could an attacker misuse/abuse an application to make it do things outside of the intended design? Most universities are not teaching secure coding. If they are, it’s usually graduate level. Have you looked at one of those “Lean x Language in 24 Hours” books? Some of the examples have security vulnerabilities. I can fully appreciate not wanting to overwhelm a new developer, but the security education has to come at some point. As usual, security is something that gets bolted on later.
Educating developers on software security is an interesting topic because not many people are trying to solve the problem. The focus is more on buying software or consulting services. Today if you want software security training you’re limited to consultant lead classes, CBTs, or self study through the handful of books available. Consultant lead classes tend to be Death by PowerPoint and CBTs are really just another form of Death by PowerPoint. Early in my training career, I delivered mostly PowerPoint training with some hands-on exercises. What I found was that developers didn’t retain enough information to fix their code. I added more hands-on exercises and retention got much better. I already knew that developers learn best by doing, but I didn’t realize just how much a difference it would make.
I haven’t tested this theory, but I believe the absolute best way to train developers would be through a software security project over a few weeks. Start with an idea for an application and move through each step of the software development life cycle with the current security activities. Include security in the requirements phase and architecture design. Do threat analysis and feed the results into the architecture design. Write code and perform code reviews. Test code functionally, but also include misuse/abuse cases. Grab some vulnerability analysis tools and run scans. Write deployment documentation including security and harden production environment. Application development with security from soup to nuts. After going through the exercise, developers will be much better equipped to replicate the experience.