I fully agree, and would like to add that the point here (fro me) is that:
a security vendor has something of his own hacked.
how has this been done and why may be important or not depending
on your opinions, but this directly lower their credibility as a firewall
vendor. How would I, a customer among others, believe their
sales guy when he comes and say "ya know, we are good at security,
s you can use our product with confidence". my first reply, and I'm sure
that's the same for many people is "oh, sorry, but no I won't trust your
company since it has been incapable of securing its own site. either
gimme serious arguments or I'll go another place".
In other words, the incident makes their selling process harder. They can
no more rely on TIS history and the robustness of the proxy architecure, as
one could say "ok, TIS were great. what you guys have done to the Gauntlet is
a crime...."
cheers,
mouss
At 08:31 07/12/00 -0500, Frederick M Avolio wrote:
>At 06:26 AM 12/7/00 -0500, Crumrine, Gary L wrote:
>>I agree that pointing a finger at the ISP may be the easy way out, but it
>>may not be all their fault. Both the ISP and NAI are victims... not the
>>criminals.
>
>Generally, this is the same as: Well, it's an outside web server and it
>doesn't have any secret stuff on it, so it is a sacrificial lamb
>system. As I've mentioned before, the term "sacrificial lamb" has less to
>do with the system and more to do with you and your job if you're supposed
>to secure it.
>
>If it has your company name on it, you suffer. Years ago, before the web,
>there was an FBI machine on the UUCP network. It was basically a PC that
>sat in a back room. Not connected to anything else. But... it had the name
>fbi.gov associated with it. So whatever happened to it reflected on the
>FBI. When the CIA web site was hacked, it didn't matter that it wasn't
>connected to any secure system. It was a site that had "cia.gov" in its name.
>
>Blame doesn't imply criminal behavior.
>
>Is the attacker to blame. Of course, and it was criminal behavior (in some
>places).
>
>Is the ISP to blame? Sure. Anyone offering web site space and support
>should also provide the best security possible. Most ISPs are clueless
>about security. And their customers are more interested in speed and
>connectivity and up-time than they are about how the web server is
>secured. So, the customers are to blame, also, for not demanding something
>better.
>
>Is NAI to blame? Sure. As a customer, as I said in the previous paragraph,
>if they did not demand to see a security architecture and monthly audit
>reports (anyone do that with their web site provider?). Also, as a
>supposedly clueful security company, if they did not require hardening of
>the NT server, and installation of their fine IDS tools. Also, they should
>be doing periodic verification of all of their systems exposed to the
>outside, including those hosted by others. Would their vulnerability
>scanner have detected an unpatched IIS? It should.
>
>Could NAI have done everything possible, done it almost flawlessly, and
>still had this happen? Yes. But they still bear part of the blame. They
>are still responsible. It's their site and they are a security company.
>
>It doesn't mean that they should pack it in and they no longer have any
>credibility. If that were the case, where would Microsoft, Cisco, and
>Check Point be? But, as I said yesterday in a post, it should at least be
>a warning to other such companies, especially the small to medium sized
>security vendors, to be aware of the pitfalls and to not get so sloppy.
>
>
>Fred
>Avolio Consulting, Inc.
>16228 Frederick Road, PO Box 609, Lisbon, MD 21765, US
>+1 410-309-6910 (voice) +1 410-309-6911 (fax)
>http://www.avolio.com/
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
