Re: Firewall administration and thoughts cont.

[Anton J Aylward <anton () toronto com>]

At 08:40 AM 04/10/97 -0400, Mark Teicher wrote in reply to Rik Farrow:
## Reply Start ##

> One issue is: Software and/or Hardware license agreements.  This issue
> tends to conerns me since sometimes software/hardware companies imply
> certain warranties or certain liabilities depending on what the software
> and/or hardware actually can provide in design, function, or action but
> never fully documents these type of items until something an incident
occurs. 

Mark goes on to discuss implied warranty (i.e. suitable for the purpose 
for which it was sold).

This is getting to the meat of the issue.
I've been in establishments where the (unstated) policy is to allow
anyone to have Web access (and hence FTP access) thought the firewall,
unrestricted.   I've also been in establishments where Web access is
permitted but FTP is expressly (by stated policy which IGNORES the web)
forbidden unless specifically authorized.

Now tell me, oh Gods of the Gui, which should be the default
setting shipped with the firewall?

I don't believed ANY answer can be correct.  Becuase of that 
implied warranty.   The firewall IS suitable for the purpose 
for which it was sold.   The issue is managing expectation.
If you'll pardon the alliteration, its one of managing management's
expectation.   Becuase the firewall can be configured to do _ANY_
DAMN THING YOU WANT!!!!

If the vendor ships it to block everything one of two
things can happen:
        a) you can use it as its shipped, in which case you
        can't do anything, so if you complain its your fault
           for not configuring it.
        b) you can configure it, and so become liable for any
           attacks which penetrate the firewall.

You can figure the decision path for if its shipped wide open yourself.

Now it may be an urban myth, but I recall hearing about a case
where a woman sued a microwave manufacturer because there was not an
explicit warning about drying her poodle in the oven after its shampoo.
OK, o it is an urban myth, but there are any number of equally crazy
court cases.

The whole point of a firewall is that it can be configured.
Further, what's perfectly safe for you may be a major security 
hole for me.   So the idea of shipping with a 'safe' default
is not, IMNSHO, not attainable.

Unless you follow MJR's perfect firewall.  ;-)

The GUI is there to pay homage to the myth that GUIs are "user friendly'.
They may be 'friendly' from the point of view of the marketeer WRT
uninformed management.   They are not friendly to me.   They are not
friendly to some technically aware managers I do deal with ("why won't it
let me see.....?")   In particular they hide important information.

I've recently battled with a firewall which has no alternative to the
GUI.   For some reason, the person at the international consulting
firm who set it up (firm and firewall remain unnamed since I wish to
avoid being the subject of a legal case, but those experienced can
probably figure out the firewall) decided that supplying the IT 
department with specs and documentation would compromise the security 
of the firewall. (YES!  Security By Obscurity from one of the Big N+1).

In his infinite wisdom (and I use that phrase with sarcasm), this 
consultant decided not to use a mail hub to dispatch mail to the 
various division and subdomains, but to construct a huge alias table
on the firewall.  And yes, the vendor's documentation can be construed 
as recommending this!  It takes a bit of imagination, but you can find 
an entry in the GUI which will permit you to do this.

But you cannot edit that alias file directly.  So when a division
gets split or renamed, or - as happened in this case, the division
became a new company with its own top level domain, you have to do 
a step and repeat via the GUI.  No "1,$s/name1/name2/".  

Tell me which you think will be more error prone?
Tell me which you think will be more difficult to verify?

Its not that I hate GUIs, it that I hate inappropriate GUIs.

I think I've already mentioned Tom Duff's view of this:

        When the computer knows more about what's going on, use a MENU.
        When the user knows more about what's going on use a COMMAND LINE.

This is 'firewall-wizards'.   Not 'firewall-for-idiots' (although there is
probably a book of that title by now).  If the menu can offer me a "do 90%
of the work for policy #27 out of the selection" them give me a command line
to do the extra bits, fine, I'll take the GUI.   I see this approach in the
AUDIT tools from companies like AXENT (which I strongly recommend!!)
I hope to see it in firewall configurators.   

But right now, I think the issue is dominated by that legal clause.
If you can configure it to do anything, the vendor is not going to
be liable.

Whihc raises the question, if you don't have a security officer, if
you don't have security policies signed off by management, who is
liable?

This is the question that the GUI issue inheritably leads to, 'cos that's
where the money is!

/anton - who wonders if he's still coherent this late at night

## Reply End ##