I picked up a free copy of 19 Deadly Sins of Software Security at a conference last year. I didn't expect the book to be good because it was a free giveaway item from one of the the vendor booths. But I paged through it on the flight home, and I was pleasantly surprised. It's actually quite good.
The formatting of the number for ‘improper file access’ is not correct, or a digit is missing.
The only secure computer is one that is not plugged in and (in the case of laptops) not turned on.
Those are two separate numbers.
Yeah, it sure is a good read. I misplaced my copy during some relocation and been searching for it since then 
I would like to point out that although the lack of memory management makes C/C++ a greater risk there is also a risk involved in running software within a framework (.NET, Java). A security problem within the framework immediately affects all software using it (class break).
Mine was stolen, some pages were taken and replaced with erroneous information, then it was put back in my briefcase.
Hmmm, this is a good list but I have seen many of them covered elsewhere, particularly the web based ones as that’s my main area of work. It is the attack vectors that are not widely known (or indeed known at all) that worry me the most.
With regard to usability, security vs. usability is a major issue and I think that many developers and network administrators in particular see them as being competing forces, i.e. if we improve usability by freeing up resources to our users then it is to the detriment of security.
I have seen many examples of this over the past few years, for example overly restrictive network firewall policies which are actually preventing people from doing their jobs correctly.
Security is very important but it is not the absolute priority for software development, and should never become a barrier to people effectively doing their jobs IMHO.
Information leakage is by far the worst, I know of several times when the customer support where I work just gave away passwords to a customer without really checking if that was indeed the correct customer.
A programmer can build in whatever security checks but if the people that manage the whole thing don’t understand or don’t care about security it won’t matter.
Dave:
I don’t think Daniel’s telling anyone to avoid the framework, nor is he doing some “mental gymnastics” to convince himself he’s safer. In fact, he explicitly pointed out that there was a greater risk involved when using C/C++.
His point, and I think it’s very valid, is that with C# you get a much safer language on a slightly less-safe platform. Any insecurities in the OS itself that would affect a C/C++ program will also affect a C# program, plus you have the additional “leaky abstraction” of the .NET Framework.
It’s no reason to avoid .NET; you just might want to be a bit more diligent about applying the latest security patches.
There’s a great series of interviews and show 006 is with M Howard who is an author of this book.
Having used Delphi/Object Pascal for years, I was always wondering about why the C++ developers yammered about their memory getting stepped on, and when I learned that it was due to putting a 12 character string into a 10 byte field, I was stunned.
Anyways, it would be interesting to see a framework developed that would not let 'net developers do dangerous things quite so easily.
“Anyways, it would be interesting to see a framework developed that would not let 'net developers do dangerous things quite so easily.”
Internet Explorer qualifies, if you drop the word “dangerous.”
In the “Unauthenticated Key Exchange” section, it says “you’d be shocked how often this doesn’t happen.” Apparently, it only has happened once? That is a little bit shocking.
What happens of I do enter HTML in the comment box? Code injection? :-).
The most frequent of these vulnerabilities are impossible in a decent language like Ada, or our own derivative Carmen. Buffer overflows are impossible per library and code injections are impossible with a little code you have to write, but that can be completely ignored from then on. Problem solved since 1978.
Ok, start shooting on Ada. It is hardened in almost 30 years of solid development. Best language choice if integrity counts.
19 deadly sins is a good overview because it’s small and easy to digest, but go read “The Art of Software Security Assessment” if you want a real eye-opener. It’s pretty thick (~1200 pages), but they dig a lot deeper into the whole range of vulnerabilities, particularly for C/C++. “Secure Coding in C/C++” is another good one too. It’s pretty short and it ties into the work being done at CERT (http://www.cert.org/secure-coding/). And there’s always the classic “Writing Secure Code,” but it’s getting a bit dated.
I see a lot of faults due to the programmer failing to validate user data (or other data). Can you really blame the language of choice for laziness?
-N
I think there should be a knowledge area about software security in the upcoming version of the Software Engineering Body of Knowledge (www.SWEBOK.org), since most of today’s systems and applications are more vulnerable to different threats than before, and the impact can be disastrous.