Corporate Policies, Symantec Firewall, and deploying standard policies

One of the corporate policies that was sent down from up high during the last audit was desktop firewalls. We originally had it set so when on the corporate network, the Windows firewall was off, when off the network, it was on. We then tweaked that, and set it to optional when off the network (with default being on), and off when on the network. Corporate security didn’t like that, and said we needed to enable it both off and on the network, and that they also recommended a second firewall. Their recommended product hadn’t been released or updated in 3 years as it had been incorporated into “Symantec Client Security”. This isn’t bad, we just got an add-on for our Symantec Anti-Virus to have the firewall included.

Symantec’s recommended method of deploying the firewall service is to start off with a clean desktop. Install all the usual utilities that you will be requiring as part of every day operations for the company, run the firewall, and applications, permitting what is required. When a suitable time has passed, a day or two, take the firewall administrator, and export the firewall policy. This can then be used as a template to push to the remote computers. This is pretty easy, and is documented fairly well here. Documented pretty well, right up until it comes to deploying it. It appears to stop right at the exporting part, which makes figuring out deployment fairly difficult. I figured you could just deploy it by right clicking on a guest in the SSC, and telling it to deploy a policy, but there is no options for it there. So I started looking around, and came across this pdf. About half way down after documenting the methods of deploying the client, it mentions that the policies can be updated by right clicking on the “Groups” section, rather than the computer. Well, I didn’t have any groups, at least not yet, so I created one, and sure enough, there was the “deploy policy” option.

I began to wonder if I’d have to force all the computers into a single group to deploy this, but then I thought better of it. I right clicked the server, and the same option was there too. So in theory, I could deploy to the whole server group without any issue. Well, that’s where the better half of my brain kicked in, and reminded me of the users, application base, and possible impacts. I have created a handful of groups that we can use for the deployment of the new policies. Why multiple groups? Well, imagine if you deployed your shiney new policy to 150 people all at once, and something was wrong, and you killed access to the internet. Would you want to be on the phone with that hickup? I didn’t think so. What I’ve gone with is a roll based group setup. Each department has their own group, and each computer will be moved to the associated group. This will allow me to build policies that meet the needs for each department, without having to worry about crashing the entire network.