Do We Need an ISO Secure Coding Standard?
Thomas Ptacek | July 26th, 2006 | Filed Under: Defenses, Uncategorized
Dark Reading quotes me again, because I’m all famous and stuff. This time, I’m bloviating about CERT’s efforts to create an ISO “secure coding” standard. Quoth the cynic,
Tom Ptacek, researcher with Matasano Security, says there are already plenty of sources of information on secure programming. He’s skeptical of the impact of CERT’s standards. “And what does standardization actually mean? What is scarier to say about a program — that it is nonstandard or that it is insecure?” Ptacek says. “The code we deal with is already insecure. Sophisticated buyers know in their gut that this is true. So why do they care if it’s nonstandard to boot?”
Before I gave this quote, I actually did pore through the SCI materials. As you can expect, the above was a choice quote. If you’re a security geek, the rest of my rant might be interesting:
There are already a myriad of good sources of information about secure programming, including books targeted specifically to developers that don’t have experience with secure programming. I don’t understand why a wiki or an ISO standard would be more accessible to these developers, who write the majority of all code.
I’m talking about “19 Deadly Sins”, and yes, you should read that before you read a wiki on secure programming.
Most bugs of any type are caused by simple, well-known patterns of programming errors. We’ve been documenting these patterns for decades. But we still have bugs.
Let me put it this way: you can write insecure C++ STL code, despite the fact that “safe” STL programming has books, standards, and built-in checking tools
The types of errors targeted by the CERT SCI are similar to the types of errors that high-level languages such as Java are supposed to eliminate. But a typical Java network program is rife with security errors. Once you eliminate the simple vulnerabilities, like buffer overflows, attackers just move to logic flaws.
Right now, the SCI will help you avoid buffer overflows and integer errors. Good luck with SQL, or crypto, or state machines. Even against C code, a large portion of what Matasano finds is not textbook overflows
We already have standards for secure “products”, such as the DOD’s own Common Criteria. These standards are heavily touted by marketing groups and broadly ignored by the rest of the industry.
Especially if all the “standard” says is that you haven’t misused “strcpy” in any obvious way, and is then used to preempt customer security testing.
I guess I have a bigger problem with “secure coding standards”, and I can’t figure out how to say it without making 2 points:
The security problems of code that has already been written totally dwarfs the problem of new code, and standards don’t do much to solve that problem.
The solution to the secure coding problem is going to come from security QA, not secure coding.
Add New Comment
Viewing 3 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Add New Comment
Trackbacks