Advice on an organized ruleset

[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?

[RayPesek]

What business are you in, and if you're in the US, are you a public company? Regulatory constraints can tell you just how particular you have to be.

Scan the rulebase and eliminate as many uses of "any" in the source, destination and service cells that you can, and forbid people from using it. It's one of the biggest places to make a serious mistake.

Rules *should* be organized by usage, with higher usage rules at the top to assure maximum performance. I actually have methods other than this one, though.

Group rules by source when a source has access to a lot of destinations. That way you can tell who is going to what.

Group rules by destination when a destination has a lot of sources. That way you can tell what is getting hit a lot.

Group all DMZ rules for a particular DMZ together.

Group all "source Internet" rules together.

Use section titles to define what each grouping is for and it makes it a lot easier to keep track of them.

>> Are we being too granular by worrying about Client A accessing Server B when they might not have any actual need to do so?

No, you are not. Default deny is always the best approach and you never know who is going to turn malicious.

250 is a lot of rules for only 150 servers. Try moving them around to group like sources or like destinations together and then look at them that way. You'll undoubtedly find there are a lot that you can combine. When you do combine them, disable the old ones but leave them in place for a couple of weeks just in case.

HTH,

Ray