Security Manager's Journal: Time to tweak the security policies
- 18 November, 2013 16:03
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.
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.
Acceptable Use Rules
The king of all our policies is on acceptable use, since it must be attested to by every employee each year. Like any policy, it's not perfect, so it was due for some tweaks as well. For example, since that policy was last modified, employees have begun using remote-access software to tap into the PC they left at work from their homes, or anywhere else. I have now explicitly restricted the use of such software, which already violated our remote-access requirements for encryption and two-factor authentication.
Of course, sometimes a tweak isn't enough. I did have to create a new policy. This need arose from a recent acquisition, in which we assumed some 30 dedicated point-to-point VPN connections. We've never allowed such things, but they seemed the best way to allow newly acquired offshore workers to access code bases and other R&D sections on our internal network. The acquired company also had no policy, standards or guidelines for such connections, so I created what I called a "partner connectivity policy," specifying rules for them. With an entirely new policy in hand, I guess I'd better order pizza.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.