A trio of
vulnerability researchers on a panel at the
Gartner IT Security Summit have put a new spin on the
discussion by suggesting that it's time for enterprises to shoulder
some of the responsibility for testing applications.
By doing their own research before they decide to buy or deploy
a new product, IT departments could put pressure on vendors to pay
more attention to security, the panelists said.
 | | | | | I guarantee you that if an
enterprise finds a vulnerability in a product it's about to deploy,
they're not going to wait two years for a fix.
Thomas Ptacek,
principall and founderMatasano
Security |
| | | | | |
| |
|
But a trio of vulnerability researchers on a panel at the
Gartner IT Security Summit here today managed to put a new spin
on the discussion by suggesting that it's time for enterprises to
shoulder some of the responsibility for testing applications. By
doing their own research before they decide to buy or deploy a new
product, IT departments could put pressure on vendors to pay more
attention to security, the panelists said.
"One of the ways that we make vendors more accountable is we let
them know that we're going to do our due diligence before we deploy
a product," said Thomas Ptacek, principal and founder of Matasano
Security, a consultancy based in New York. "Enterprises should be
using security as one of the criteria in product testing and the
purchasing process."
Security researchers and customers both have complained for
years about the amount of time it takes many vendors to fix
security vulnerabilities once they're notified. Most large software
companies, like Microsoft Corp., Oracle Corp., and others, have
established guidelines for dealing with new flaws and researchers
know roughly how long it will be before a patch is ready. But many
smaller vendors don't have such processes in place, and it's not
uncommon for it to take them six months or more to fix a
vulnerability.
This has led to the practice by some researchers of publicly
disclosing details of a vulnerability before a patch is ready—or
threatening to do so—in order to pressure the vendor to act more
quickly. That behavior is less common now than it was a few years
ago, as many researchers now abide by some form of disclosure
policy whereby they might release a few details about the flaw and
then wait to disclose the rest until a fix is available. This
responsible disclosure philosophy has
placated many vendors, but some in the research community still
don't think much of it.
 |
| Responsible disclosure: | Middle ground hard to find in vulnerability
disclosure debate: Security experts at RSA Conference 2007
passionately debated the cases for and against vulnerability
disclosure, while some believe the arrival of Web 2.0 software
will hinder white hats and embolden malicious hackers.
When signature based antivirus isn't enough
Zero-day exploits, targeted attacks and increasing demands for
endpoint application controls are driving the rapid metamorphosis
from signature-based antivirus and antispyware to HIPS-based
integrated products
Why hacking contests, 'month-of' projects don't
help: Ivan Arce, chief technology officer of Core Security
Technologies in Boston, is a big proponent of penetration
testing as a way for companies to find and fix their
vulnerabilities.
Podcast:
Security Wire Weekly -- May 16, 2007 - Core
Security's Ivan Arce discusses the pros and cons of penetration
testing, "month-of" flaw disclosure projects and hacking
contests.
|
|
| |
|
David Maynor, co-founder and chief technology officer of Errata
Security, likened vulnerability disclosure to noticing that the
front door to a neighbor's house is open. If you call and tell the
neighbor, and don't tell anyone else beforehand, that's no
disclosure. But if you call your friends, go in and have a party
and swim in the pool, that's full disclosure, he said.
"The equivalent of responsible disclosure is you go in, eat some
food and try on some of their clothes and then you tell them their
door is open," Maynor said. "I'm not a big fan of trying on other
people's clothes to be honest."
Chris Wysopal, chief technology officer of Veracode Inc., and a
long-time vulnerability researcher, said things aren't always that
black and white in the real world.
"Some things take more than a few weeks to fix," he said. "I've
waited over a year for things to be fixed because they were serious
design flaws."
Wysopal also agreed with Ptacek's contention that enterprises
should be more demanding of the vendors they deal with. While
everyone is worried about the disclosure policies of individual
researchers, he said, who is holding the vendors accountable for
the way they handle bugs?
"Some of these vendors are irresponsible. They have to actually
communicate with the researchers," he said. "Customers need to hold
vendors accountable. Ask your vendors what their policy is when
they get a vulnerability notice from a researcher."
Most large enterprises do some level of testing of new products
during their buying process, but much of it is focused on the
performance of the application and whether it works well with the
company's existing infrastructure. That, the panelists said, needs
to change if customers expect software makers to sit up and take
notice.
"I guarantee you that if an enterprise finds a vulnerability in
a product it's about to deploy, they're not going to wait two years
for a fix," Ptacek said.