The bugs stop here

1 2 Page 2
Page 2 of 2

"There's a fair bit of marketing involved because, no question, it's a politically tricky situation," says the aforementioned unnamed divisional IS officer of a large bank. "No matter how you approach development, they'll resist. They'll say you're threatening their timetables. If you're a jerk about it, you end up losing and things don't get secured."

"There is a delicacy to confronting development," agrees IndyMac Bank's Weber. "The application scanning tools add some objectivity. The CIO should also set development requirements and get management buy-in first. That adds more objectivity. If you clearly define the security parameters, development can't make it a personal argument or a grudge match."

It's easy to see how it could devolve into politics and sniping when Weber explains what he's really doing. "My job," says Weber, "is to impose a security will on the developers."

Use freely available security standards

Start with NSTISSP No. 11 (PDF format), the national security standard that mandates that any software used in a national security setting must pass certain government audits. Learn the criteria, and then demand that your developers and vendors meet them.

The government has many other security standards. None is a defining standard but virtually every one of them contains something useful. Special Publication 800-27, a NIST document, for example, contains 33 application security principles. (One of them: Implement least-user privilege, which means start with all access turned off and turn it on only as needed, not vice versa.)

It's important to note that most of the standards are foundational. That is, they're most useful for software at the design and requirements phase, and less useful for applications that have already been developed and deployed.

Put security in writing

Ferderer now requires that his vendors do application scanning on every software package Mutual deploys.

"The trend to put security right in contracts has become quite successful," says OWASP's Curphey. "It's more common and more accepted than ever, in part because there are the tools which, to a degree, lend objectivity to the security of an application."

A contract signed between General Electric and the software vendor General Magic last year excited security experts. Section 7.3 is called Code Integrity Warranty, and it holds the vendor financially accountable for bad software and requires the vendor to fix it.

Tick off these to-dos too

After buying the software, re-educating your developers, poring over standards and hanging out with contract attorneys, you can (if you have the energy):

  • Check out OWASP. Weber at IndyMac Bank lifts heavily from the OWASP guidelines for secure Web application development.

  • Read Winning with Software, by Watts Humphrey, and have the developers read Writing Secure Code, by Michael Howard and David LeBlanc.

Send your developers to school. College-level computer science classes in writing secure code are starting to appear. At SEI, fellow Humphrey (called "the Edwards Deming of software") has developed an entire development methodology for secure coding called the Team Software Process (TSP).

Microsoft recently put a small group of coders through TSP's intense two-week training. The group was then charged with rewriting a 24,000-line application under the TSP process. The goal was to reduce the number of defects in the program from 350 to about 22. Microsoft says a post-production defect costs it $4,200. If the company meets its goal, the total cost of post-production defects in this small application (it's an internal one) would shrink from $1,470,000 to $92,400.

Don't give up, don't ever give up

Asked if he was more optimistic now about security than he was four years ago, when Melissa first hit, Rich Pethia says flatly, "No."

That's an unsurprising response from the director of the CERT Coordination Center, charged with disseminating early notice of serious vulnerabilities. CERT has logged more than 182,000 security incidents in 14 years, 82,084 in 2002. From 1995 to 2002, CERT mapped 9,162 vulnerabilities, nearly half of them last year.

So you'd expect Pethia, who has briefed President George W. Bush on such matters, to be gloomy. Still, Pethia thought for a minute and then revised his stance.

"Actually, I am a little more optimistic," he says. "There's far more awareness. The economy is terrible, so people can't afford insecure applications. After 9/11, there's a national sense of what these vulnerabilities mean. We're starting to put numbers on the problem and use risk assessment tools. That means insurance will soon get in the game, which is always a big step for security."

Combine these factors, Pethia says, and there's a breath of hope. In fact, he's convinced that one more ingredient will validate his optimism: proactive CIOs who demand better software.

So what exactly are you waiting for?

This story, "The bugs stop here" was originally published by CIO.

Copyright © 2003 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon