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