Scott Seidler wrote: > > Aleph - Im reforwarding this to you as submitted on friday - it is a > rebuttal to JIM MAZE's comments re the post i made earlier. He seems to be > unreachable using his listed email at: jmazeat_private I'm sorry if you were unable to reach me at that address. That's the first complaint I've heard, but I'll check it out. > > pc to run it, operating system costs (most of our customers are NOT > willing > > to run Linux or BSD) and the cost of the software itself - its not much That's probably because they don't understand it. I find that if you take the time to explain the technology at a level that they can understand it, people are willing to trust your recommendations. And it's also a pretty easy sale, seeing that Linux is free. > > CHeck out this little sniglet from a recent > > email i recieved from Cisco announcing NSA testing results: > > <snip> > > >The PIX Firewall underwent an arduous seven month product testing > scenario > > >that mapped the PIX security targets (ST) against the user application > > >scenario prescribed by the Government's Protection Profile. The PIX > > >Firewall Security Target was found to comply to the requirements at CC > > >Evaluation Assurance Level 2 (EAL2) , as defined in the Common Criteria > > for > > >Information Technology Security Evaluation (CC), Version 2.0. The PIX > > >Firewall has subsequently become the first, and only, Firewall to be > > >certified as conforming to the US Government Application Level Firewall > > >Protection Profile for Low Risk Environments. > > <snip> That's funny. How can the PIX be certified as conforming to any "Application Level Firewall Protection Profile", when the PIX is not an application lever firewall? As you know the PIX is based on stateful packet filtering - not application layer proxies. It seems to me that the Traffic Filter Firewall Protection Profile for Low Risk Environments certification would be more appropriate, eh? http://www.radium.ncsc.mil/tpep/library/protection_profiles/ > > .. Not to mention the throughput through the unit rated to T3. Its really > > simple to install as it comes completely shut down to the outside world > > with only a handful of commands to create a one way firewall - whereas a > OS > > would need to be "stripped down" as you mentioned, and specifically setup > > for the Firewalls use. > > > > Unfortunalety - putting the customers in-house capabilities aside - the > > time it takes to set up a pc based solution and configure even free OS > into > > it with free security software (factoring the time it takes as well to > get > > some technical support on the set up etc.) a Hardware based solution like > > the PIX for a street price of about 8K ends up cheaper every time weve > > looked at it. > > Here's the problem with the PIX, and any other packet filter - stateful or not. The darn things don't break the client server connections. Every network in the world has at least one mail server and one web server. With a PIX, you have to have an ACL entry that allows port 25 to the mail server and port 80 and possibly 443 to the web server. The problem is, any traffic that meets these basic requirements will pass right through unrestricted. The client applications talk directly to the server applications - which is never a good thing from a security perspective. Ever hear of buffer overflows, cgi manipulation, sendmail? That's why I would choose a proxy based firewall for the perimeter every time. > > So I guess i do really agree with what you said - IF the inhouse > personnel have the time and knowhow to gather the systems, the software, and IF > they have the time to invest to set it all up and keep it locked with fixes > and patches. (and there are the bugs). IF they can do all that and not > include a dollar value on their time, then it wont cost that much money for good > security. > > > > Unfortunatley, these are not our typical customers, as a matter of fact, > it > > isnt ANY of our customers. > > Hmmmm. I'd hate to start sounding like a commercial.....but I'm working on a solution to this problem. If you'd like to hear about it, e-mail me privately. > > So to get back to the original point i was making re: money and security > > that seemed misleading: IF you have the time and IF > > you have the expertise and IF your company will even allow you to use > > Freeware (most wont) then you COULD spend little > > money and get a great security solution IF you dont factor the customers > > time. > > Name a single company that doesn't use tcp_wrappers somewhere in the network, or triwire, cops, tiger, crack, ssh, nmap, s/key, or smap. All Freeware. Also, what are the issues your clients are bringing to you regarding freeware? The problem used to be commercial support - but with companies like Red Hat offering commercial support, there should be no objections for using Linux in the corporation today. Again, I think it just takes someone being able to communicate the technology effectively to the people in charge. > > For our customer base - this isnt a solution. > > I hear you. But just because it isn't an appropriate solution for your market doesn't mean many companies won't benefit from having a complete understanding of their options. I'd hate for smaller companies to not try to secure their networks because they think they won't be able to afford it. > > -- Scott > > > > sseidlerat_private -- Jim jmazeat_private -or- jmazeat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:00 PDT