Re: SC-L-DIGEST V1 #9

["David A. Wheeler" <dwheeler () ida org>]

Alun Jones wrote:


I hate to say it, but maybe it's time for developers to become accredited
professionals, and for employers to insist on getting qualified developers,
rather than picking anyone who's read a book on C.


Crispin Cowan countered:

What would they be accredited of?  ... There is 
no cookbook for reliable software. A programmer can follow all of the 
best practices, and still produce software that crashes & burns. Worse, 
there is controversy over what the "best" practices are, so you can't 
even hold a programmer accountable to a single procedure.


So what is it that we would be accrediting?



There _ARE_ things that could be accedited.
While there's no "cookbook guarantee for success", there are
principles that ARE generally accepted.  There's also a long list
of approaches that are KNOWN to be INSECURE, yet we don't require
anyone to know to avoid them.

While the meaning of "security" varies between systems, there _IS_ a
common superset of requirements that most systems pick from
(e.g., Confidentiality, Integrity, Availability, Auditability).
Saltzer and Schroeder was written in 1975, and is still a very valid set
of design principles. And let's face it, nearly all security flaws today 
stem from the same

mistakes everyone else made before (buffer overflows, format strings, etc.).
If we made sure that all developers knew the common defects that
are security-relevant, then we would eliminate 99% of our current problems.

Right now the biggest problem in developing secure programs is a
LACK of KNOWLEDGE by DEVELOPERS. Processes can help,
but only AFTER the developers understand the problem.

Accreditation would help ensure that developers at least knew a bit
about the issues.  Not a "one-size-fits-all" method, but about
possible requirements, design principles that have stood the test of time,
and implementation techniques that have repeatedly caused problems before.

Take a look at my freely-available book ("Secure Programming for
Linux and Unix HOWTO" at http://www.dwheeler.com/secure-programs ).
Yes, it discusses requirements and design.  But notice the huge amount of
text discussing implementation mistakes and how to avoid the mistakes,
such as buffer overflows, format strings, race conditions, etc.
Almost no developer coming out of school learns about
these problems, and companies don't require their developers to learn 
them either.

So, we continue to see the same problems again & again.

An alternative to accrediting individuals would be to REMOVE the 
acceditation from
CS and SE universities/colleges who fail to teach how to develop secure 
software.

Nobody is going to write their own quicksort anymore, a topic they all cover
ad nauseum.  Yet every developer WILL be writing a program that connects to
an intranet or Internet, and those graduates' understanding of secure 
software
development may determine if we live another day.  Our lives are in 
their hands,

yet they continue to graduate the unqualified. The "Software Engineering
Body of Knowledge" (SWEBOK) still thinks of security as a "specialty" area,
and last I saw doesn't cover the area of developing secure software at all.
Rediculous.  If it connects to the Internet or intranet, or accepts data 
from those sources,
it needs to be a secure application.  That now describes almost all 
programs.

The world has changed, and our schools haven't changed with it.

I commend Cowan's work to harden systems against common implementation
mistakes, but that work generally only imperfectly protects systems 
and/or reduces damage.
It's much better to have more secure programs to start with, so that 
Cowan's work

can be the safety net for the few vulnerabilities that slip by.

Since most developers don't know how to implement secure programs at all, we
should EXPECT that our programs are normally insecure. And they are.

--- David A. Wheeler