Secure coding? Bah!

Secure coding? Bah!

Andrew Briney, Information Security magazine

"The root of the vulnerability problem is that programmers don't know how to code securely. If programmers were taught security in the first place, my job would be 100 times easier."

How many times

    Requires Free Membership to View

    SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!

    Michael S. Mimoso, Editorial Director

    By submitting your registration information to SearchSecurity.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSecurity.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

have you heard this? All together now, repeat after me: Not gonna happen.

Don't get me wrong. Building secure software is a laudable goal. It boosts productivity and reduces costs. According to one study, it's 6.5 times more expensive to fix a security problem in the implementation phase than in the design phase of a software rollout. By the time you get to the maintenance phase, it's 100 times more expensive.

But we'll burn too much time and energy chasing a totally impractical objective. Secure programming is an oxymoron because none of the parties who could make it happen on a broad scale are properly "incentivized."

Industry leaders care about two things: how to make more money and how to spend less. The notion that secure programming helps them increase efficiency and cut costs in the long run ignores the fact that it's faster and cheaper to build crappy software to get the project rolled out immediately and help the company make its quarterly number.

Academia seems best positioned to influence this issue. But engineering and computer science curricula are developed by faculty who don't have the background, knowledge or interest in developing security coursework. Accreditation bodies aren't forcing the issue, and there's precious little research funding in this area. The result is a vicious cycle: No money, no research, no courses, no students, no workforce training and no matriculating Ph.D.s to break the cycle.

That leaves us with the government, which professes to want to change this problem but is hopelessly mired in bureaucracy. To date, the NSA has designated more than three-dozen universities as Centers of Academic Excellence in Information Assurance Education. Just ask the directors of these centers how much federal money they've actually received under this program, or how uniform their curriculum is compared to other centers. They're struggling, and they're frustrated.

Secure coding is yet another silver bullet. Risk reduction is all about reducing vulnerabilities, mitigating threats and lowering event costs. Secure programming, in theory, solves the vulnerability problem. But since the theory isn't ultimately practical, you have to concentrate your efforts on other vulnerability reduction efforts -- hardening, layering, patching -- while keeping your eye on emerging threats and managing incidents to reduce recovery costs.

About the author
Andrew Briney, CISSP, is editorial director of the TechTarget Security Media Group, which includes Information Security magazine, SearchSecurity.com and the Information Security Decisions conference.

This was first published in January 2004

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.