lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200208021807.OAA26250@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: it\'s all about timing

>It is interesting that the people screaming loudest for some sort of
>order in the submission of bugs, are in fact non-bug hunters at
>all. Rather a vocal group academics who intent of have their name on a
>draft or ratified document they came up with. Sure some may have
>posted a few findings but none are consistently doing so, and the bug
>hunters, sure don't sound like they need some else telling them what
>to do. You don't hear them crying to for order.
>
>Wonder why that is.

I think it's because there are more "consumers" of vulnerability
information than just other bug hunters, for example, people who want
to remove those bugs from their vulnerable systems.  I would be very
interested in hearing the experience of bug hunters who are also
responsible for the security of large, diverse networks; they may see
this situation from both angles.

The audience for a security advisory includes individuals and
organizations with many different needs for security information.
Having some order to disclosure can make it easier for people to
identify the vulnerabilities that they care about, and to secure their
systems.

The audience includes:

- System administrators, who often need to manage or support dozens of
  products

- Security administrators, who need to research and understand
  hundreds of vulnerabilities across their enterprise, and who may not
  fully understand all the products that have been deployed at their
  enterprise.

- Vulnerability database maintainers, who need to research,
  understand, and/or verify thousands of vulnerabilities.  Since
  databases are relied upon by many people, errors or inconsistencies
  in your own advisories will be multiplied greatly.

  For a list of some of the challenges in vulnerability database
  maintenance, see my post at:
  http://lists.netsys.com/pipermail/full-disclosure/2002-July/000568.html

- Vulnerability researchers, who may have specialized research
  interests that require greater detail (or different types of detail)
  than most of your audience.

- Potential customers, or the consultants that they rely on

- Existing customers who care about security issues but do not
  regularly read advisories


Sysadmins and security admins often have time pressures that may make
it difficult for them to sift through "noisy" vulnerability
information - incomplete, inaccurate, etc.  If an advisory is released
without a vendor patch, the admins then have to keep track of which
bugs are outstanding, and figure out which researchers they can trust
when there is no vendor patch.

One of the roles of vulnerability databases is to sift through the
"noise" and make it easier to access vulnerability information.  But
since it's resource-intensive for experienced vulnerability database
maintainers to manage the noise, it seems reasonable to assume that
admins may have difficulty managing the same information... or at
least figuring out which information is actually correct.  The job is
only going to get harder with the increasing de-centralization of
vulnerability information.

In my experience, the most informative and accurate security
advisories offer a mixture of the details that researchers provide,
along with the correct version, fix and actual cause of the problem,
as is often best known by vendors.

High-quality information may not be needed by everyone, and some
people may not think it's important, but better information means
better security overall.

- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ