RE: Firewall: dedicated equipment x Unix workstation

[Frank Willoughby <frankw () in net>]

Gary Crumrine brought up some good points in his mail.


> The wisdom from the past used to point that way, but I have had a 
> change in heart lately.  After trying to convince clients that they 
> need a box for a firewall, a box for virus checking, a box for 
> intrusion detection, a box for RAS dialin, a box for a mail server, a 
> box for a web server, and a box for an auth server for VPNs... yadda 
> yadda yadda.. their eyes just glaze over and they walk away mumbling 
> to themselves.  There we go shooting ourselves in the foot again.


Gary's idea makes sense from a user perspective.  It can save a lot
of money in hardware, software, and sysadmin costs.  Unfortunately, 
there also a couple of issues which need to be examined.

As the firewall is in series between the Internet and the company's
network, it is also a single-point-of-failure.  Assuming that 
the firewall isn't vulnerable to other attacks (including Denial-
Of-Service (DOS), then the additional functionalities/apps may 
actually *decrease* the level of security and performance otherwise
afforded by the firewall.

Here are a couple of implementation issues that should be examined
before trying to integrate everything into the firewall:

o Performance.  CPU cycles spent on <insert application here> 
   are CPU cycles that aren't spent on firewalling.  This slows
   down the network connections.  At some point, an additional 
   firewall may be needed for load balancing to make up for the
   lower performance (so we really didn't gain anything here).

o Security.  From a security perspective, a firewall should be 
   a dedicated box.  Anything not directly related to firewalling
   should be removed from the system.  The reason is that each 
   additional application presents a potential avenue for an 
   attacker to launch a DOS attack against the firewall, or 
   exploit a vulnerability in the application that might permit 
   the attacker to seize control of the firewall.
   
o Interoperability.  Some things may work well together on the
   same box, others won't.  Placing the different applications
   on different boxes reduces the chances that one application
   will interfere with another. It also reduces potential downtime
   trying to troubleshoot problems that the customer won't be
   able to solve.  

o What is the vendor's core competence?  If it is a firewall
   vendor, then their anti-virus software probably won't be
   as good as an anti-virus vendor's.  Even if the vendor
   acquired the application vendor's companies, getting the
   engineering teams to work well together won't be easy.

o It adds to the complexity of testing.  This alone will 
   probably drive most firewall vendors crazy.  Final Quality 
   Assurance Testing for firewalls is very complex and difficult 
   enough to do right (many don't do it right).  Adding a half 
   a dozen or two applications on the firewall only makes things 
   worse.  Will Application A introduce a potential security problem,
   impact the firewall's performance, cause a resource conflict,
   or a race condition?  What if Application A causes an exception?
   If so, how will it affect the firewall's security & performance?

o The increased complexity may double (or more) the Final QA Test
   time - delaying the software's release date.  This will probably
   go over like a lead balloon with the marketing folks who are
   really set on getting the product out the door yesterday.

o Who do you contact for support when something goes wrong?  Is
   it the firewall's fault, <Application A vendor> or <Application 
   B vendor>, hardware problems, interoperability problems, or any 
   combination thereof?  What will you do if a problem can't be 
   easily traced to a particular application and each vendor says 
   it is the other vendor's problem - not theirs?
   
o Going further, who is going to step up to the plate and make 
   everything work together (and stand behind it)?

Can the above-mentioned applications be integrated into the 
firewall?  Sure.  Would you want to?  Maybe, maybe not.
Not being a glutton for punishment, I would rather avoid
the issue and not try to be all things to all people.

Do one thing, do it well.  

Most companies have little knowledge about security and
have placed their trust in the vendors to do their job
right.  If the InfoSec vendors try to be all things to 
all people, they may compromise the security of their 
product (and the organizations who use their product).

Best Regards,


Frank


The opinions of the author of this mail may not necessarily be 
representative of the opinions of Fortifed Networks, Inc.

(c) Fortified Networks, Inc. - http://www.fortified.com/
Home of the Free Internet Firewall Evaluation Checklist
Expert (vendor-neutral) Computer and Network Security Solutions
Fixed Price Contracts - Expert Information Security Officers
Phone: (317) 573-0800     Fax: (317) 573-0817