Secure Coding mailing list archives
Re: SC-L-DIGEST V1 #9
From: "David A. Wheeler" <dwheeler () ida org>
Date: Fri, 09 Jan 2004 20:05:46 +0000
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
Current thread:
- Re: SC-L-DIGEST V1 #9 David A. Wheeler (Jan 09)
- Re: Re: SC-L-DIGEST V1 #9 Brett Hutley (Jan 12)