mailing list archives
RE: FW appliance comparison - Seeking input for the forum
From: "R. DuFresne" <dufresne () sysinfo com>
Date: Thu, 2 Feb 2006 17:31:02 -0500 (EST)
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 1 Feb 2006, Paul Melson wrote:
Subject: Re: [fw-wiz] FW appliance comparison - Seeking input for the forum
I think it would be interesting to know what type of group of was
responsible for managing
the firewalls in the study. I am moving an account off of a Checkpoint
being managed by a
services organization onto a PIX platform (no intent to start a vendor
war) - and I have
been surpised by the permissiveness, and redundancy, in the "managed"
ruleset. The managed set broke two of the major rules in the documented in
the paper - and
possibly a third if I had it on front of me.
Of course this takes a new tangent; but it would be an interesting study.
Haha! I have to tell you, as soon as I read this, I immediately thought of
two vendors and am wondering if either of them are the vendor in this case.
But embarrassing vendors - as fun as it is - isn't part of the list charter.
The one thing that always struck me funny about these situations where an
MSSP does a lousy job of remotely managing a Check Point rule base is that,
in order to get Check Point's seal of approval, you've got to run
Provider-1, which is a fairly large cash layout to start a service like
that. But then to not spend much if any money on staff and staff
I guess I shouldn't be surprised, but I am. And amused. But only because
it's not my firewall. :-)
Ahh, MSSP's, interesting worked with a couple over the years and
discovered that again for the most poart they tended to staff with
contractors with the same skills as a monkey with a fine tool can
accomplish. Jhiring someone with or near to acquireing a CISSP, and
giving them enough training so they are somewaht familiar with the layout
of the gUI to manges a checkpoint firewall box, yet not a clue as to what
the ports and protocols residing on those ports means, ended up with
pretty much open routers for the vast majority of clients. Thing I got
into arguments about with fellow staff and managers all the time was; a
client makes a stupid request, so what to I as the responsible tech in
such a case do? My argument was, let the client know why there request to
open up the world to theit network in a nast way was in fact stupid, they
afterall were paying for my expertise and guidance. Should the client
still insist that I impliment the stupid request, then yes, it's their
network and they have a full right to do stupid things in their own nest.
What I was combatting were those lazy folks that just insisted the job at
hand was to impliment and close the ticket as fast as possible as it
looked good to upper mgt for the fast turn around.
Of course, I was often shocked at the SLA's that formed the basis of the
outsoourced security contracts, which often failed to mention or
request/demand that expertise on the MSSP side was truely a factor in the
managed needs of the clients. Noe gets what one bargainsand pays for....
admin & senior security consultant: sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
firewall-wizards mailing list
firewall-wizards () honor icsalabs com