6 Tips to Clean Up Your Security Policy

Firewall and router security policies can be a challenge to maintain. It is not uncommon to have 300 rules within a small company’s security policy, and in some larger organizations this number can grow into the 10’s of thousands. And in many cases, these policies have been around for 5, 10 or more years without the company really understanding of what each rule within the security policy is trying to accomplish. (In many cases, information security analysts and firewall administrators have inherited these policies from their predecessors, or worse they have been hired to replace someone that has left the company.)

So, imagine if you added or removed a rule at the wrong location within this security policy? You might block a business application, or potentially allow a hacker into your organization to steal your data – crown jewels of your organization.

Here’s some common ways to try and help reduce the complexity of the security policy and also help these devices run more efficiently. The good news is that there are security policy management solutions that automate these tasks so you don’t have to do this manually.

1. Duplicate Objects

Security policies have evolved over time and when different people enter information into the rulebase, they may use different object names. The ability to have a common naming scheme and eliminate duplicate objects can really help simply your environment. While you are cleaning up your duplicate objects, you may want to have these objects organized with a specific naming scheme as described below.

In many cases, you should employ a naming scheme that will help identify what type of device and where these objects are on the network. There are many different strategies for this, and here is a simple scheme to get you thinking.

Device naming scheme – XXXXXXXXX-YYY-O-T-DC-VM
Where XXXXXXXXXXXX is the name of the device
YYY – is a code for production, test, dev
PRD = Production
DEV = Development
TST = Test

O – is a code for the operating system
W = Windows
L = Linux servers
A = AIX
S = Solaris
Etc.

T – is a code for the type of device
A = Application Server
D = Database servers
W = Windows Domain
S = Sharepoint
Etc.

DC – is a code for the data center location
01 = data center 1 in NY
02 = data center 2 in London
03 = data center 3 in Singapore
Etc.

VM – is a code for virtual machine or physical machine
VM = virtual machine
PH = Physical machine

So a device with the following name (XXXXXXXXX-YYY-O-T-DC-VM):
Ftpsrv-PRD-L-A-02-VM translates into a devide Ftpsrv in Production which is a Linux Operating System that is an Application Server located in the London Data Center on a Virtual Machine. There’s a lot you can gather from a name!

2. Redundant Rules

As policies can be very complex, you may want to scan your rulebase for redundant rules. Remember that most security devices will process rules in the order that they are defined within the security policy. If you have redundant rules, you are stealing processing power from the devices in addition to adding more complexity into the security policy.

3. Rules Without Comments

Another way to help you organize your security policy is to look for any rules that don’t have comments. In general, it’s like looking for a needle in the haystack to try and figure out why this particular rule was in there in the first place so make sure that your security policy is well documented (most products allow you to put comments in the individual rules). This is a great way to document your security policy so you can understand why something is in there in the first place. Please take advantage of these features so when you are trying to figure out the security logic, it will be a little easier.

I’m sure when you move to the next security job, you’ll appreciate that someone did this for you.

4. Tighten permissive rules

Permissive rules are rules that allow more devices or services than should be allowed. There is a concept in security call “Least Privileges”. Roughly defined, this means that you should only give as much privileges to the user so that they can do their job. If you have a security rule as follows:

Source = Joe’s laptop , Destination = Web Server, Service=any

Then you have given me the ability not only to access the web server using HTTP and HTTPS, but the ability to use any application. This could be SSH, FTP, Finger, etc. There are many potential services that I could try where there are extra security vulnerabilities that are definitely unwanted…Please remember to tighten your security policies to prevent unwanted actions:

Source = Joe’s laptop , Destination = Web Server, Service=HTTP,HTTPS

Another way to help organize your security policy is to look for any rules that don’t have comments.

5. Unused Rules

You already know that security policies have evolved over time, so it’s no surprise that there may be rules that are unused. This is similar to asking when is the last time you cleaned up your hard drive? Only when you have too…

For unused rules, there are tools available to help you identify when the last time a security policy rule was used. In order to use these tools you may need to turn some additional logging or hit counters on the security policy, but it’s well worth the time and effort. Why? Because you then get information about which rules are used and which ones can be decommissioned. In many cases, you want to get a good sampling of information and gather this data for a period of time. For example, if you have an application that only runs monthly or once a quarter, you don’t want to delete the rules for this application because you haven’t seen any activity in one month. However, in many cases if you haven’t see any activity for a longer period of time, it’s a good bet you can disable this rule.

Many customers would stage unused rules as follows:

• No activity over 3-4 months, disable rule and notify stakeholder to see if they still need this rule (some people call this rule recertification
• No activity over 6 months, permanently delete the rule

6. Policy Optimization

Remember when I suggested to add some extra auditing or hit counters to the rules above? Now you can really take advantage of some of this data that is being collected.

When these counters are turned on, you can see what rules are the most active rules. By analyzing the most active rules and looking at the security policy logic, you can optimize your rulebase by moving up certain rules that are being hit more often. In some cases you may be able to get 10-25% more processing out of your firewall devices. I’m sure your company would appreciate the new found benefits. However, be careful to understand the security logic when you make these changes. You don’t want to move up a security rule and change the logic which opens up a service to an unwanted guest.

Like everything in life, there is a certain amount of work that needs to be done to make this work, but if you focus on some of the key points, then you will gain significant benefits. Happy policy cleanup and tuning…