Re: Firewall Audit Programme/checklist

[Chad Schieken <cschieke () advsys com>]

Agreed, a detailed checklist, broken down in true/false  (yes/no) type 
questions and answers would be almost impossible to build (completely) and out
of date the second you typed it into your text editor.

However a specialized framework to tackle this problem seems inorder. This would
allow the analysis to be done by the competent individual, but the investigation
to be accomplish be a jr. or less knowledgable individual. 

further it would help even the most knowledgeable guru stay on-track and not
miss details or leave portions out. 

It could be validated based firewall/gateway type and product sets. And 
slightly or not so slightly modified for differnent types of configuration, 
levels of protection, and archcitectures.

Now the interesting part, authoring such a framework, would take some time, need
constant updating, and almost always need improvement. but that oould be better
than nothing. 



> > Has anyone found or got an Audit Program for firewalls? or an audit
> > checklist for firewalls?
>
> I do a lot of training for a "big six" firm and an audit checklist
> is a fairly common request. I haven't ever given one to anyone,
> because I don't have one. If you know what you're doing when you
> audit a firewall, you don't need a checklist. If you don't know
> what you're doing, you do -- but then you shouldn't be taking
> someone's money to audit their firewall.
>
> There's one book out called "Practical IT Security Auditing" or
> "Systems IT Auditing" by Barton Neal. It includes checklists that
> are semi useful, BUT the problem, once again, is that it doesn't
> include what the checklists *MEAN* which is the information that
> the auditor really needs. Also, like many audit checklists, it
> is too hidebound and regulated. The firewall auditing section, for
> example, appears to assume that you're auditing a firewall toolkit
> based firewall (!)
>
> i.e.:
> -----
> ...Ensure that the application gateway firewalls' host operating
> system (usually UNIX) has been properly modified to disable services
> that could be used to subvert the security of the firewall software
> program:
>       1) Review the /etc/inetd.conf file and the /etc/rc start-up
>       files to ensure that all standard network services have been
>       disabled by commenting out (#) their entries
> ...
>
> Now, obviously, that's not going to make a lot of sense on a
> Checkpoint, or a Firewall/Plus, etc. Someone who was using this
> checklist would either look stupid or would have to know enough
> about what they're doing to not need it in the first place. :)
>
> It's a tough problem, because there's a methodology but it's really
> pure systems analysis. You need to start at zero and build facts
> about the firewall, then understand the significance of those facts
> in the installed context. It takes a lot of expertise -- more than
> can be comfortably fit in a book or taught. Even if you did fit it
> on a checklist or in a book by the time you had it written down
> the rules would have changed. :(
>
> The big problem is that IT audit comes from a mainframe background.
> Mainframes are *simple* to audit. You just have to make sure
> that RACF is configured right and that the SNADS are connected
> to the DASD by a JCL or whatever. Out on the Internet, the products
> mutate overnight, there are dedicated single process systems
> that break a lot of rules, and there are lots of applications
> that are basically undocumented. :( What you really want isn't a
> checklist, it's a flow-chart. A really BIG flow-chart that goes
> kind of like:
>
> if you're looking at a firewall
>       look at the policy for incoming traffic
>               does it allow http in?
>                       to what machine?
>                               what OS is it running?
>                               are the CGI scripts audited?
>                               is the httpd up to date?
>               does it allow smtp in?
>                       to what machine?
>                               what OS is it running?
>                                       if UNIX
>                                               is sendmail up to date?
>                                       else
>                                               WTF?
>               does it allow other services in?
>                       what service?
>                               WTF?
>
> The problem is that the *INTERESTING* stuff is the "WTF" entries
> and those are also the danger points. :(
>
> I'm not trying to attack you for answering a simple and straightforward
> question. But, I beg you, if you find a checklist, please don't think
> it's something you can apply in a simple and straightforward manner.
>
> mjr.
> --
> Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
> work - http://www.nfr.net
> home - http://www.clark.net/pub/mjr