We’re not talking about plain old rules, but rather mandated rules as defined in a federally enacted legislation. As someone with a career in information security, my first answer is “yes, regulation is good for security.” Regulation helps make sure that people and companies are protecting the security of their systems, networks, and information, even minimally. If you are faced with regulatory compliance, you are faced with a legal issue. And, if you are not compliant, you are essentially breaking the law.
But the devil is in the details.
I know perfectly well that there are many standards and regulations in place. But which ones are the most impactful?
HIPAA/HITECH has been around now since 1996. The main purpose of HIPAA was originally to help ensure portability of insurance in the event an employee changes jobs. This grew as the bill grew with a variety of contributors, and soon included requirements to establish national standards for electronic healthcare transactions, and to help curb Medicare fraud and abuse. If fully enacted and universally supported, it had the potential to reduce healthcare expenses. But compliance, as well as enforcement, has been, spotty at best. While some organizations have fully adopted the HIPAA requirements, many are still making only minimal effort. Part of the HIPAA act included language to actually secure electronic records and limit the ways that healthcare organizations can use information. If you have gone to the dentist or doctor in the United States over the last few years you have undoubtedly been given a copy of their HIPAA policy that says they do not share or sell your information. This is a good thing, and is probably the single most effective result of HIPAA legislation to date.
HITECH extends this somewhat by adding additional security controls, most notably breach reporting rules. It also essentially states that good encryption, while not a formal “requirement,” is a big boon to your information security.
All in all, HIPAA is a good thing. It can save money, and improve care, while helping to keep your medical information safe. It could do all of this if compliance was as universal as it was supposed to be when the legislation was written. Part of the original “problem” with HIPAA was the way it was written – by committee, not practitioners. Think of it more as a “thou shalt” than a “we shall.” The most serious catch to HIPAA compliance has always been that it is anti-cheap. Some of this is because of the vagueness in the language, and some is in the sheer size of the requirements. The clear “win” for HIPAA is not obvious to most organizations, but the fact that HIPAA compliance costs money is clear. As a result, true compliance has lagged. Historically, this has had limited impact on organizations – in most cases there is simply no real consequence of lack of compliance. There are consequences of noncompliance built into the act, but for the most part, fines and sanctions have failed to materialize.
So, when talking about HIPAA compliance, we are faced with a cost to implement and no real disadvantage of noncompliance. The federal legislation essentially added operational complexity and cost. Realistically, I suspect that HIPAA has had a positive impact on most, if not all healthcare related organizations, but only to the extent that it helped instigate additional security actions. However, these organizations have made true “compliance” a high priority. Admittedly, this statement is based primarily on my own experience with healthcare organizations.
Now, let’s compare HIPAA compliance with other federal legislation like PCI – Payment Card Industry compliance.
Wait a minute. PCI is an INDUSTRY requirement, not a federally mandated one.
I was not involved in PCI, and to this day, I am still an outsider looking in. But, I kind of imagine that PCI was a more iterative process, based on a combination of the company specific requirements of the original programs of the credit card companies involved. Each credit card company had their own set of requirements. Someone, most likely from an external company that had to comply with all of these requirements, pointed out the fact that all five of the original programs were comprised of a core of essentially similar requirements. The original programs were based on a combination of legislative requirements to protect financial information, paired up with business requirements to protect the clients and financial information within each company. The PCI Council was formed, and worked on a joint venture to define a single unifying standard. Mind you, this was all without any specific federal legislation forcing the issue. I may be wrong, but I suspect that given the growth in the credit card industry during this timeframe, along with the rise in cyber attacks, fraud, and identity theft, I would expect that federal legislation would have been put forward to help protect consumers as well as the industry. But, PCI beat them to it by defining their own successful process first.
The first big win for PCI was the level of detail that has been put into the requirements. PCI does not have specific requirements that are completely actionable, but guidance was better defined and more specific than many other standards, such as HIPAA. PCI definitely suffered from some of the same issues as HIPAA, for instance, it has never been cheap or easy to be PCI compliant. And, though PCI was written by people who actually had to do the things identified in the requirements there was still room for interpretation and creativity in implementation. If you read early PCI guidance, it is obvious that some of this language was written by information systems and security engineers.
But, the language actually helped. PCI was written as guidance. However, it was accompanied by implementation guidance that actually worked because much of it was based on things that the authors knew were effective. This is not to say that PCI is perfect. Just because you are PCI compliant, it does not mean you are absolutely secure. More than anything, it means that you have done the required things for the identified systems. Part of making sure this works correctly is defining the boundaries of your cardholder environment, and part of this is looking at what other parts of the organization can impact the defined cardholder environment. It takes more than a single standard to protect an organization from an advanced attack, especially one that uses multiple attack vectors.
The second biggest win was that PCI also established compliance requirements. This included a formal compliance audit process that included self assessments and trained auditors. And, even the QSAs (Qualified Security Assessor) and ASVs (Approved Scanning Vendor) include their own validation process. You don’t just get to be a QSA or ASV without a formal vetting process. The third component that made PCI work was consequences. If you failed to be PCI compliant, it mattered. Consequences include fines, potential litigation costs, increased audit cost, and the loss of card privileges. What’s more, the industry understands that noncompliance has consequences.
The results kind of speak for themselves. PCI has a reputation as a successful program.
Another looming security standard is the Cloud Security Alliance’s (CSA) Security Guidance for cloud security. Cloud services are currently one of the largest growing industry segments, and if you look at the potential benefits of a cloud solution, it’s no wonder. But “the cloud” is not without risk, and vendor selection and vetting is an issue.
There are two basic questions in the process:
• How do you pick a qualified vendor and have confidence they are offering true cloud services in a secure manner?
• As a cloud provider, what do you need to do to protect client information and your own infrastructure, while being able to offer the required cloud services?
The CSA is following the PCI lead of jumping on compliance driven by the industry instead of waiting for governmental legislation. The CSA is also going about the process in the right way. Industry participation is driving a set of recommended standards that are currently being vetted through an open review process. The purpose of the review is for practitioners to review the proposed requirements and determine if they are actually actionable and practical in an operational environment. What a concept.
Compliance guidance also includes a controls matrix and assessment questionnaire that can help both the cloud vendor and a potential client to evaluate the security controls of the provider. While this is not quite to the level of formality of PCI’s assessment process and QSA process, with the finalization of the CSA’s Certificate of Cloud Security Knowledge, it is a step in the right direction of defining a manageable security standard.
1. Define the standard, compliance requirements, and implementation guidance.
2. Define a compliance process, including authorized assessors and assessment processing.
3. Define consequences.
So far, it appears as if the consequences are going to be more driven by business than specific sanctions – the market is volatile enough that if a vendor is not doing what they need to the chances are they will not be around for long.
This is actually a pretty good consequence for where the CSA is right now. Their battle on meeting the three steps above is going to be interesting, and if they can keep momentum, they might actually hold off government intervention of mandated controls. In turn, this could mean that “cloud security” would actually mean something because it was defined by cloud people instead of “Washington”.
How cool would that be?