[c-nsp] Visible bug IDs and Cisco service requests

[Buhrmaster, Gary]

(comments below) 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ted 
> Mittelstaedt
> Sent: Tuesday, June 28, 2005 11:12 PM
> To: Clinton Work; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Visible bug IDs and Cisco service requests
> 
> 
> 
> >-----Original Message-----
> >From: cisco-nsp-bounces at puck.nether.net
> >[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Clinton Work
> >Sent: Tuesday, June 28, 2005 3:34 PM
> >To: cisco-nsp at puck.nether.net
> >Subject: [c-nsp] Visible bug IDs and Cisco service requests
> >
> >
> >
> >I have a case open for a 7206/NPE-G1 that crashed and the issue
> >has been
> >traced to bug CSCdz80661. I asked the case engineer to make the
> >bug visible
> >in the bug tool, but he has refused. Shouldn't customer 
> encountered bugs
> >be make visible on the CCO?
> >
> 
> Clinton,
> 
>  This is a moral issue that Cisco has been grappling with for a long
> time now.  The problems are;
> 
> 1) Showing bugs that customers haven't found can be used as ammo by
> competitors.  Bad for Cisco, Good for customers.
> 
> 2) Showing bugs can puncture egos at Cisco.  Bad for Cisco,
> neutral for customers.
> 
> 3) Showing bugs can undercut marketing campaigns by Cisco.  Bad for
> Cisco, neutral for customers
> 
> 4) Showing bugs can make some customers change purchasing decisions
> since the features they need don't work right.  Bad for Cisco, Good
> for customers.
> 
> 5) Showing bugs can reveal vulnerabilities that crackers can exploit.
> Bad for Cisco and Bad for customers.
> 
> So you see it isn't black and white.  How would you feel if you bought
> a new router that was supposed to do some particular task and 
> it didn't
> because of a bug?  Conversly, how would you feel if someone broke into
> one of your routers after reading about a bug on CCO and writing an
> exploit for it?
> 
> Ted

<soapbox>

Let me address your points.

This bug *has* been found by a customer (or at least that is the claim).
If it has been found in a non-engineering code line, the bug should
be available for others to research.  Perhaps I am in the minority,
but I find doing my own research in the case collection produces
the best results.  I want the information to be accessible to me.
Actually, I want more detail to be accessible, so I can decide if
the bug is relavent (personal pet peeve is that the bugid details
are so sparse I have to guess about most of the details).

Any engineer who is not aware of his/her limitations needs an
ego adjustment, not protection.  Mistakes are made.  Test cases
are inadequate.  Bugs are introduced.  Deal with it.  The value
of an engineer is not they s/he never makes a mistake, it is that
that person, overall, contributes more positive results than 
negative.  Take pride from the good work.  Learn from the bad.
I believe Paul Vixie takes some perverse pride in having been
personally named on more CERT advisories than any other individual.
What that actually tells me is that (at least) at one time he
was a very prolific coder.  And the more you do, the more
opportunity for making mistakes.

Cisco (claims to) take pride in itself as an engineering company.
Engineering companies should not let marketing get in the way of
good engineering.  But no matter, good marketing should never say
you have no problems (when was the last time Boeing/Airbus said
"we never crash" and anyone believed it), but emphasizing the
positive.  No one believes Cisco products are perfect (replace
Cisco with any competitors name).  One choses a vendor/partner
on more than how many bug reports are available.

If it is good for the customer, should not Cisco help the customer
make the best decisions?  Nothing hurts a long term relationship
more deeply than trying to hide the ugly or the embarrasing.  I
keep hearing that Cisco is in it for the longer term.

While I have no objection to witholding the fact that a security
bug exists for a limited time so that Cisco can produce a security
fix, eventually the fact that a bug exists (because a security
advisory is released) is known.  I do not need the details, but
I have a right to know the bug exists and that it be visible.  But,
there is no evidence that has been presented that this is a security
bug.  Unless you are going to admit to this being an undisclosed
and unfixed security hole.  Oh, and btw, an exploit will be
written in a few hours after announcement of the fix anyway
(if it is not already "out there").  Get over it.

As a final thought, I used to use IBMlink to access the IBM OS
bug database (APARs/PTFs for those who remember such things).
Those bug reports were fully searchable, and included enough detail
so you could know what was what.  I got quite good to be able
to evaluate the impact of the known bugs on my environment.
And that was possible because part of the responsibility for
entering information into that database was to fully explain
the problem, and the impact so that the customer could make
that evaluation.  Yes, there may have been some internal use
only details not included, but the essential information was
there (unlike Cisco's "interface may hang" bug summary
descriptions which just annoy me.  The moon may shine tommorow
too, but that provides me with no useful information).  Those
IBM programmers/engineers did not have problems admitting to
bugs in the code, nor that bugs existed.  They were also willing,
from time to time, to accept my suggested fixes (we had source
in those days).  While I am no longer a customer of IBM, it is
my understanding that that database, and customer access to it,
still exists.  Cisco would do well to look at IBM's example of
how to do things better in bug reporting to the customer.

</soapbox>

Gary