Vendors slow to act on bug reports

Two Australian organisations - a bank and a security consultancy - say vendors are not responsive when they report newly-found bugs.

If you watch the world of security, the pace at which security updates are announced probably give you the impression that vendors respond smoothly and quickly to news of a security vulnerability.

Not so, according to Jason Edelstein, co-founder and CTO at Sydney-based Sense of Security.

Edelstein says one of the biggest gaps in IT security remains the uneven way in which software vendors handle security issues. To explain where things go wrong, Edelstein first explained the process that Sense of Security follows when it finds a vulnerability.

“First, we do the research to validate the bug – we will build a proof-of-concept that proves the bug can be exploited.”

“If you go to a vendor with a theoretical bug, even if you can describe it technically, unless they replicate it they won’t believe it. So the proof-of-concept is necessary – you do something like launching Windows Notepad on the desktop because of a buffer overflow, something benign like that.”

With the proof-of-concept ready, the next step is notifying the vendor, and even in these days of heightened security awareness, Edelstein says this can be a challenge. Some vendors will have a single point of contact for security notices, “but for a lot of vendors, it’s very difficult to find out how to lodge a report.”

Even if notified of a bug, with the proof-of-concept and a statement that an advisory will be issued if there’s no response, Edelstein says vendors can be slow to act. In general, both as a courtesy and in keeping with his belief that Sense of Security should only disclose the vulnerability when the vendor can deliver a fix, the company will follow up the notification with the vendor.

Vendors that have strong security responses aren’t the problem: but response is far from uniform.

Responses to notifications from Sense of Security have included a rebuttal (“We don’t believe the vulnerability exists because this software has been vetted by a Big Four firm”), ignoring the advisory, requests for further demonstrations because the vendor lacked the ability to compile the exploit source code for itself, through to outright hostility.

“We’ve had a cease-and-desist letter in which the vendor threatened to take legal action if we released the code,” he said. The same vendor also threatened legal action if Sense of Security tried to contact it again.

Life better for the big customer

In part, the issue is the nature of the relationship between a security consultant and a vendor. If, for example, you’re a large bank with a contractual vendor relationship, things are easier. Peter Martin (not his real name) is in charge of security at a major Australian bank, and spoke to Tech Target on condition of anonymity.

Because a bank is in a position to “beat up” on its vendors, it can at least avoid the non-responsiveness Edelstein reports. However, Martin said, that doesn’t necessarily achieve a quicker response.

“If we’re doing penetration testing and we find something – we do notifications just as any organization would, following the recommended process.

“But if it’s a critical failing we find, we’re in a position to harass them and get it chased up.”

Corporates too small to have a dedicated security team, or independents too small to attract the notice of a major vendor, are much more likely to run into trouble, Martin said.

In that sense, vendors’ responses may well be inadequate. Only “a small subset” of organizations have the capacity to discover critical security vulnerabilities, he said. It makes little sense to attach importance to a vulnerability according to the size or familiarity of the organization making the notification.

While things are changing, Edelstein says the core problem remains that software vendors aren’t in business to find bugs, they exist to ship the next version out the door.

“There’s no real legal obligations on a vendor to fix bugs – because they don’t make money out of fixing bugs.

“The real pressure is rolling out new code and selling licensees – getting the product out the door.”

However, Martin believes the slow move towards making software “secure by default” is starting to gather pace. “The best thing vendors could do is to follow more secure coding practices.”

Edelstein agrees that coding is becoming more secure, but remains convinced that the software industry needs to get better at handling notifications that come in from the outside, rather than relying on solely on their own tests – or their own self-interest – for the discovery and repair of security bugs.

Read more on Data breach incident management and recovery