Tip

Oracle's Mary Ann Davidson: Secure coding? Absolutely!

Mary Ann Davidson, CSO, Oracle
Ezine

This article can also be found in the Premium Editorial Download "Information Security magazine: Screen test: App-layer controls beef up perimeter firewalls."

Download it now to read this article plus other related content.

Andrew Briney's Secure coding? Bah! article struck a chord, as it should have been titled "Secure coding? Absolutely!" Given that the software industry as a whole has never made a concerted effort to write better code, it's far

    Requires Free Membership to View

too early to throw in the towel.

Many are convinced that because we can't have perfect code, we shouldn't even try for good code. It's nonsense to give up on writing better code, especially when we appear to have plenty of time to invent new technologies that don't solve our problems.

Briney said, "Risk reduction is all about reducing vulnerabilities, mitigating threats and lowering event costs." However, most customers have almost no information on the security-worthiness of the products they buy, and some risks can't be mitigated. The single best thing the industry can do to mitigate users' risk is to write better software.

Software development must improve because software has become part of our critical infrastructure. As such, software development should be held to the same standards as other facets of critical infrastructure. Imagine if civil engineers built bridges with the same inattention to fundamental engineering practices as many software developers. Would it be acceptable to hear:

  • "I can't be bothered to figure out how to make the bridge secure. I'm only interested in using the latest cool building materials and having a sexy facade."

  • "Time to market is crucial. If I can't get my bridge up this month, my competitor will."

  • "It's not my fault if the bridge fails. I didn't expect so many heavy trucks on it."

There are no perfect bridges, but engineers are keenly aware of the ramifications of poor engineering practice. If they were as unschooled in secure design practice as the average software developer, we would have collapsing bridges and severe loss of life.

Briney said, "But it's even faster and cheaper to build crappy software to get the project rolled out immediately, please your boss and help the company make its quarterly number." Actually, it isn't. Much of secure coding practice is just good coding practice. Observing a good development process actually gets better quality products out the door faster.

"Secure programming is an oxymoron because none of the parties who could make it happen on a broad scale are properly 'incentivized,'" Briney said. There are many things that can and have happened to refute this. For one, customers can demand more secure software. The Department of Defense has made a good start by requiring formal, third-party security evaluations for products used in national security systems. This requirement may be extended to other agencies.

Security evaluations don't result in perfect software, but they do force vendors to follow a secure development process. Oracle has invested more than $17 million in security evaluations throughout the last 12 years, and I can categorically state that it has resulted in better products and more "security awareness" among our developers. Avoidance of even one significant security fault would more than pay for the cost of an evaluation.

More than 50% of security faults are a result of buffer overflows. If we, as an industry, merely stamped out buffer overflows in the next two years, we would reduce security faults by half and would significantly decrease our customers' risk exposure. Checking boundary conditions is measurable, achievable and something that every developer should have learned in their first programming class. If they didn't, they shouldn't be working in the industry.

In summary, my response to Briney's editorial is "Secure coding? Yes, absolutely."

About the author
Mary Ann Davidson is CSO at Oracle.


FOR MORE INFORMATION ON THIS TOPIC…


This was first published in March 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.