Firewall Wizards mailing list archives

Re: Firewall administration


From: David Collier-Brown <davecb () canada sun com>
Date: Mon, 06 Oct 1997 12:44:36 -0400

Rik Farrow wrote:
Get rid of the bad design. 

        STRONGLY AGREE....
        My 9-to-5 is consulting on the Application Binary
Interface at Sun, mostly from the viewpoint of stability.
If you don't get rid of bad things, you've decided to go out
of business.  You just haven't set a date (:-))


As to smaller points:
I have a couple of problems with this.  For example, one vendor
supports almost 200 services--your form has gotten very unwieldy.

        Actually I was emphasizing designing it in terms
        of what I want to know: the exploits and exposures.
        There are really only about four broad categories,
        from  integrety to confidentiality to denial of service to
        ... whatever the other one was (:-))

        The eaxmple needs the ``carefull collection of dependancies''
        is spoke of.  I used mail->smtp->spam as a pretty obvious
        example.  A real example would be more complex, with
        a small bunch of buttons at the top, and a big section of
        red traffic-lights at the bottom.
        

And services like NFS, which has an authentication mechanism
so weak as to be almost useless (similar to CIFS) does not
belong in this list.  Having a warning would be akin to having
a sticker on the dashboard which reads:

"Warning: due to the bad design of the doorlocking mechanism,
passengers may fall out when turning corners."

        I disagree: this is exactly what I want: a big red
        button that says ``if you turn on cornering, people will fall 
        out on the road''.

        From the security officer's point of view, there are two
        enemies: the attacker and his own management.  It is
        very important that one can say ``you ordered me to throw Sam 
        out of the car'' when management complains about the
        effects of opening the hole they asked for last week.  It's
        even more important to be able to send them a form to sign
        which says ``Turning on cornering will result in the 
        inadvertant ejection of passengers. I authorize
        this as an officer of the company''.
 
Finally, what about the exploits yet to be created?  Minimalism
is critical in firewall configuration.  

        So you add one more rule, so that 
        (port NNN && portmapper) -->
                (denial-of-service, "some descriptive string")
        and this becomes part of the display.  You add the new rules,
        and a bunch of red lights come on on the display.  And 
        you go and decide what to do about them.

        HOWEVER:  This is clearly not minimal, and indeed therefor
        shouldn't be part of the implementation part of the firewall.  
        (Thanks, Rik!) 

        THEREFOR one should have a policy part that just feeds
        directives to the implementation, and optionally takes
        event-reports back to check against the policy.
 
Making it easy to do
the wrong thing, enable a service just because it's in the
menu or form, weakens your security.

        I'm empasizing the **opposite**.  Whenevevr you turn on
        something that is ``easy'', you get faced with the hard,
        physical fact that you've just done something risky.  

        If a form-based interface makes it easy to make mistakes,
        then make the mistake part of the form.  It verges on obvious
        (but only if you look at it from the point of view of an
        ergonomist or a security officer, not a developer).

        I've had to fight many times with programmers who made
        the easy part easy, and the hard part **more** difficult.
        Sometimes impossible.  Forcing the results into the
        equation is one of the ways I keep them under control.


--dave
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb () hobbes ss org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb



Current thread: