I like to watch industries evolve in how they deal with information security. It was interesting to watch retail evolve as PCI got more organized. The PCI Council put together the DSS with dates and penalties for breaches and non-compliance, and that drove significant change. It appears that a similar major change within healthcare is starting to take place. We have begun to see a proactive shift that incorporates compliance with HIPAA, an understanding of risk, and the development of security programs.
As I’ve discussed in the past, the healthcare industry is significantly behind in dealing with IT-related risk. For an industry to change its approach to information security / risk, its culture needs to evolve. In my opinion, risk is the most effective driver of this change. If the risk is great enough, industries develop a mature understanding of risk management (of which security is a subset). The military and banking have tangible risks tied directly to their IT assets; therefore, they understand risk. The problem is that this mature understanding of risk doesn’t exist in most other industries. Without risk driving a security program, industries must rely on other drivers - usually compliance (also a subset of risk).
What we’re seeing within healthcare is that PCI is driving the maturation of risk. For example, one key issue that keeps coming up, especially in hospitals, is the belief that PHI is more important than PCI / credit card information. Yet it is PCI compliance that has forced organizations to think systematically about risk. How do you reconcile the budget for PCI compliance with the lack of budget for PHI-related security?
In addition, PCI has forced multiple groups (including IT, security, audit, and finance) to work together to deal with compliance and, ultimately, information security issues. Many of these same groups are now being asked to deal with HITECH / ARRA / updated HIPAA. With the new interpretations of HIPAA, the new regulations, and with these new sets of eyes, these groups are beginning to understand that they are not compliant with HIPAA, that they have significant risk exposure, and that they need to develop programs to deal with this exposure.
From what we are seeing with many of our healthcare clients, the combination of a more pervasive awareness of PCI and new healthcare-specific regulations are creating a more mature understanding of risk and driving a new focus on developing successful information security programs. Let’s hope this trend continues.
We held the Secure360 conference in the Twin Cities last week. Presentation topics included PCI, cloud computing, and problems within the security industry. While it can get tiring discussing the industry’s problems, I like trying to understand the difficult nature of information security and enjoy the challenge of trying to overcome the obstacles related to rationally dealing with risk.
On this topic, Rich Mogull had a very good presentation, “Putting the Fun in Dysfunctional,” about the inherent problems with information security. I appreciate insights from someone with both an IT and a physical security background and I thought he did a nice job discussing why security is such a difficult area for a business to understand. I agree with the points he made that at the most simple level security and risk are abstract, long-term concepts that require a rational approach. Rich did a good (and entertaining) job of illustrating that, as humans, we are often not rational. Generally we deal in the short-term and prioritize with our basic needs. In the context of a corporate environment, understanding and dealing with risk is extremely difficult.
I’d add to Rich’s discussion that in most organizations building mature risk management is essentially like playing a game of telephone across functional departments, most of which find risk and security to be totally foreign concepts (except, of course, at financial institutions).
Rich’s thesis created a nice framework for the other core topics at the conference. A number of presentations dealt with the dangers of cloud computing. Because we created the cloud without rationally dealing with risk and security, it’s an afterthought; there are huge holes in cloud computing security and therefore significant risk. David Bryan had a great presentation on the subject.
The other core topic, PCI, is generally thought of as a compliance issue. Anton Chuvakin put some context around PCI and how it fits as a basis for a security program. I’ve seen a number of organizations do this, and Anton did a nice job outlining the gaps related to using the standard as a basis. While no standard is ideal, it’s a start and generally kick starts a maturation of risk management within organizations that adopt the approach.
Overall, the Secure360 conference was very good and the speakers both local and national were great. Kudos to the organizers. I look forward to next year.
In late March Thales released an interesting report on the state of PCI – “PCI DSS Trends 2010: QSA Insights Report.” The report was written by the Ponemon Institute and it highlights the difficulty of taking into account risk, security and subjectivity within the PCI DSS compliance standard. If you haven’t read it, here’s a link: http://iss.thalesgroup.com/l/program/pcitrendsreport.aspx.
First, the insight that only 2% of organizations fail their PCI audits should raise some eyebrows. Taking it at face value (and there’s certainly room for discussion about that) it indicates that, in general, retailers and payment processing related organizations are taking PCI compliance seriously. However, when combined with another observation in the report, that about 40% of organizations are relying on compensating controls, it illustrates the subjectivity of the standard and of the “auditing” process. There are a number of other conclusions that can be drawn from this high pass rate, and hopefully, the Council will look into them.
Second, the report says that over 50% of the QSAs surveyed observe that information security is still not being taken seriously by the organizations they are auditing. Even though almost all of the organizations covered in the review are addressing PCI, most are not truly addressing security and, by extension, risk – which is a level of maturity that usually requires enlightened management or a breach. This finding further highlights how important it is for audits to be done by competent and honest auditors. Like the point above, this gets at the core of PCI - the standard and the associated subjectivity should evolve to ensure that security and risk be addressed, not just compliance.
Finally, the report states that QSAs feel that firewalls and encryption are the most effective technologies used to protect cardholder data. The number of organizations that think they are doing one thing (with technology) and are actually doing another is amazing. ASV scanning is a very important component of verifying technical compliance, but with self-attestation for many internal components it doesn’t cover nearly enough. With this in mind, the PCI Council should implement further verification to ensure that technology and controls are implemented properly. This would continue to drive the convergence of compliance and security. More reviews - especially third-party - would also help organizations better understand risk and develop mechanisms to mitigate it programmatically.
Overall, the report says as much about the state of the PCI standard as it does about the organizations it covers. Some of the more interesting insights are the implications surrounding PCI’s subjectivity and maturity. The positive take away from the report is that it appears organizations affected by the initial PCI focus (retailers and payment processing-related firms) are taking PCI compliance seriously. To achieve the common goal of reducing IT risk related to PCI data, hopefully the Council will be able use this report (and other similar reports) to enhance the standard to cover more security and risk.
I was at the Healthcare Information and Management Systems Society (HIMSS) national conference last week in Atlanta. Overall, the conference wasn’t much different than past years. From an information security perspective the presentations and conversations were limited, but there were a number of interesting things that I took away from the conference.
First and foremost, healthcare is still very far behind other industries in addressing security concerns at the application provider, hospital and insurer levels. It appears that the larger application providers have begun to address certain concerns; e.g., most healthcare software companies are beginning to address compliance. What’s interesting is that PCI and PCI PA-DSS are the main drivers forcing these organizations to at least review their products. This is obviously backwards, since any healthcare organization would claim that patient information is more important than credit card information, but it’s a testament to how important the stick of strong regulations and standards are when it comes to affecting change in a specific industry. Healthcare software companies still don’t view security or third-party review of their applications as important, but having seen the findings after many of these applications have gone through review, it’s something they will realize that they need to do.
Hospitals and insurers are similarly behind in developing strong information security programs, however many organizations are doing the right thing. It appears that it is mainly larger organizations (revenues $5B+) that have well developed security programs that address risk and compliance programmatically. These organizations generally have the funding and executive support to develop programs that are essentially what you would find in a similarly sized and well-managed Fortune 500 firm. The smaller firms ($5B and less) are generally much farther behind other similarly sized organizations in other industries. Many are just addressing PCI and are just starting to think about how they are going to truly address securing protected health information (PHI).
Based on these observations, there is a lot of work to be done to improve information security within healthcare. One would hope that the discussion surrounding this would take place at a conference like HIMSS. While security was not a main track at the conference, there were some discussions on security at HIMSS within the context of the American Recovery & Reinvestment Act (ARRA) and electronic medical records (EMR) security, including a daylong ARRA seminar on Sunday before the formal conference opening. However, since ARRA isn’t focused on security, the coverage of information security within these presentations tended to be somewhat limited.
It was very interesting that the Health Information Trust Alliance (HITRUST) was not discussed much at the conference. As the most comprehensive and usable solution for healthcare security, there weren’t any sessions on the topic and even conversations surrounding it were heavily overshadowed by discussions about ARRA. As one of the most valuable new initiatives for enhancing healthcare information security, hopefully this will change next year as the industry begins to understand how the HITRUST security framework can be of value to them.
With all the focus and money targeting healthcare IT, the next year will be very interesting and addressing security should be a high priority. Ideally, with the massive amounts of new funding available, more organizations will adopt a risk-based approach to their businesses, backed up by a strong information security program. As illustrated by the success of PCI (even within healthcare), it will probably take a combination of drivers to achieve this, including a strong dose of regulation to force changes within the healthcare industry. Hopefully, the outcome will incorporate standards such as HITRUST to ensure consistency, maturity, and higher levels of security within the healthcare industry.
In this conclusion of the HITRUST blog series, I would like to discuss some definite opportunities and challenges that HITRUST is likely to face.
Putting together a single prescriptive framework for the healthcare industry is truly an ambitious effort. However, cross-referencing this framework with different regulatory requirements and then proposing a mechanism by which companies can be certified against this framework takes any such ambitions to a whole new level. The good news is that many of the healthcare industry’s biggest organizations have gotten onboard and made significant contributions to this effort. Additionally, with the way HIPAA is written, there seems to be a lot of need for a framework such as this, which can enable companies to better defend their interpretations of HIPAA requirements. Therefore, I think the future of HITRUST is going to be defined within the following considerations:
Quality of the Framework – In order for the framework to gain traction, it must be of good quality, and it should achieve its stated objectives of being risk-based and prescriptive. Even though the framework is a product of multiple organizations collaborating, HITRUST does not necessarily govern by community and will make the final decision about CSF content. Another important aspect of the framework will be the approval process of alternative or compensating controls, and ensuring that the process of approvals or denials is transparent. Nothing will de-value the framework faster than perception of its being driven by the agenda of any specific company rather than the industry as a whole.
Maturity of the Certification Process – Having gone through the assessor training, I feel this is perhaps the weakest HITRUST point so far. In starting a certification program from scratch, mistakes are easy to make and are common (just ask the PCI Council). However, PCI DSS was not a voluntary program; compliance was mandatory. Requirements such as submitting complete gap analysis reports to HITRUST (including all found vulnerabilities spelled out in detail) are clearly not going to last, since I can’t imagine any company willing to submit a comprehensive set of their dirty laundry (including all areas where they are not compliant with regulatory requirements) to a for-profit company for their assessment and evaluation. However, I feel that once they begin to get this kind of feedback from HITRUST practitioners, they will make the necessary changes in their approach.
Certification Quality Assurance – Not all consulting firms are equal; in fact they differ greatly in the quality of their work. Therefore, HITRUST needs to establish a better-defined QA program, to govern the certification process. Protecting the integrity of the HITRUST certification will be essential for internal auditors to begin considering it in place of alternative third-party audits.
First Breach / Legal Challenge – In spite of the fact that HITRUST does not make any representations that regulatory compliance is synonymous with HITRUST certification, the first time a HITRUST-certified company suffers a breach or is a subject to regulatory inquiry, we will see the first official test of the framework. One of the big selling points of the framework is that their interpretations of HIPAA are valid and substantiated by the whole healthcare industry. However, if a judge disagrees with any of their interpretations, this may be very damaging to HITRUST acceptance.
I really want HITRUST to succeed. I think it’s a great initiative that has a lot of promise for the whole industry. However, I think it has a long way to go before it is widely accepted, and the certification process is sufficiently mature to inspire confidence on all sides. My recommendation for all healthcare providers and vendors is to begin looking at HITRUST and seeing how their security controls compare with those specified within the CSF. For those companies that do not have a security program in place and are looking to undergo a HIPAA gap assessment for the first time, I would recommend adopting the CSF. After all, the risks are fairly small, since the framework is based on current standards and not anything new. As to the expense of undergoing a full certification, I would recommend putting that on hold until the framework is more widely accepted, or in cases of service providers, until your customers begin to ask you for it.
Subscribe to Industry Blog