Setting IT Security Policy

Clear definitions of who is responsible for resources and who has the authority to sign off on changes to access privileges and user rights is important in any size organization. We also must know what level of auditing and logging is desired, as well as what may be required legally or contractually. For large systems with many users, simply managing the volume of security data logged can be a daunting task if you do not have a sound system in place for doing so.

Having a clear understanding of the organization's security needs and goals, along with a clear policy, helps IT implement and enforce that policy. Checks and balances, along with accountability, come into play very frequently in day-to-day security operations. The sense of urgency that might be present when someone asks for access to a system, share, or application can be strong. Recently I had several access requests come in while working on a large SSO project for a client. While I have the power to make changes in the security configuration, and those changes may make sense, I don't have the authority to make them. The person requesting the changes needed to get the proper approval, the proper signatures, and follow the same process as anyone else.

It might seem like the security policy is something to be drafted, reviewed, and approved once, only to be filed away and almost forgotten. IT security policy management is more than just document creation, and much more than just a check-box on a to-do list. A well-conceived and well-managed security policy can provide a clear vision of the organization's security goals. You might begin with an example IT security policy if you don't know where to start, but you shouldn't depend on a template to meet your requirements in full. Remember that your security policy may be audited later.

Even better, a sound policy delineates a path to follow for processes and procedures to make that policy an operational reality. If you have defined what groups have what users, what their roles are, and what resources those roles allow them access to, and what kind of access, at what times, it's straightforward to go from there to modifying access control lists (ACLs), firewall rules, directory group membership, content filtering, and so on.

Simply enacting a policy and letting the operations staff, administrators, and technicians run with it isn't enough. Security policy management is an ongoing process. It's predictive and assertive in my opinion, not merely reactive. Choosing technology that makes it easy to implement policy can make or break the success of that policy. You may discover after creation of a strong, business-focused security policy that the technology you have in place isn't capable of supporting it. (Time to upgrade...)

You should not just use a free IT security policy you find online, or use boilerplate. Working from an example IT security policy is a place to start, but you should understand your organizations needs in detail. Those IT professionals involved with daily operations, as well as non-IT departments often see security policies as an annoyance, a hassle, and an impediment to getting work done. Just as important as creating an actionable policy is education and explanation about that policy, including what business value it provides and why it is needed. Regulations such as SoX and HIPAA can add complexity and additional effort to the implementation of your security policy.

From the user, client, or customer perspective, I believe it's important to find the best balance between security with usability. It's definitely possible to make a system so secure that the customer can't even use it! We are trying to minimize risk; we cannot eliminate it entirely. I hope this article has demonstrated how IT security policy management is a benefit rather than a burden.

I've edited, revised, and audited security policy for large IT organizations, and helped small to medium businesses (SMBs) with creation of sensible IT security policies. In the enterprise software projects I work on as a PM, architect, or technical lead, we have to ensure that the resulting product doesn't circumvent or violate the organization's security policy.