I am not connected with CERT (other than knowing a number of the people
involved) and can understand Mr. Moran's position. It is true that generally
CERT is "input only" and, while I do not necessarily agree with their
position, it is arguable.
CERT does not and cannot provide solutions, they are not funded to do so.
It is also their policy not to discuss reported problems other than with
the developer of the product in question, and only to produce advisories
when a fix for the problem is available.
Having tried to convince manufacturers before that there is a problem, IMHO
CERT plays a very necessary role in this matter since CERT does not have
to establish credentials.
I do have an advantage over CERT in that, as a hobbyist, I can create and
distribute a "fix" with no guarantees or warranties, something neither CERT
nor the manufacturer can do (one of the problems with a litigation-happy
society). Of course since the "bad guys" enjoy this freedom also, it is a
difficult matter. I can state uncategorically that it is *much* more difficult
to write an anti-virus program than a virus, much easier to hack/crack than to
protect in a manner inoffensive to legitimate users, but then I am egotistical
enough to accept those handicaps.
Back to the subject at hand, for example there is currently what I consider a
severe problem in Novell Netware 3.x and 4.x that will not be discussed openly
just yet since there is no fix. Novell has been contacted and hopefully a new
"feature" will soon appear - for Novell the fix should just require a simple
change to a single program (maybe 2).
My advantage is that for me this is an ethical choice and not a policy
or business dictate, a freedom which neither CERT nor the vendor enjoys.
I do know that many people within such organizations do not necessarily
agree with such decisions but have no choice in the matter.
Thus I do feel that CERT plays a very valuable role in the process of
computer security though it is not often visible as such.
Padgett [padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) via risks-digest Volume 15, Issue 20]
13:06
#
G!
