Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
I would consider myself very much a realist, and know full well that as an industry we often let the quest for perfection get in the way of “good enough.” I believe in simple, low friction tasks that have major impact with as little engineering effort as possible. I think security education is an area where people are often looking for big, grandiose, “perfect” solutions, when “good enough” will suffice.
Don’t get me wrong. I love to see a solid, complete security education curriculum within companies, but in every case I have seen such a ‘perfect’ system, it’s failing. It’s failing because there is no urgency from management to have people attend the training. And when there is training, it’s not being tracked, so no-one knows at the top if the money is spent wisely. And let’s not lose sight of the elephant in the room, is the training effective?
So what do we need to do?
Let’s start from the supposition that we’re not trying to turn the entire software development team into security alpha geeks. I would argue you NEVER want to do that, because you’ll never ship your code to your customers! Let’s also assume we want to be as lean as possible. In other words, teach people what they need to know rather than filling their heads with all sorts of stuff they will never use. For example, don’t spend two hours teaching Web developers about C and C++ memory corruption issues. If some C#, PHP, Ruby and Java folks want to learn about memory corruption, fantastic, let them, but don’t force it on them. I spent some time earlier this year with a customer in England that builds C/C++ software for low-level embedded devices used to control critical infrastructure, and they had the opposite mentality. They told me if I mentioned the words “cross-site scripting” or “SQL Injection” they would escort me from the premises! I did however, talk to one engineer about SQLi over a beer one night.
At Microsoft we have plenty of security training material and much of it is very specific.
It is critically important that security education be built into the development process, what I mean by that is set aside time in the schedule to get it done. To be completely blunt, it’s part of the development process, not an afterthought.
After working with customers where security training for developers has been successful, the #1 success factor appears to be “start small.” For example, if you build web-based solutions, start with having the developers read a chapter of a book on cross-site scripting, cross-site request forgery and probably SQL injection. Or, have someone on the team build a presentation on the pertinent topics and present it at a “lunch and learn” and make sure you video tape the event and put it online. Start to build a library of this material. Never underestimate the value of a guy who knows about a specific security topic sitting in front of a PowerPoint presentation with a microphone.
For awareness training like this, I would recommend the following format:
That’s it! One hour. MAX. It doesn’t have to be fancy. It’s low-tech at its best. One customer gave copies of 24 Deadly Sins of Software Security to their developers and had them read appropriate chapters before they started to write new code or update existing code.
There is some evidence that this kind of training is more beneficial than “big bang” security training that covers everything anyone would ever want to know about security and then some. Having small, very specific training allows an engineer to stay utterly focused on the task at hand and not worry about topics that have no bearing on what he or she is currently doing. For example, why cover memory corruption issues when someone is building a Web site using ASP.NET and C#? Or the innards of crypto key derivation when the designer is working on permissions and access control issues?
That’s all I want to cover on educational process.
So how do you measure progress? One of the most effective measures we have found is to monitor bugs in new code! Let’s say you have ten developers, and all have been through your web training. If there’re no new web-related bugs found in the code for the next few months, then I think you can claim success. If you do find some bugs in the code, even one, look at the check-in logs (you do have revision control, right?) to see who added the bug(s) and have a chat with that person. Try to understand why the error was made and move on. Perhaps the person needs his code peer-reviewed for a while to make sure he or she is doing the right things.
The beauty of this low-tech approach is there’s little-to-no capital expenditure, so management is happy. It’s not a huge time investment each that every developer must make, so the developers are happy, and it all helps foster more secure software.
What’s not to like?
Let us know your thoughts.
- Michael Howard