Creative Policy Control with Provider-1

Ruling Your Network With An Iron Fist

If you are familiar with security policy management for network level enforcement, most of this blog should make total sense, even if you are not that familiar with Provider-1. If you don't already know what Provider-1 is, and are not involved in policy creation and management, you might want to check out some other articles here that are not so much about specific technologies. I don't always talk shop, but sometimes I just can't help myself.

I would like to address the creative side of network security policy management. Right about now you are wondering if I really just said creative, and you are correct. Let's get creative here, in planning our policy. P-1 offers a powerful tool in the ability to manage global policies, that create hierarchies of security zones, but just because it can do this, doesn't mean people always make the most of it. This is the creative part. You can manage policy in a hundred different ways, none of them wrong, so what is the best way to do it?

Unfortunately I don't have that answer for you, I'm afraid you are going to have to figure that out for your own infrastructure. There isn't one way to manage policy that is better than any other, unless you consider how it applies to the infrastructure you are managing, so take this all with a grain of salt, but I would like to present for you three simple global policy options available to you to consider in your policy design process. But before I do, we need to think about your overall policy strategy, and how it's managed.

A Word About Network Security Policies

I am not going to tell you how to create your security policies, if you have a process that works for you, move on to the next section as that process is just as valid with global policy management as it is with your overall policy management. If you could use a cleanup with your policy organization today, then global policy management isn't really going to buy you much.

Here is how I like to run my policies. Groups. Every rule is a grouping, and that means breaking your infrastructure down into manageable groups. One organization I know does it with colours, and it works very well. Red zone, blue zone, yellow zone classes of servers, networks and services. Their policy change management is such that you request addition to the red, yellow and blue groups, not the addition of a rule. As a matter of fact, once you have a policy defined and in place, it should be a BIG deal to add a rule. If that happens, it means you missed something. Having that process to classify your assets, and the associated access/limits based on those classifications is the key to turning your creative side into a working business process.

Tips for Building Global Policies

1. Global Policies

It would not make sense to start with anything, except the most basic application of global policies. The idea is you create a high level policy, that is not pushed onto a security gateway, but merged into another policy management device, the customer, or what we commonly say in the P1 world, the CMA (Customer Management Addon). The changes at the global level can enforce rules either before, or after the policy the customer creates, giving you the option to create rules that are required (before) or a suggestion (after). In the example below, the policy on the top is being created with an access rule for gateways, and a block all rule for the bottom. This top level policy pushes the rules and objects created at a global level, into the CMA(s) policy management (of your choice).
The CMA could represent hundereds of other security management stations, allowing you to build global rules once, that are enforced hunderds of times. Need to change a global rule? No need to log into all your management stations, you just change it once at the global level, and let it propagate down to the CMA, like the policy shown below.
The rules highlighted by the arrows cannot be changed here, they come from the global policy. The administrator of this system is free to create rules as needed, as long as they do not conflict with the global policy as mandated by the P1.

Think of how this could be used very effectively to enforce corporate policy. For example, DNS is a protocol that we all need to have, but it can also be the most abused service when it comes to exploits (ask Dan Kaminsky if you don't believe me). Lets say you want your entire infrastructure to only use your corporately controlled and approved DNS servers, and block everything else. With a global rule allowing DNS to my servers, and blocking all other DNS traffic, every management system can be designated to enforce these rules, bend to my will and heed my warnings on DNS risks. Ok, I'm getting a little dramatic here, but when you play with a P-1, you do risk developing a god complex. This truly is the power of a security policy dictatorship, so try to make it a benevolent dictatorship :)

2. Global Dynamic Groups

Remember how I liked to push everything in groups? Well I am not naive enough to believe that approach works all the time. You will always have those custom rules to deal with, so why not leave them at the local policy level? Take the work of defining the grouping of common servers and services to the global level, but leave the ability to manage server type access on the local policy. How do you do this?

At the Global SmartDashboard level, create dynamic objects that represent the various servers, like web servers, your administration workstations, etc.

These will appear as groups in the local dashboard. When attached to a global policy, it means the local administrator can add or remove objects from the global policy groups, but not actually change an existing rule. New web server online? Add it to the group. Change in admin console location? Change the admin console objects in the group. New DB server online for expansion? Let me get that added to this group here. That's it. It's logical and leaves your local policy open for those customizations that always seem to happen, no matter how many groups you create ;)

3. Gateway Oriented Functions

Depending on your architecture, you may want to leverage something that is gateway oriented, even if it is only for a subset of the firewalls you are managing (you can have multiple global policies in Provider-1, feel free to use all 3 options presented here). Let us say you are working from a site perspective, and have many locations, all with similar needs and requirements. Allowing for local configuration, how would you leverage a global policy across different CMAs, on a gateway function perspective?

Start in the Global SmartDashboard, creating dynamic objects by the classification of firewall type you are managing.

Then build your rules according to the gateway type, using the 'install on' field in the Global SmartDashboard to designate which firewall type will receive the rule.

This global policy can be inherited across multiple different sites,

when the local admin, in the CMA SmartDashboard, adds the appropriate gateways to the appropriate groups (sent down through the global policy).

Hope this helped give some perspective on these three quick tips for leveraging global policies in Provider-1. It breaks my heart to see a Provider-1 deployed without a solid global policy, and with the right policy design, this virtualization of management can take your policy control to a whole new level, literally.

And remember, try to make it a benevolent dictatorship.