First things, first.

It sounds easy: firewall policy cleanup. How hard can that be? Well, if you have FireMon, pretty simple as it turns out. But how did we get ourselves in this predicament in the first place? What is the root cause of unused or unnecessary firewall rules? To find out, maybe we need to back up and take a closer look at how a rule is created.

Not too long ago, I can recall several conversations in which “change control process” was a foreign phrase to most security administrators. Initially, it was quite a shock for me to sit down with a prospective customer, who literally had no definable procedure for making or “verifying” rule requests outside of an email trail, and (maybe) a spreadsheet. Over time, I began to realize it was just “how things were” but it showed me just how integral FireMon could be to a security organization. As time went on, it became more common to see firewall change-windows implemented, homegrown applications supplant spreadsheets (with varying degrees of success), and basic approval processes begin to emerge. All of which is fine and good, but it misses the most elemental piece of the puzzle in rule creation: creating the rule correctly and effectively in the first place!

Back in 2001, when we launched FireMon into the security space, we knew were onto something very special given the pervasive problem of tracking changes made to the firewall. Overtime, we augmented our capabilities to a point in 2003, when we created a very simple method of testing a policy for expected behavior with a feature we named simply, Policy Test. Despite our lack of whiz-bang-sexy marketing names, this feature proved to be a huge hit with our customer base. One of our largest telecommunications customers used the feature to help thwart SQL Slammer (remember that little slice of fun?). How? Well, using FireMon’s Policy Test a user simply provides FireMon three key pieces of testing criteria: SOURCE, DESTINATION and SERVICE. Submitting this information to FireMon and applying the “test” across the entire environment or focusing on a single firewall, instantly answered the question of, “Am I passing SQL into my network?” Soon our customers were using the tool to uncover all kinds of information hidden inside of their complex policies without pouring over audit logs or wasting time trying to decipher hundreds of rules. You can probably guess where this is going…though more accurately, it isn’t “where” but rather, “when”. That’s right: rule creation. Instead of blindly dropping a rule in at the bottom of a policy or duplicating rules our customers were able to confidently insert rules when, and where needed. Overtime, these 2 activities of making sense of a policy and rule creation comprised the vast majority of the feature’s use and we felt good to have pioneered another piece of the security management puzzle.

What’s next? Internally, that’s a question I hear around the office a lot, and this case was no different. Several customers had asked us to integrate with their workflow solutions, (Remedy, Service Desk, etc.), while others (who had no established workflow solution), asked us to create one. Our response was simply to do both.

So, we created Policy Planner. It offers a simple, web-based front end (so that anyone, anywhere, can create a ticket regardless of technical expertise), and tracks the ticket from request to closure. Roles are defined which serve as checks and balances throughout the process, tickets may be assigned to appropriate administrators, and as mentioned, Policy Planner can integrate with third party service desk solutions serving as either a standalone solution or augmenting an existing, and often larger one.

One of our most well received features in recent memory is the ability Policy Planner has to make recommendations about rule requests. Think of it as having every single administrator who has ever made a firewall rule modification/add/delete at your fingertips when you sit down to create a rule. Using an advanced form of our Policy Test capabilities behind the scenes, Policy Planner can bring unprecedented value in the rule creation process by offering one of 3 pieces of matter of fact advice: “No Change Necessary” – it will tell you if the rule already exists; “Similar Access Exists” – all that is required is a modification to an existing rule; and “Rule Placement” – the rule is needed – no similar rules exist, and it should be placed above rule “X” to avoid hiding or shadowing a rule below it.

The power of the solution is obvious particularly in response to the question at hand which is, “How do I keep my policy free of redundant or unnecessary rules in the first place?” Of course, Policy Planner integrates seamlessly with FireMon closing the loop on rule management.

So what’s next? Quite a bit actually. 2010 promises several enhancements to both products (FireMon and Policy Planner) including the information they share, so you’ll have to stay tuned. Better yet, come see us at RSA 2010 (March) or InfoSecurity Europe 2010 in London in April.