Comply (And/Or) Die: Conforming With Multiple RegulationsComply (And/Or) Die: Conforming With Multiple Regulations

Once upon a time, CIOs considering a new project or purchase weighed whether it helped IT support the core mission of the business. Now, for most of us, the decision process is laced with the additional complexity of asking, "Will this also help us with compliance?" Moreover, the days when we had to worry about only one regulation are mostly gone--when we asked the 379 respondents to our information Analytics survey on regulatory compliance how many requirement sets their organizations are addressing, the No. 1 answer was four or more, at 35%. Add to that ongoing budgetary pressure and a political climate that seems to favor more, not less, regulation, and who can blame IT groups for feeling stretched to the limit?

Fortunately, there are ways to work smarter and cover multiple compliance mandates with careful planning. In our full report, "Comply And/Or Die," at information.com/analytics/ conformance, we help IT come to grips with the daunting task of addressing the myriad controls involved when you must comply with two or more regulations. By focusing on similarities and overarching concepts and requirements, IT can target high-value areas and add efficiency. The key is to focus resources and structure the strategic process to ensure applicability across multiple regulatory standards.

Sounds like good advice for everyone, right? In fact, we take the fairly uncommon standpoint that our increased focus on regulatory compliance has had many positive effects for IT, in particular around information integrity and protection. But it has raised troublesome issues as well. Regulatory compliance tends to encompass some of the most disliked facets of technology and process--particularly, a prescriptive set of requirements backed by the threat of dire consequences if rules aren't adequately met. Yet, IT controls in many regulations are qualified with squishy terms, such as "appropriate security" or "reasonable protection."

There Is A Path

With the "audit-proof security program on a shoestring budget" ideal in mind, let's explore the scope of the problem. A minority of the 379 respondents to our survey are wrestling with just one standard, compared with the almost 80% who are dealing with at least two regulatory requirement sets simultaneously. And single-compliance organizations shouldn't get too comfortable. Generally speaking, the past decade brought a marked increase in regulatory oversight of sensitive information, and this trend is increasing at both the state and federal levels.

"Infosec pros have long complained that FISMA is not a threat reduction or risk mitigation framework--it's a giant exercise in covering one's posterior," says Michael A. Davis, CEO of security consultancy Savid Technologies and an information contributor. Davis recently spoke with National Institute of Standards and Technology director Dr. Ron Ross about plans to make the regulation more effective. Ross says that, instead of providing more control guidelines, NIST is going to become more prescriptive, similar to PCI. It plans to provide more methods and processes that can be quickly implemented and that generate measurable outputs. Furthermore, Ross says, the agency wants these prescriptive controls to be more targeted to the threats that organizations are seeing in the real world.

Don't Run Scared

We went back to our data set to identify the regulations that respondents expect to wrestle with most in the coming year. HIPAA is in first place, with PCI and SOX tied for second from a priority standpoint. We decided to focus on HIPAA and PCI because of the ubiquitous nature of both standards and the amount of useful supporting documentation that's available. But the information in this article and our report should map to key SOX, FISMA, GLBA, and other requirement areas as well.

A number of factors drive us to pay attention to regulatory compliance, from expensive legal repercussions to negative publicity and its effects on the bottom line. While fear may be a good motivator, however, it can also cause us to overreact and blindly shovel money at the problem without a definitive plan. A better incentive is risk reduction. Almost half (48%) of the business technology professionals we polled say they hope that by meeting regulatory requirements, their sensitive data will be significantly better protected.

That's a smart goal as well as a realistic expectation.

The downside is that only a tiny percentage, just 6%, think it's actually likely that their organizations will become more effective and efficient as part of this process. That pessimism is a useful warning on the potential collateral damage that may accompany regulatory compliance; respondents are concerned about the additional overhead that new policy frameworks and controls might cause. IT teams will need to be particularly vigilant about reaping the benefits of security controls without unduly crimping employees' creativity or ability to get work done. It is possible; in practice, we've seen organizations actually benefit from the enhanced structure and consistency--it's all in how you manage the process.

Examining PCI DSS and the HIPAA Security Rule illustrates how these requirements differ, but more importantly, how they're similar.

The HIPAA Security Rule is intended to provide a set of standards for the protection of electronic medical records, often referred to as electronic protected health information, or EPHI. HIPAA has two groups of controls, Required and Addressable. Required controls must be implemented, period. These include conducting a risk assessment, security incident handling and disaster recovery planning. IT has a bit more flexibility in addressable controls, such as having workforce clearance and termination procedures, in that these areas allow the implementer to assess if the control in question is reasonable for the current operating environment.

The Payment Card Industry Data Security Standard is, in contrast, a set of fairly detailed requirements that are intended to protect credit card payment information. To this end, a specific set of controls is outlined. Much like HIPAA, PCI DSS also breaks its security program down into smaller groups that include such topics as building and maintaining a secure network and maintaining an information security policy.

A key differentiator is that the Data Security Standard document occasionally delves into very specific protection mechanisms that must be established to protect PCI data, as opposed to relying on IT's interpretation of adequate security. For example, there are detailed firewall requirements, wireless LAN encryption standards, and mandated security policies and procedures. If you expect to go through a formal PCI audit, being comfortable with all facets of the DSS is a must.

Although PCI and HIPAA are protecting different types of information, the philosophy is actually quite similar. Simply put: Make sure that the organization has identified the relevant data to be protected and is ensuring its security. That's it. Sure, the devil's in the details as to the best approach to take to secure information, but the more similarities we can draw between different regulatory sets, the more likely we are to find common ground and begin leveraging economies of scale.

The good news is that more than 70% of our respondents classify their compliance efforts to date as providing at least a fairly secure and mostly documented program. The bad news is that many of these organizations seem to have a relatively short time frame to complete compliance programs--on the order of five months or less. Depending on how mature the existing security infrastructure is and the level of resources being thrown into this initiative, that can be a tall order.

Still, we're encouraged that almost 80% of respondents say that serious effort has already been put into trying to comply with one or more regulatory sets, and that modest to significant resources are being provided to these efforts. This indicates that there's at least a partial match between the desire for compliance and the reality of how to get there.

The Approach

When it comes to regulatory compliance, the framework you select for your organization will set the tone for the whole security program and ultimately structure how you'll approach risk mitigation. There are numerous documents available, either free or for a fee, to help define program aspects. These documents will either be specific to a particular regulatory compliance area, such as the PCI DSS, or take a more agnostic approach, such as the ISO 27001/2 documents; we cover security standards in much more depth in our full report.

Many times, we see IT groups pick from multiple documents to create a final methodology. There really is no right or wrong answer here. What is crucial is that you don't try to start from scratch--standards bodies have spent hundreds, even thousands of hours developing sophisticated control suites. Further, by using the methodologies of well-regarded standards developers such as ISO, ISACA, and NIST, you'll add credibility to your programs while saving money and resources.

Think of a security program framework as providing the universe of possible control areas that IT can address either tactically or strategically.

For a comprehensive yet flexible security framework for meeting multiple compliance objectives, consider starting with guidance from ISO 27001 and 27002. Although these pubs aren't free, they'll set you back around $350 for both--well worth it given the amount of time saved in structuring the overall vision of your program. The ISO documents work together, with 27001 defining the vision for the program and 27002 providing more tangible control objectives. If time is of the essence or a program management approach is already in place, you can skip 27001 and simply continue to flesh out your existing program using the control areas from 27002.

The ISO 27001 standard uses the "Plan Do Check Act," or PDCA, approach:

Plan: Create the Information Security Management System (ISMS) objectives, policies, procedures, and documents required to properly address risk in the environment.

Do: Implement the ISMS that has been planned.

Check: Verify and monitor that the ISMS is performing as needed.

Act: Execute ongoing enhancements and tuning of the ISMS to ensure that it's adequately protecting the environment and iteratively being improved.

Our proposed security program flow is as follows:

Acquire and review ISO 27001 and 27002. This provides the "blue sky" approach and granular information that will need to be trimmed down.

Make a plan. We're not looking yet to follow all aspects of the ISMS, given the potential overhead. This first attempt often takes the form of writing a security policy that states the main tenets of how regulated information is to be protected by the organization, discusses management's support for the program, and provides the basis for other controls.

Prioritize. Begin selecting the most critical policy areas that need to be documented and start drafting, refining, approving, and using them in your environment.

Review and slot existing security controls into your new program framework. Depending on what you have in place, begin selecting and addressing areas of weakness. If you're not sure where to start, focus on controls that provide cross-regulatory value.

Continue to maintain, enhance, and expand. Any security program must be viewed as a living organism, and not just a "fire and forget" fix that can be completed and then boxed away until next year. Organizations are constantly changing, and so are the risks facing electronic data and security infrastructures. A well-designed program will be flexible enough to adapt to the organizations' needs.

A final note: Don't follow the 21% of respondents who give staff training short shrift. Imagine the benefits if your users were alert and watching for social engineering attacks, understood why unknown attachments shouldn't be opened, and sympathized with why passwords need to regularly change--and be complex! Don't write off user security awareness and training. It could save your hide.

Richard Dreger is president of WaveGard, a vendor-neutral security consultancy.

Write to us at [email protected]