2003 Testimony to Congress Proves That We Still Have a Long Way to Go In Building Secure Software

Back in May 1998, as a member of the hacker think tank, L0pht, I testified under my hacker name, Weld Pond, in front of a U.S. Senate committee investigating government cybersecurity. It was a novel event. Hackers, testifying under their hacker names, telling the U.S. government how the world of cybersecurity really was from those down in the computer underground trenches.

Many in the security community know of the famous L0pht Senate testimony, but very few know that one of the L0pht members testified on Capitol Hill 5 years later. That member was me. This time I testified as a cybersecurity professional using my real name. I was the director of research and development at @stake, an information security consulting company.

Back in the summer of 2003, the internet was plagued with worms such as Blaster and Sobig. The U.S. House of Representatives Committee on Government Reform wanted to hold hearings to understand the problem. Why had 400,000 computers been infected with Blaster in less than five days when the patch that would have prevented the attack had been available for over a month? I was asked to testify to help the committee understand vulnerability research. How were the vulnerabilities discovered that lead to worms like Blaster, and why were these latent vulnerabilities there in the first place?

The problems I spoke of in 2003, sadly, are still here with us 18 years later. Large amounts of software are still not designed defensively… and not built with security testing embedded in the development process. The economics of software development still leads to the reuse of old insecure software. Computer users still loath updating to new, more secure versions of software due to costs and resources required.

I discussed how the root cause of viruses and worms was security flaws in the design or implementation of software. I still believe this today (even though most vulnerabilities are not “wormable” or attackers choose to attack with more precision). I discussed the problems with a ship-it-vulnerable, patch-it-later approach. Even now with some products using auto-updating, patching is often late or doesn’t happen at all due to the resources required to patch in an enterprise IT environment.

Most of what I spoke of was the world of vulnerability research. Who were the people – like the researchers from the Last Stage of Delirium – that discovered the Blaster vulnerability? Why would they do this? How did they do this? How is it possible that they found a security bug when the vendor didn’t?

Then I spoke about the safe vulnerability disclosure process: How researchers could work with vendors to keep the internet safer despite vulnerable software everywhere. This type of process is now widely followed by researchers and vendors and is codified into an ISO standard.

We have made progress on the challenge of building software more securely, distributing patches better, and handling vulnerability disclosure better. But the gains are far less substantial than they should be after 18 years. In my 2003 testimony, I said, “The current flawed computing infrastructure is not going to change for the better overnight. It will take many years of hard work.” We are still in the “many years” phase and perhaps will be for another decade. Take a look at my 2003 testimony and see for yourself just how far we still need to go.