Re: How to keep firewall rules clean and up-to-date

On 2011-04-26 13:12, Ilias - wrote:
> Hello,
>
> What do you do to keep your firewall rules clean and up-to-date?
> Procedures, for which?
>
> Keep in mind;
>
> -Servers that change from IP
> -Server which has been discarded
> etc.
>
You forgot to mention the "we need this service NOW, and we don't care 
how you fsck up the network architecture to deliver it", a.k.a. 
"temporary solution" case.

An important factor to consider is that changing firewall rules is the 
simplest part of the game. You need a fix to delivered here, and a 
reconfiguration there to be able to actually close that hole in the 
firewall, all Someone Else's Responsibility.

This means we are basically talking about enterprise level procedures, 
not just procedures for firewall operations.

A working life cycle management procedure which actually care about 
discontinuing services and their supporting RFS-es would be very nice. 
It means you have to have a service map for your IT detailed enough to 
support identifying configuration items related to services in the 
firewall. And motivation to actually drive the discontinuation 
procedures. If someone have actually seen such a procedure working, I am 
eager to learn the key points, as right now I think it is mission 
impossible, save some small, well-defined environments.

Another solution - which I believe works better - is to drive the whole 
thing from the exception management perspective. From the ITIL 
viewpoint, it is basically problem and change management. You identify 
the problem (a clutter in the firewall config), devise actions (the last 
of them being removing that configuration from the firewall), and let it 
run according the usual procedures. Ehhm... I have found vanilla ITIL 
(as enforced by vanilla process support systems claiming to support 
ITIL) does not work well, and work horribly for security problems, where 
no one but security people are motivated to actually deliver a solution, 
and they are the ones who cannot. So you need to add well thought out 
escalation paths for both the problem and change management phase, and 
add a "we report the statistics time to time" procedure used to escalate 
the cases like when someone have 3 critical risk problems and fails to 
even state when they will be solved, or have 50 changes overdue since 
three months. And you should define dead-end as well, when someone from 
high says "OK, I see the problem and take responsibility for not solving 
it".
You can make the input to the process from audits, statistics (gee, this 
service haven't seen a bit of traffic since three months), etc.
We are doing such a procedure for all IT security problems and system 
interdependencies. It does not save you the fights, but at least gives a 
structure to do it, and raises the risk management decisions to the 
appropriate level.

For this to work, you still need some basic information about the 
clutter you have in your firewalls, like who/what asked for/depends on 
the service. If you don't have this, a good way to have a "clean paper" 
is to say that services should be reregistered, and unregistered ones 
will be shut down at date X. You have to announce it loudly, frequently, 
in an understandable manner, and give very long time for it, so that 
when you actually turn out some vitally important service of the 
enterprise, you should be able to say "I have warned everyone 
continuously since months", and the CIO would fire someone else than 
you. So you start it by devising a plan including communication and 
checks for still unregistered services with traffic, and go to the CIO 
with it.

_______________________________________________
firewall-wizards mailing list
[email protected]
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards