How to Reconcile Different Definitions of PCI DSS and HIPAA Compliance

Compliance would be challenging even if it were a black and white issue. The reality is that compliance regulations, such as PCI DSS and HIPAA, are really just a string of requirements open to interpretation. The definitions of each requirement can vary, sometimes quite a bit, from auditor to auditor or from company to company. Today,even the auditors are getting audited in an effort to ensure that the application of compliance regulations is as uniform as possible.

Part of the challenge is that there’s actually no governing body in charge of defining what each of these requirements really means. So what one audit firm or company deems as appropriate monitoring, for example, may be quite different from the next. How do you know which way is right? Moreover, auditing firms are businesses themselves, and as such, have developed their own interpretations of and recommendations for compliance issues.

So what do you really need to do when it comes to compliance? This is a tricky question to answer, because it involves sorting the “real” from the “not real.” Some of the requirements are more in the vein of suggestions, while others are non-negotiable.

You also need to know whether you are wearing your compliance hat or your security hat when you’re implementing new processes or answering customer questions. See, while compliance mandates are aimed at providing standards that will protect consumers and their data, the reality is that they are not nearly enough to guarantee actual security. You can be compliant and not secure. You can also be secure and not compliant.

Of course, as frustrating and opaque as compliance can be, you can’t throw the baby out with the bathwater. Ifcompliance is a business driverfor you, then you do it. So, all that said, here’s what you need to know about navigating the gray areas and blurred lines of HIPAA and PCI DSS compliance.

HIPAA = A Lot of Gray Area

HIPAA is pretty widely recognized for its broad and generalized requirements. It doesn’t help that it has been amended several times since its inception in 1996. New regulations came out in 2003, and were revised again in 2006. Then there were the HITECH updates, all rolled into the OMNIBUS. It’s a lot to keep up with.

What you really need to know is that HIPAA has three major parts: Security, Privacy, and HITECH. If you’ve been to the doctor recently, you probably know about the privacy disclosures that are given to every patient as part of the HIPAA privacy guidelines. HIPAA privacy guidelines generally affect how personal healthcare information (PHI) is stored, accessed, distributed, and protected.

The security standards, interestingly, have quite a bit of generality written into the rules themselves. For example, part of the standards state that “Covered entities may use any security measures that allow the Covered Entity to reasonably and appropriately implement the standards and implementation specifications.” (Emphasis ours.)

It goes on to explain that, in making these decisions, you can take into account factors like your organization’s size, complexity, and capabilities, as well as technical infrastructure, costs, and the likelihood of risks to electronically stored PHI.

In addition to this leeway around deciding what makes the most sense for your organization, HIPAA states that some of its rules are “required,” while others are “addressable.” While “addressable” may seem at first to mean “optional,” the reality is that just as much effort (sometimes more) must go into documenting why you are not meeting a regulation as would go into meeting it in the first place.

If this sounds a little abstract, here’s a good example: encryption. HIPAA simply states that you must encrypt data with “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.” Basically, they’re saying: encrypt data so the bad guys can’t see it. They’re not telling you how to do it (which PCI DSS does with specificity, as you’ll see below.)

While there’s quite a bit of gray area, you need to carefully study the HIPAA rules and implement them in ways that make sense for your organization. This will almost certainly mean bringing in a third party. If you use a cloud security platform likeThreat Stack that provides continuous monitoring and deep auditing capabilities, you’ll be able to check a bunch of boxes without extra effort (we’ll get into this in more detail later on.)

PCI = More Specific, But Still Fuzzy

PCI DSS is quite a bit more specific than HIPAA. It actually calls out requirements, and in many cases, also offers quite a bit of detail. However, there are spots where it falls short. For example, PCI DSS requires you to use a firewall to protect your data. But you could theoretically install one, never configure it, and still be compliant! This is what we mean when we say that security does not equal compliance and vice versa.

On the whole, however, PCI DSS is pretty clear. The organization behind PCI DSS describes the standards as an “actionable framework for developing a robust payment card data security process — including prevention, detection and appropriate reaction to security incidents.” PCI DSS documentation includes requirements, testing procedures, and guidance meant to demystify the process.

In one case, PCI DSS requires organizations to “Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.” It then goes into detail about what constitutes open, public networks. And while it does not specify what qualifies as “strong cryptography,” it does call out that certain technologies (e.g., SSL) are not sufficient in and of themselves and must be fortified with further measures.

While it can still be overwhelming (to say the least), there is certainly a lot more specificity to work with. When it comes to PCI DSS, the best approach for making sure that you achieve compliance is to understand the underlying principles that it is trying to get at. For example, one of the major goals of PCI DSS is to protect cardholder data. You should be able to answer the question “Is cardholder data exposed at any point before, during, or after transactions?” If you can’t answer that question, you probably aren’t PCI DSS compliant.

As with HIPAA, having a cloud security platform like Threat Stack in place can help you check quite a few compliance boxes for PCI DSS by verifying that you can monitor things like user access controls at all times.

Clearing the Fog: Can You Answer These Questions?

When it comes to compliance, the bottom line is that you need to answer some tough questions. These may come in the form of an audit (self-imposed or otherwise), a customer or prospect query, or an internal review. Here are some examples of questions you should be able to answer:

If you terminated a security engineer today, how would you make sure they didn’t have access to your environment tomorrow?

Do you know what every asset is in your environment and what it does? Do you know what they’re connecting to?

Do you know where your sensitive data lives? When it’s in transit? Who has access to it at any point in time?

Do you know every time your firewall goes down?

These are just a few examples, but if you can’t answer these questions right now, it’s safe to say you have a good amount of work to do.

Before you panic, remember you’re not alone. Most companies struggle with this at some point or another. When it comes to cloud environments in particular, backdoors are everywhere, especially if you haven’t implemented a security platform like Threat Stack. In many ways, the key to compliance is continuous monitoring, which allows you to rewind and replay if something goes down. Implementing a platform like Threat Stack not only ensures security, but allows you to get through the compliance rigamarole with significantly less stress.

That’s What It’s All About

Compliance isn’t really about being 100 percent secure; there’s a lot you need to do to be secure that is above and beyond compliance. Compliance is about being able to answer tough questions like the ones above. It’s about being able to check the boxes and prove to an auditor or customer that you are taking reasonable precautions in line with specific compliance rules.

With Threat Stack in place, customers are able to mark Threat Stack as the “how” to many compliance requirements and move on. That both streamlines your compliance process and means a lot less explanation for a lot more protection. You can’t argue with that simplicity, right?!

Want more compliance content? Sign up for automatic email notifications when new posts in this series go live: http://get.threatstack.com/compliance-blog-series. As a bonus, we’ll make sure you’re the first to receive the Compliance eBook we’re releasing at the end of the series.

15 years of experience as a security engineer at Trusteer (IBM Security), Core Security Technologies, and Threat Stack, has made Anthony a valuable member of Threat Stack's growing Oversight team. Anthony helps our customers deploy, configure, fine-tune, and manage their continuous security monitoring so they can run secure and compliant, without sacrificing time and resources.