On 29 June 2004, James Walden said:
Subject: [SC-L] ACM Queue article and security education
I'd like to open a discussion based on this quote from Marcus Ranum's ACM Queue article entitled "Security: The root of the problem":
"We're stuck in an endless loop on the education concept.
We've been trying to educate programmers about writing secure code for at least a decade and it flat-out hasn't worked. While I'm the first to agree that beating one's head against the wall shows dedication, I am starting to wonder if we've chosen the wrong wall. What's Plan B?"
From my perspective, security education is only beginning to climb an initial upward curve. While classes in security topics are becoming more common in undergraduate computer science course catalogs, their presence is far from universal. I don't know of any university that requires such a class for an undergraduate CS degree; if any such programs exist, they're not common.
I agree with James Walden. Very, very few schools educate on how to develop secure applications. I'll be teaching a course on developing secure programs at George Mason University (GMU) this fall 2004; GMU is one of the VERY FEW schools where such a course is even OFFERED, never mind being REQUIRED.
I challenge Ranum to prove that most schools require education on secure software development before graduation at the undergraduate level. We haven't been "beating our heads to educate programmers". We HAVE been beating our heads against an uncooperative academic environment that is unwilling to educate how to develop secure programs. I've been working for years trying to convince the SWEBOK to add security as an important software engineering topic; last I heard, they had still failed to include security as a topic worth knowing about in software engineering.
I believe we need to get to the point where computer science & software engineering schools LOSE ACCREDITATION for failing to educate how to develop secure systems at the undergraduate level. We aren't anywhere near there today.
Few people need to write quicksorts, or operating system kernels, but that's where we spend too many of our precious educational hours. EVERYONE is now writing code that connects the Internet or an intranet, through which their programs will be attacked. We are ALL writing programs that must be secured. And almost all schools fail to spend even a single minute on educating what that means. So let's make sure they get an education on what's actually more important. Even a few hours would be FAR MORE than what almost all schools do today.
I completely agree with Ranum that tools are a very helpful part of the arsenal. Turn on warnings! Make the defaults safe! Build warnings/counters into the development system! I give away a security scanning tool (flawfinder) so that developers can search for probable vulnerabilities, and I've often worked to get safer functions added to various libraries so that things are "secure by default."
But that's not enough: A fool with a tool is still a fool. There is no tool that can counter all foolish decisions, and a developer can usually override a tool, so a developer MUST understand WHY the tool is doing what it's doing.
Not using C/C++ to write new apps isn't enough. No tool can prevent ALL foolish decisions; you can specify a foolish decision, and then formally prove that you did it. Failing to verify input sufficiently can happen in any language. And many "safe" languages have ways to override their safety, because there are times when you need to override. C# has an "unsafe" mode that allows buffer overflows; Ada has modes to remove its protections too; and anybody can call out to C/C++ libraries. A developer who doesn't understand anything may just choose to override their tool, because the reasons for the limitations haven't been explained to them.
Tools are great. But only if we educate our developers sufficiently so they'll know how to use the tools, their limitations, and the risks they take when overriding them.
--- David A. Wheeler
