What Can Be Done About Software Security?
Good project management, enterprisewide commitment, ongiong training seen as crucial
July 1, 2007 —
(Page 1 of 7)
Security flaws darken the sky over every company that encounters them. The consequences can be so severe that it is remarkable flaws continue to persist after years of stakeholders enduring the expense, pain and risks associated with insecurity. But just as a spate of failures of cast-iron bridges in the early years of Victoria’s reign caused the British government to regulate railroad construction, so too may failures in software security lead to future government controls on how code is written.
Gunter Ollmann, director of security strategy for IBM’s Internet Security Systems division, reported in May 2007 that ISS researchers had analyzed more than 7,000 publicly disclosed bugs in 2006. Strikingly, Ollmann estimated that the number of new code vulnerabilities could exceed 139,362 per year, increasing the perceived risk of zero-day vulnerabilities exponentially.
Software has transformed into a critical part of our infrastructure, yet its architectural standards are not on par with physical structures such as bridges. Although every situation is different, the experts SD Times interviewed for this story reached consensus on some of the most common underlying factors that beget flaws: Fundamental project management, organizational commitment and training were the most frequently discussed topics among those interviewed.
John Heimann, Oracle’s program director in the global security product group, observed that most companies have not defined standards for secure coding. But management must define standards, explain what they mean to developers, and measure developers on their achievement, he said.
Tight schedules may also lead to lax software security. Rex Black, president and principal consultant of Rex Black Consulting Services, said that schedule pressures drive out a lot of things required to produce quality software. “[Management believes] that pressure is part of getting peak performance out of an organization. There is frustration at the contributor level about constant pressure to meet dates. You can’t be surprised when [developers] don’t deliver fully functional or secure code.”
SPI Dynamics co-founder Caleb Sima remarked that even if management conveyed requirements precisely, another problem is that the person who created those requirements needs to know security. “Product managers deal with customers, not security. There must be a dedicated guy helping the product manager.”
Share this link: http://sdt.bz/30849