We all have compliance issues. Compliance with HIPAA. Compliance with HITECH. Compliance with PCI. These are all well-defined regulations and standards that we should be able to understand quite easily. Compliance is easy.
Yeah, and I have a bridge I could sell you. Cheap.
But, compliance is not really hard per se. It is, however, tedious, time-consuming, and expensive. There are plenty ways to describe compliance efforts. But what does compliance really require?
There are a few things required by most, if not all, of these standards. If you are going to be compliant with one or more of them, you can start here:
1. Do a BIA (Business Impact Assessment), or a data asset inventory, or whatever you want to call it. Identify the applications, data, and systems that are critical to your organization’s operations. In the end, any compliance effort is about the data. Identify all of your cool data, along with where it sits, how it’s received, stored and transmitted, and how it’s accessed. What database stores your cool data, and what applications access it? Include what batch processes touch the data, such as backup processing and any sanitization processing that translates production data into data that you can use for test and development. Put simply, you have to understand what cool data you have and where it is. For that matter, the primary goal of any information security program should be to protect the data, especially the cool data. I am still amazed at how many companies I see that have never really done a decent job at this.
2. Implement a formal security policy. Don’t just write a policy. Write a policy that makes sense, and takes into account what your cool data is, what your company does, and who your people are. Include business-line input, get management support, publish the policy internally, and distribute a copy to all employees. Train employees on the policy and ensure that they understand and agree with it.
Data Segregation
After that, what can you do to make compliance easier? If you know what data you have, you can determine if it’s possible to segregate your data. Think about how much easier your security life would be if you could take all of your HIPAA/HITECH (or PCI, et al.) and maintain that data on a specific set of systems that you could completely segregate from your non-HIPAA/HITECH functions. I once worked in an office that included two separate networks – one for office related functions like email and internet access, and one that provided access to data for more sensitive projects. The purpose was to do exactly this, segregate the data and the access to the data. If Bob did not need access to the more protected system, he would not even get a network drop. The physical segregation was protected even further because standard email/internet access was provided through Cat 5 Ethernet cables with standard RJ-45 plugs, while the physical interface with the “sensitive” network was provided via a BNC connector to fiber. I worked on site at a hospital that did the same thing for clinical vs. office/administrative systems. Only clinical systems went on the red network, and only administrative systems (with email/internet access) went on the white network. All of the red network jacks were recessed, and required a specially formed connector – a white jack, or normal Ethernet cable, simply could not be plugged into the red jack. It sometimes added complexity to their operations, but they viewed it as more of an administrative problem than anything else, and they dealt with it.
Could you change your PCI scope from the 8,000 servers and user systems in your corporate environment to cover just the three servers that manipulate your credit card data? The answer, in case you did not know, is potentially. All too often, the answer is that some data, and supporting systems, just cannot be simply isolated or segregated, but sometimes they can. Simplifying your operational environment is often a good thing.
Encryption
What is the one thing you can do to protect your data above all other mechanisms? Encryption. HITECH has words to describe the difference between encrypted data and unencrypted data. Encrypted data would be Protected Health Information (PHI). Health related data that is not encrypted is Unsecured PHI. This is pretty straight-forward. No matter what else you do with your PHI, if it is not encrypted, it is unsecured. If you haven’t already, you should look at the rules for managing PHI. There are, by my quick count, 23 line item requirements under HITECH (45 CFR 164.404 – 164.414). And, oddly enough, they all apply to unsecured PHI. If your PHI is all encrypted at all times you have exactly zero additional HITECH requirements. Unless, of course, you are going to address other requirements, in case someone does stumble across unsecured PHI.
Good data encryption is either included directly in most standards, or at the very least, good data encryption can meet multiple standards requirements. For PCI alone, encryption directly addresses requirements in PCI 3, 4, 6, and 7. That is a lot of bang for your buck.
So Prove It
Ultimately, the hardest part of any compliance effort is actually proving that you are compliant.
PCI includes a formal assessment process, performed by a QSA (Qualified Security Assessor). If you pass the QSA assessment, you can say that you were compliant with the PCI requirements at the time of the audit. PCI includes some guidance on approved solutions and controls. However, most standards are not as clearly defined as PCI. Whether or not you pass a HIPAA or SOX assessment depends largely on the viewpoint and mentality of the individual doing the assessment. In any given case, the goal of the assessment is to compare what you are actually doing to the exact wording of the standard and its intent.
So, outside of periodic assessments, what do you do to manage compliance?
Don’t ignore the effectiveness of a log management solution. If you are keeping accurate and timely logs of your enterprise systems, you will have the opportunity to capture things like password changes, reported events, system failures, successful (or failed) backups, and pretty much anything else that can be reported in a system log. A true log management solution allows the data collection and retention needs to be met, thereby supporting the inexpensive gathering of large amounts of data. Think of it as tracking all of the little changes that are happening in your environment. You will have to make sure that you are including every system that is covered by your compliance requirements. If you have already done the BIA or asset inventory, this part is easy. Storing the information in a log management solution should also help protect the centralized logs from tampering. Logging itself appears in most of the standards in one form or another, and can help with compliance in almost every section of HIPAA and PCI, along with sections 404 and 408 of HITECH. By including log management in the organization’s security program, compliance is simplified even more.
But gathering the data is not the best part. On top of the log management solution, you will want to be able to run compliance reports against that data. You will want to ensure that your logs are maintained in a manner and structure that allows systematic reports to be run against the data, on demand.
Say you want to be able to prove that you are actively managing authentication in support of PCI section 8 and HIPAA section 308(a)(4)(ii). What if you could run a report against the log data that showed all user creations, with group assignments, and associated permissions? You then have exposure to data for not only the listed sections, but for many other requirements for both PCI and HIPAA. If you have the actual existing data that helps you prove that your processes work in an ongoing manner, you are golden. You’ll be able to prove compliance to yourself, and even better to an external auditor.
If you can identify where your cool data is, you can easily watch what those systems are doing. The real advantage of an active log solution lies in your ability to report on the gathered data in a meaningful way. Don’t give up that opportunity. When it comes to compliance, we can all use every advantage we can get.
Read More Expert Columns in SecurityWeek’s Risk Management Section
