Re: Firewalls - Ease of Use and Maintenance?

[-Hammer- <bhmccie () gmail com>]

The other high cost of "free" that people sometimes overlook is 
liability. Many organizations want/need someone to hold the fire to in 
the event of an issue. I believe in open source and am an advocate of 
open source computing (this email is from my Debian (NOT UBUNTU) laptop 
and my BSD workstation is right beside it), but at an organizational 
level, if I had an open source FW and a vulnerability was allowed to get 
thru it and compromise customer or confidential data, my management 
would be looking to the vendor for answers. If I told them "it's open 
source, there is no "vendor"" it would not go over well. Why? Because 
the liability is now assumed by my company. So when the customer sues 
it's on me. Or (and we see these on a regular basis) when the patent 
troll contacts us about his patent that the open source product is 
violating and wants compensation the liability stops at my company. IF I 
am using a vendor supported platform, I can take that to my vendor and 
discuss options. Many (not all) large businesses have agreements with 
vendors that go well beyond NDAs. Agreements about liability. 
Healthcare/Financial/Defense all have these kinds of agreements. I'm not 
saying it's fair. It's just how the world works. For that reason there 
are some areas where open source is smart while there are other areas (a 
firewall you depend on to protect you) where open source may put you and 
your employer at risk. You have to consider that. Or... Some of us do.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/10/2011 07:36 AM, Jimmy Hess wrote:
> On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard<nick () foobar org>  wrote:
>    
> > On 09/11/2011 19:07, C. Jon Larsen wrote:
> > As I said, it's not a pf problem.  Commercial firewalls will do all this
> > sort of thing off the shelf.  It's a pain to have to write scripts to do  this manually.
> >      
> Ah... the high cost of  'free' products,  you have to do some
> scripting, or pay another organization to support it / do scripting
> work for you.  The advantage is... you _can_ do a small amount of
> scripting or programming to add minor additional required
> functionality.   And a very large number commercial firewalls do not
> have config synchronization, except,  perhaps between a failover pair,
> anyways.
>
> Anyways...   I can see synchronizing blacklists on a firewall,   or
> having a firewall configured to fetch certain 'drop' rules from a
> HTTPS URL.        Otherwise:  the thought of  mass synchronization of
> lots of firewalls can be bad in that it creates a single point of
> system compromise;  supposing  the synchronization source  machine
> were compromised,  one dirty rule inserted by an intruder followed by
> a kick off of the sync mechanism,  and then actions to break
> it/prevent further syncing, defeats the security of the entire
> deployment....
>
> --
> -JH
>
>