Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Security Manager's Journal: Time to tweak the security policies

Mathias Thurman | Nov. 19, 2013
Sometimes a tweak isn't enough though. That is when you have to create a new policy.

Every fall, I conduct a policy review. I think it's a good idea to have this on my calendar, because no policy, no matter how well crafted, is meant to last for all time. New standards arise and old ones are modified, making some policies deficient. Or a security incident, an audit or some business reality that was previously unacknowledged emerges to demonstrate how a policy falls short.

Trouble Ticket
At issue: It's time for the annual review of security policies.

Action plan: Make any modifications necessitated by changes in technology, business needs and outside threats.

I wouldn't make much progress with this exercise if every policy tweak had to be approved by our policy board (comprising human resources, legal counsel and the CIO). It's just too hard to get all of them in the same room at the same time. When I first came to this company, I needed the policy board to approve my initial policies. I had to bait a conference room with pizza to get everyone together. So we made a deal. I can make incremental modifications without the board's input. I make needed changes, forward the new wording to the board and then wait for their reactions. Usually, I don't hear a peep.

I'm working on several modifications this fall. First up is passwords. We have a fairly high-profile policy for user passwords that covers things like complexity and change frequency. But we have several other password policies that were little noticed because they were buried in other IT documents. I've pulled them out, rewritten them with an eye toward consistency and consolidated them all in a single policy.

Next, I needed to address policies that relate to our expansive embrace of cloud computing. Good-sized chunks of our infrastructure and applications are now hosted, and the prevailing thought is that once they were removed from our premises, they became immune to our DMZ policy. But the infrastructure and applications still face the public and serve our customers. With that thought guiding me, I modified the DMZ policy to make it clear that any resource sitting between the public Internet and our trusted production network must be protected by a firewall and other network security devices, regardless of where that resource physically lives.

Speaking of firewalls, I recently conducted a cursory audit of our firewall rules using a tool called FireMon, uncovering several that aren't utilized. I'm all for security and even more, redundant, security, but security measures that serve no real purpose don't help. So I asked our firewall admin why he didn't remove the unused firewall rules. His answer: We have no policy allowing him to do so. I can help with that! I modified the firewall policy so that the admin must disable any rule that hasn't been triggered in 30 days and then delete the rule after 90 days.

 

1  2  Next Page 

Sign up for CIO Asia eNewsletters.