Recently there has been some discussion on BUGTRAQ regarding some companies
attempts to change the way they publish security advisories.
Some background:
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0036.html
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0042.html
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0056.html
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0054.html
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0076.html
http://www.securityportal.com/list-archive/bugtraq/2000/Dec/0101.html
Basically, it started when Microsoft abruptly switched to a new advisory
format where the notification e-mail included only a cursory description
of the problem and a [malformed] URL for the actual report. Today, Elias
Levy announced that @Stake wanted to switch to a format with more
information in the message but still requiring a visit to their website
for the full advisory.
Some interesting RISKS:
- Access for people with marginal Internet connections or browsers other
than IE/Netscape is less convenient.
- Information is unavailable if the webserver is down or overloaded, as
might happen with an important advisory. It seems counterproductive to
put important, time-sensitive material behind a single point of failure,
particularly when the decision is to deliberately avoid using a free
distributed, fault-tolerant distribution channel.
- It makes it much easier for a vendor to change an advisory without
notifying anyone, especially since changed or removed advisories won't
be archived in anywhere near as many places as a mailing list such as
BUGTRAQ. In addition to covering up bad work, this would also make it
easier to remove or tone-down past advisories about companies the author
is now aligned with.
- It opens the prospect of tailoring content to the reader. This could be
as simple (and annoying) as charging for access to some content or as
complex as determining what to show based on where the request came from
(e.g. competitors, vendors or journalists). While this would probably
be caught for something major, particularly at first, it would not
surprise me to find at least subtle tampering happening regularly if
this becomes commonplace.
I find it hard to ignore the above concerns given that the switch
provides no benefits of any sort to the reader, let alone enough benefit
to outweigh them. The only legitimate advantage from such a policy is
that it makes it easier for the author to change the contents of a
released advisory. For legitimate purposes, this is unnecessary:
- Updates to current advisories can be published in the same fashion as
the originals, ensuring that anyone who received the original will
receive any updates.
- It's extremely easy to add a link to the advisory which people could use
to check for updates.
- It discourages the use of proper change control, since it's easier to
update an existing advisory than release a update.
- It will cause old links to break if they ever move content
around and neglect to install a redirect for the old URL.
(Microsoft is notorious for this, especially with links that break
only for visitors using something other than Internet Explorer) ["Chris Adams" via risks-digest Volume 21, Issue 16]
0:00
#
G!
