| COLUMN |
New SANS program a critical leap forward |
 |
|
|
With the infosec industry as a whole experiencing tremendous growth in the last 10 years, software security and secure development practices have been left behind. For whatever reason, ISVs, universities and developers' organizations have treated secure coding like an annoying younger brother. If it got noisy enough, they'd pay a little attention to it until things quieted down, and then they'd go back to their regularly-scheduled programming.
This has been the general attitude of the software industry for decades, and it's not difficult to see why. Customers -- enterprises and consumers both -- were completely uninterested in security until very recently. Software design has always been driven by the race to shove more and better features into the next release and get the product out the door as soon as possible. If the customers weren't demanding better security, why should the software makers bother with time-consuming precautions such as source-code scanning and penetration tests? All those things would do is delay the ship date, and in the software business, that's the cardinal sin.
But, beginning with Microsoft's creation several years ago of the Security Development Lifecycle and the attendant training of all its developers in secure coding practices, more and more ISVs have begun to pay attention to the role of security in software development. No software maker exemplifies the "ship-or-die" mentality of the industry more fully than Microsoft, so when the company began delaying products in order to fix security problems, people took notice.
But there's still a long way to go on this front, and a lot of the responsibility falls at the feet of the big software and security vendors and the colleges and universities that are still turning out security-ignorant software engineers.
That's why this week's announcement by The SANS Institute that is has created a new body dedicated to training and certifying developers to write more secure code is so important. The Software Security Institute, as it's known, is not just another PowerPoint-based effort full of sound and fury signifying nothing. It is a joint project that has the backing of SANS as well as a number of major vendors, including Symantec, SPI Dynamics, Fortify Software and others, and several universities, such as Virginia Tech and the University of California at Davis.
The main deliverable of the institute right now is an exam that developers can take to assess their knowledge of secure-coding practices in various programming languages. After taking the self-assessment, developers can opt to move on to a certification exam through which they can earn a designation as a GIAC Secure Software Programmer. The program's offerings likely will expand over time, but the real key right now is the involvement of the higher education community. Any effort of this kind has to start at the beginning, and for software engineers that means college.
But until the last few years, security classes of any kind have been almost non-existent in most computer science programs. If you want to know how bad it is, go ask five developers in your organization whether they had any security training at all in college, and unless they're under 25 years old (or attended Purdue or Carnegie-Mellon), the answer will almost certainly be no.
Again, this is a function of the demand in the market. Software makers didn't need developers who could write secure code; they needed developers who could write code that worked and who could meet tight deadlines. Gene Spafford, the executive director of CERIAS and a professor of computer science at Purdue University, once told me that he could turn out students who could write secure code all day long, but no one would hire them because they wouldn't write in C++ or Java.
A sad state of affairs, to be sure, but one that the new institute should help address. Universities and colleges that are working with SANS will not only help administer the certification exams, but also will commit to training developers in their local areas. Faculty at these schools will be able to share secure programming techniques and educational materials, as well.
All of this could end up going nowhere and die on the vine as many other such efforts have over the years. But, I'm hopeful and optimistic that this one will work for a couple of reasons. One, SANS has been doing security training for a long time and Alan Paller, its director of research, knows everyone there is to know in the industry and has a knack for getting things done. And two, it has to work. The time when a few buffer overruns here or SQL injection flaws there was acceptable is long past. It's time now to end the excuses and get to work.
|
|
|
|
