Legal optimize

Take technology out of your security policies to maintain compliance

Are you tired about wondering whether your organization is compliant with all the regulations that affect it? Mike Mullins has a rather unorthodox suggestion: Take the technology out of your policies. See why Mike says doing this will make it easier to address compliance in your company.

As the U.S. government continues to impose more and more regulations on businesses, compliance has become an increasingly sticky issue for many companies. Most legislation -- including the Children's Online Privacy Protection Act, the Electronic Signatures in Global and National Commerce Act, the Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOX), the Gramm-Leach-Bliley Act (GLBA), and the Federal Information Security Management Act (FISMA), to name a few -- all have a universal theme: They require companies to securely configure and control their network infrastructure.

Many organizations approach compliance from the wrong angle. They make the mistake of looking at the multitude of regulations and trying to decide: Are we compliant?

But that's not the right question. What companies really need to be asking is: Are our policies compliant, and do we follow our policies? Stop chasing compliance by implementing new security technologies, security devices, and/or security controls; instead, address the issue where it belongs -- in your security policies.

Where to start

The first step is to understand that policies are a blend of your corporate and compliance requirements and legal obligations. A policy isn't a technological review -- it's a compliance and legal guideline that addresses corporate requirements.

That's why you shouldn't create policies based on technology. Technology changes faster than you can modify your policies.

For example, don't say, "We must secure files containing customer information using file security and encryption." Instead, create a policy that states, "We must secure customer information so that only authorized individuals can view or modify it."

By changing the wording in this one sentence, you've made a huge difference. You've covered access permissions, both electronic and hard copy security, storage security, and the transmission of that information internal and external to your business environment.

Where this leads

It may seem counterproductive, but taking the technology out of your policies can help maintain compliance. You can use the policies to specify business goals while meeting legal requirements, and you can then use the policies to address the different areas of compliance.

One of the most troublesome areas of compliance is often auditing. Auditing can mean several different things depending on who you ask to define it. For example, an accountant and a firewall administrator will give you two completely different definitions. However, your policies must address both areas.

Don't write an IT security auditing policy that states, "Retain all electronic logs that contain records of system or file access for a period of three years" -- you don't need to be that specific. Your overall security policy should state, "Retain records of all authorized and unauthorized access to business resources, systems, and processes." You've taken technology out of your policy and addressed compliance as an overall business process.

Final thoughts

Chasing compliance with changes to your network and new technology is a losing battle. The IT pros who manage the protection of your network are usually a sharp bunch. If you give them broad policies that address your corporate requirements, they'll use those policies to set security standards for your infrastructure -- and enforce those standards through network compliance management. As long as your policy is up to date, your days of wondering Are we compliant? are over.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.

7 comments
tomg642
tomg642

Michael's thinking around how auditing can mean several different things depending on who you ask resonated with me. His example of how an accountant and a firewall administrator will give you two completely different definitions could just as easily apply to roles and responsibilities as they pertain to compliance. A CFO will talk and think differently about compliance than a GC or a CIO. It all comes back to policy; IT provides the means to manage compliance but it's rooted in policies that should not be written for the technology. Michael's thoughtful article and the comments gave me a lot to think about -- like what policies would say if they could talk. I ponder the possibilites in a blog entry here: http://www.polivec.com/index.php/blog/post/if_it_policies_could_talk/

nath
nath

The article may help the CEO and CFO to keep their mind free of technology clutter while laying out the policy. The mapping from regulation to policy is mandatory. Making policy compliant with regulation may be necessary first step but not sufficient to meet the end state of compliance. Manual compliance of paper based policy has been proved to be inadequate and this has now been accepted. Where technology comes in is when we realise that the paper based policy can neither be enforced not monitored and worse still can not even been audited to meet the compliance requirement. With out the modern identity and access management system, the the exercise of paper based policy become futile because it is just not implementable. It will be like laying out the grand intention of saying that we need to reach out to europe but reaching out to europe will mean using technology and the process of reaching out itself will be governed by technology. It may even start with flying to europe and not start walking and hoping that we would reach our destination some day in future,if at all. We need compliance and we need it to day and not in some future millennium. Technology enables compliance. Incrementally reaching closer to Europe one small step at a time may be a small step for man but we need to leap out and we have time pressures. Making policy compliant is only a small step, not the leap enterprises are required to make by the regulation.

sjhyde
sjhyde

I agree completely with this viewpoint, but you should be cognizant of the fact that there is a fine line in play here. Certainly, broad policy terms allow you more flexibility when creating your environment, but if your policies are too broad you allow for too much interpretation on the part of the auditor. Policies that address regulatory compliance in part, should also have supporting documentation of factors that helped drive the final decision. In IT areas, the basis for that documentation is typically your risk analysis.

aghai
aghai

The suggestion that policies come first and should stay independent of technology is a sound one. A policy by definition is broad and serves as a guideline. Appropriate standards and procedures should provide guidance and boundaries to help those implementing the policies or conducting the audits.

Ron_007
Ron_007

That's the way I've learned it too. Policy is high level direction. General guidance. Doesn't have to change very often because it doesn't mention specific technologies. Procedure is the step by step cookbook for implementing the policy. It changes to match evolving environment. Standards/Guidelines define the specific current approved technologies used in the procedures to implement the policies. One thing not mentioned yet, is that policies have also have to have sanctions. If you violate the policy, then this, that, or the other will happen to you. And of course, policy compliance needs to be monitored and enforced.

pm0080
pm0080

All the ISO Standards require a broad policy statement, but then follow up with a manual and defined procedure which address who a company is to address the policy.

Kairoer
Kairoer

I found this article a great one! Imho, policies are to be easy to use, not a technical, detailed and boring blueprint. I always makes a point of using the good, old KISS - keep it simple, stupid. Doing so, makes it easy to use, understand and apply the policy. And as you point out, compliance comes as a nice bonus. I discuss the topic at my blog. http://www.roer.com/node/105