Insecurity By Design

Kevin Kernan posts on C|Net that "the best long-term answer to the security problem is to make software intrinsically more secure."  Read that article here.

He goes on to discuss the inability of developers and security professionals to even talk about security effectively, and makes the point that instead of investing in all the security software that tries to protect the application software after its built, we should design in security from the start. 

Security should definitely be part of the design process of software. However, this only goes so far. The simple security issues (buffer overruns, etc) are easy to educate programmers about, easy to build tools to detect and should one day become extinct. Most developers know about these kinds of vulnerabilities already and strive to avoid them. Yet, still they persist. Getting it right is difficult and is not fool proof.

The real problem lies in the subtle vulnerabilities. Ones we don't know about yet, are difficult to recognize due to their complexity, or come about due to a combination of minor flaws that together add to trouble. These are hard to spot both by tools and human eyes.

SQL injection is a big problem. Even when educated to avoid it by validating input many programs still exhibit flaws due to weaknesses in their validating logic. Is this really an intractable problem? Are the developers just prone to never get it right?

Couldn't we solve the problem better by re-designing the data API's instead of putting the burden on the multitudes of developers with varying degrees of security smarts? The data API's are not flawed, they just don't protect you from this attack.

What if they did?

Comments

• Anonymous
  June 14, 2005
  The comment has been removed
• Anonymous
  June 16, 2005
  The comment has been removed