[fdamstra]

I'm looking for some general advice. I came into a company with a rather large rulebase, and in the last few years, our network and rulebase have simply exploded.

When I started, we had one HQ with WAN connections to about 50 sites. Now, we have a half dozen corporate partners, and WAN connections to about 150 sites. We had about 30 servers when I started, and we've got about 150 servers now. Such growth is wonderful from a job security and budget perspective, but our firewall policies have grown tremendously. The bean counters are giddy.

However, 3 years ago, with 50 sites and 30 servers, it was easy to establish rules for "Clients A-K have access to server A on these ports," and clients "D-M have access to servers B-C on these ports", and "Internet clients have access to servers B-D on these ports." But now, it seems our rulebase is out of control.

It's not difficult to scan through the rulebase and see redundant rules that could be combined. But it's also pretty easy to see how a simple mistake in combining rules could cut off access to a lot of people who need it (and might complain loudly to the CEO).

So question 1: How do you go through the process of consolidating your rulebase? Are we being too granular by worrying about Client A accessing Server B when they might not have any actual need to do so? What do you do when you see a rule that is "wrong" (especially, say, a NAT rule) but isn't actually causing a problem? Fixing the "wrong" rule may actually break something that was previously working, so how do you handle the situation?

Of greater concern, however, is that having a big rulebase might mean we're granting access to things we want secured. If I have rule 112 that specifically grants access to clients A-D to a server via port 666, then an errant administrator wants to grant client F to just about any server (except ours, maybe) on the same port, he might grant access from Client F to Any on port 666. A drop all rule at the end wouldn't help.

So, question 2: How do you mitigate against administrator mistakes? I'm pretty sure they are commonplace?

If I've held your attention this long (and I think that's a longshot), I think it all comes down to question 3:
Assuming you operate by the principal of least privilege, how do you organize a large ruleset?

I see a number of obvious options:
A) You organize by purpose.

Clients need access to certain resources, so you allow them.
Users need access to certain resources, so you allow them.
One big drop rule at the end.
Your drop rule is too noisy, so you add a "silent" drop rule just before the end.

This describes what we're currently employing. It seems like a reasonable way to organize rules in a SOHO environment, but doesn't seem to scale.

B) You organize by source, followed by a drop rule.

Group A needs access to Server B, so you allow it.
Group A needs access to Server D, so you allow it.
Drop all other connections from Group A.

This seems like it would grant a nice degree of organization, but eventually Group A and Group D both need access to server X, so you've got extra rules that are spread apart. This isn't necessarily a bad thing, but the rule base ends up being even bigger.

C) You organize by destination, followed by a drop rule.

Server B needs to be accessed by Clients A-X, so you allow it.
Drop all other connections to Server B.

This initially seems like a nice way to organize, but it breaks down when you need to allow a group of people (say, the client support team) to access a lot of servers (as does B, now that I think about it).

D) You organize with a hybrid.

(no examples this time)

You could organize based on source, then based on destination (or vice versa), but then you can't add drop rules to the end of either. This is pretty much the same as option A. It doesn't scale.

So we're left with:
E) Find somebody who can keep the whole ruleset in their head and see the implications of any change.

I think of myself as a pretty smart person, but I'm not able to track 250+ rules and their implications in my head. And I know our ruleset pretty well.

... or ...

F) Reduce the size of the ruleset.

This means grouping more objects together, even if it means granting unnecessary access to some systems. Maybe we can't control every access to a machine, and that we're opening up access through the security onion. I hate this because it means bypassing a line of defense, and trusting that the host system's authentication is strong enough to prevent unapproved access.

...

Sorry, I know this is a long post, but it boils down to a few basic questions: How do you keep your rulebase manageable while keeping security high? How do you transition from a "small business" to something larger without sacrificing security?