Great Circle Associates Firewalls
(February 1998)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: References for writing Security Policies (was Re: Certifiying Security Auditors)
From: Bennett Todd <bet @ rahul . net>
Date: Mon, 16 Feb 1998 13:11:53 -0800
To: Paul McNabb <mcnabb @ argus-systems . com>
Cc: proberts @ clark . net, firewalls @ GreatCircle . COM
In-reply-to: <199802162031 . OAA00067 @ mail . argus-systems . com>; from Paul McNabb on Mon, Feb 16, 1998 at 02:31:54PM -0600
References: <199802162031 . OAA00067 @ mail . argus-systems . com>

1998-02-16-20:31:54 Paul McNabb:
> I'm sorry to bring this up yet again, but I've lost the references
> to how to write a security policy.  I've seen several decent papers
> over the last several years, but I can't seem to locate them now.

I _like_ this topic! I think it's near and dear to the heart of security
administration, and easily the most important part of the job in
selecting and configuring a firewall.

Unfortunately, I can't contribute much in the line of references; my
favourite remains Bellovin and Cheswick's ``Firewalls and Internet
Security''; they give the big picture real clarity.

What I always try and do is start with a ``boilerplate'' policy, a
``one-size-fits-all'' that's close to what the organization needs,
erring a little on the strict side, then tune it to fit with detailed
arguments about the specific needs of the users.

So for instance for anything except a wide-open ISP, I tend to start
with a simple stance:

	permit bi-directional email, with aggressive spam blocking,
		proxied at the bastion host; include full logging and
		the option of capturing all traffic as it goes by

	permit outbound-only http, with applet stripping and MIME type
		checking, via proxy, with full logging of every request
		made

	prohibit everything else unless a specific business case is made
		for it

That tends to be close enough to be a good starting point for debate
over configuration details.

For an ISP, or someone filling an analogous role --- no commitment to
protect users from their own folly, selling the service of full and
un-hindered connectivity --- the stance would be simpler. Do
bidirectional spam-blocking, which means force all email through a
proxy, just because if you don't you're a bad net citizen. Use a
configuration that allows your border router to be configured to
strictly prohibit outsiders from forging IP addresses found within your
net, and insiders from forging IP addresses of the outside. Aside from
that, secure your own machines like bastion hosts (or put them behind
your own firewall) and run the best intrusion-detection software you can
lay your hands on, to help you alert your users when they are burgled.

-Bennett


Follow-Ups:
References:
Indexed By Date Previous: RE: Security Auditor versus Security Auditor was Re: Certifying Security Auditors
From: Mark Teicher <mht @ clark . net>
Next: Re: SQL*Net and TIS fwtk -Reply
From: "Samuel T. Baker" <sbaker @ mail . state . tn . us>
Indexed By Thread Previous: Re: Certifiying Security Auditors
From: mcnabb @ argus-systems . com (Paul McNabb)
Next: Re: References for writing Security Policies (was Re: Certifiying Security Auditors)
From: "Hr. Kay Wondollek" <kay @ mchu . siemens . de>

Google
 
Search Internet Search www.greatcircle.com