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 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:
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
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
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…
