Friday, September 20, 2013

Engineering Software That Is Difficult To Exploit

A recent post to the SC-L mailing list lamented an interview with an executive where the executive stated his company's approach to software security was to raise the cost/complexity bar for exploring their software.

The poster wrote "The response to vulnerabilities was to raise the cost/complexity of exploiting bugs rather than actually employing secure coding practices."

I don't believe the person posting really understands the goals of software security, or is simply failing to understand these are not opposing goals. If you still delusionally believe that you can engineer all security bugs out of your code, I think you don't understand modern software security. You may also be setting some unrealistic goals.

Even though I've assisted enterprises with employing "best practices" and a plethora of tools and procedures to integrate software security into their various SDLCs, they still produce security defects/bugs. This is nearly universal. Even organizations that understand the difference between flaw and vulnerability, to quote Gary McGraw, still fail to eliminate all security defects. The answer for these groups is to make defects more difficult and more costly to exploit. There is absolutely nothing wrong with setting this as a goal, in my experiences.

This approach doesn't herald giving up on writing secure software but rather acknowledging ratcheting cost/complexity of exploitation is a valid piece of the overall software security program.

Quite simply, failing to understand this results in frustration and continued alienation between security and development personnel.

Should your goal be to produce more secure software? Absolutely.

Should you're goal be to force your adversary to spend more anf work hardet to exploit your code? Absolutely.

Are these two opposing concepts? Hell no.

No comments:

Google+