Re: Vulnerability Response (was: BGP TCP RST Attacks)

["Paul D. Robertson" <paul () compuwar net>]

On Wed, 2 Jun 2004, David Lang wrote:

> unfortunantly this is much easier to say then to define, especially when
> you have disagreements between departments over the liklyhood of something
> beign exploited "Vendor BIDNAME says that their equpiment that will span 5
> networks is perfectly safe and can't possibly be comprimised becouse they
> don't run an OS" from the folks who want to install something vs the
> security departments view of the same hardware "these are x86 based nodes
> plugged into every network with an ethernet backplane between them, they
> are a very high risk"

That's a function of being in the room when $vendor proclaims that their
code is the only code ever written securely.  Asking for proof (or better
yet formal proofs,) metrics, measurements and independent assessments and
explanations of how they handle specific circumstances wins almost every
time.  "How many bugs/kloc do your coders produce?"  "What's the number of
bugs in your bug database for $product?"  What happens if there's a bug in
your interface and someone does the following..."

You *need* to be in those meetings- because then the users see that the
vendor's sales rep and his support *don't* have all that much security
clue, and really don't know all that much about their products.

While it's fun to make the vendor turn tail and run, the real objective is
to ensure that (a) the vendor sweats enough to make the pricing
negotiations much easier, and (b) you can either shoot down the stupid
ideas, or offer "safe" alternatives to doing things the wrong way.

One of the best quotes yet that I got from a vendor in a meeting was
"Stop!  I can't think that fast!"  In that case though, the users were
being pressured into evaluating and possibly purchasing something they
didn't want- but politically couldn't dismiss themselves.  I got invited
to do the thing they were used to seeing me do- beat up the vendor over
security- but this time it was to their advantage for me to poke holes in
it, since it'd give them ammo for rejecting the whole silly scheme.

> let alone the more subtle issues of how expensive the risk is to open one
> more port through a firewall.

Get some sand, a bucket, a nail and a hammer, and *show* them how much
effectiveness they lose with each port.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards