HITRUST Part 3 Certification Explained

As a continuation of the HITRUST blog series, in this post I would like to explore the concept of certification, and what it means.

So, by now I hope you’ve followed my advice and have been browsing the framework up and down. Perhaps you generated a few reports that show you just how easy it is to identify controls for each regulatory requirements and standard. You are now a CSF Ninja and have mastered the framework engine, and now you are ready for bringing the idea of HITRUST certification to your organization. However, there is a very important concept that I must stress with regard to certification:

HITRUST certification does not mean you are compliant with ANY of the regulatory requirements or standards referenced within CSF.

Since this is somewhat counter-intuitive, please take a few minutes to absorb this information. So, what is the value of a HITRUST certification?

To answer this question, it’s important to go back and review my first blog post in this series, and understand that one of the missions of HITRUST is to be practical and realistic in its approach to security. Therefore, the current certification is based on a certain minimum standard that had been agreed upon by all participating organizations. Therefore, the certification is not to be used as a way of proving HIPAA or HITECH compliance, but rather as proof of meeting the most basic security requirements the healthcare industry has deemed as most important. To a healthcare industry outsider this may appear weak and indecisive, and perhaps there is at least some truth in that statement. However, those that deal with the daily challenge of responding to a seemingly unending stream of third-party audit checklists and audits, and those who have to manage controls for hundreds of applications and hundreds of different medical devices will view even such a humble beginning as a monumental effort.

The overall goal is for the HITRUST certification to be used as a way of showing that a particular organization is focused on security and has all the basics covered. As the industry gets better with managing security, I fully anticipate the certification threshold to go up and become even more difficult to obtain. However, while HITRUST seeks acceptance by medical practitioners and various service providers, I think it’s wise to keep the certification requirements more attainable, even if the certification does not equal regulatory compliance. After all, each organization may choose to implement more than the certification minimum and get to a level of compliance before this is required by HITRUST.

In my view, the real value of the HITRUST certification is in simplifying and streamlining conversations between healthcare providers and vendors about the security of PHI data. If a vendor has a single framework to comply with, it may choose to spend more resource on achieving that compliance, and not worry about various checklists and rule interpretations by different security consultants and auditors. Similarly, if a patient care provider can focus on adopting a single framework, and requiring that all vendors do the same, the CSF certification may be acceptable in place of any other third-party assessments.

Please, check back for the fourth and final installment of the HITRUST blog series, when I present some of the opportunities and challenges HITRUST will face in the future.


Vulnerability Alert: FCKeditor Arbitrary File Upload

The worst kind of vulnerability in your environment is the one you don’t know exists. The “FCKeditor Arbitrary File Upload” issue seems to be just such a vulnerability. The purpose of this blog entry is to increase awareness of this issue and provide companies with sources for remediation options. The “FCKeditor Arbitrary File Upload” vulnerability provides attackers with a method to upload arbitrary files (such as web-based shells), and execute commands on affected servers. However, privileges are limited to those assigned to the web server service account or user. The issue was originally identified being exploited in the wild during July of 2009. Since that time it has become a common finding during NetSPI ASV assessments and penetration tests. Unfortunately, many vulnerability scanners still don’t find this issue. As a result, many companies are unaware that it exists in their environment, even though they subscribe to vulnerability scan services. However, this doesn’t have to be an invisible threat. Be sure to contact your vulnerability scanning vendor to make sure that they have a plug-in to identify this issue. In the meantime, I’ve provide some links that contain more information about the vulnerability and how to fix it in your environment.



What is HITRUST? – Part 1

HITRUST is rapidly gaining popularity in the healthcare and security consulting fields, and NetSPI is investing significant resources in developing services that will assist clients in taking advantage of the new Common Security Framework (CSF), as well as in achieving all the benefits of optimizing information security programs against an industry-developed and accepted framework. As a way of introducing this new development, I will write a series of blog posts intended to familiarize anyone interested with just what HITRUST and the CSF are all about. So, let’s dive in…

Imagine that health providers, payers, and service providers got tired of constantly having to deal with different interpretations of regulatory requirements, an ongoing series of compliance and third-party audits, and inconsistencies among different regulatory standards. Also, imagine that they decided to get together and perform the tremendous task of not only correlating various regulatory requirements, but also reconciling any differences among standards. Well, that happened… sort of. More specifically, the Health Information Trust Alliance (HITRUST), a for-profit company, brought them all together and assisted them in this very ambitious effort called the Common Security Framework (CSF), available for free from their website. (

In addition to developing the framework, HITRUST has positioned itself as a certification body that will allow companies to demonstrate their acceptance of the CSF framework, by issuing a certification. It is important to note that certification does not mean that the organization has implemented 100% of the controls described within the framework, but rather that it meet a specific certification threshold. Another important note is that certification does not mean compliance with all standards included in the CSF… but more on that later. The minimum certification requirement has been agreed upon by all participating members as the current minimum standard for security controls that an organization in healthcare should maintain. This approach is consistent with the goal of having the framework be based on practical expectations rather than often unrealistic regulatory expectations.

The reality is that most companies are currently not compliant even with the most basic requirements required by HIPAA, and now further enforced by the HITECH provisions of the 2009 American Recovery and Reinvestment Act (ARRA). Even with the level of specificity added by HITECH, there is a lot of room for interpretation of the requirements by auditors and security analysts. Recognizing this problem, the HITRUST Alliance has decided to leverage the power of the healthcare community at taking a step forward in defining a certain minimum set of requirements, intended to move all providers, payers, and business partners in the right direction. Additionally, if your organization has the misfortune of having to defend its security controls and demonstrating HIPAA compliance in court, being able to demonstrate the use of controls approved by the larger healthcare community will provide a stronger legal position.

Check back for a more detailed look into the CSF, as well as information about the certification path and my humble opinions about the future opportunities and challenges for HITRUST.


HITRUST Part 2: Taking a First Look at the CSF

As a continuation of the HITRUST blog series, in this post I would like to take a closer look at the Common Security Framework CSF, and what it’s all about.

The CSF is designed based on the ISO/IEC 27001:2005 and ISO/IEC 27002:2005 standards. Additionally, the framework currently includes:

  • NIST 800 series of standards
  • ISO/IEC 27799:2008 Health Informatics
  • PCI
  • HITECH Act
  • FTC 16 Red Flags Rules

HITECH is planning to add other regulatory requirements and standards, such as EHNAC’s Healthcare Network Accreditation Program (HNAP-EHN), Healthcare Information Technology Standards Panel, and CMS Information Security (IS). However, the real value of the framework is not in that it provides a clear cross-reference between these and future requirements, since this information is already available within a broad range of compliance management tools, but rather that the reconciliation of the different standards and the additions of the controls are based on experiences and best practices from the HITRUST participants.

Each control described within the framework includes basic information such as control objectives, descriptions, and a few different categories that it may be associated with. Additionally, each control includes the following, which differentiates it from others:

  • Control Implementation – This is a prescriptive description of a control that provides     detailed information about different aspects of implementation.
  • Control Audit Procedures – Detailed instructions that clearly document the steps that CSF assessors should take in order to accurately ascertain compliance with the specific control.
  • Control Standards Mapping – All regulatory requirements and standards that apply to the particular control.
  • Alternative Controls – Compensating controls that have been approved by HITRUST, that may be used in place of the controls listed. All organizations may submit their alternative or compensating controls to HITRUST for approval, which will subsequently include them in the framework for the benefit of other companies.
  • Required for Certification – Some controls are marked as required for certification, while others are only recommended for compliance with specific regulatory requirements. (I know that ability to certify while not being compliant is odd, but hang in there, I will tackle this topic in the next blog post).
  • Organizational or System – Organizational controls are implemented for the entire organization, while system controls should be implemented and audited on each system containing ePHI.

The engine supporting the framework allows easy searching and navigation of the framework. Additionally, all regulatory requirement and standards references are presented as hyperlinks that will navigate directly to the original authoritative sources. HITRUST also has created several reports that can enable companies to determine gaps within any of the regulatory standards, based on the framework control references. Overall, since the framework is available free of charge, I strongly recommend people to register with HITRUST and browse around.

In addition to providing a list of controls, HITRUST has also incorporated different levels of implementation for different controls. These are guided by the size of the organization, and range from Level 1 (most basic implementation) to Level 3 (most advanced security). Therefore, in order to understand which level of implementation would be applicable for a specific organization, it’s important to pay attention to the organizational and system factors, which include a wide range of consideration such as the need for PCI compliance, number of patient visits or hospital beds, number of employees, internet connectivity, or many others. However, in order to allow for easier and more automated determination, HITRUST has created spreadsheets where an organization simply needs to fill out some basic information, and the next tab will provide the required levels of implementation for each control.

To summarize, the CSF is specific, prescriptive, and scalable, providing not only guidance for implementation, but also for validation and attestation of compliance. The framework is intended to be in continuous development, by addition of formally accepted alternative controls, as well as entity type specific implementation requirements. Another important misconception is that CSF is a new standard. In truth, the CSF is an interpretation of other existing standards. Therefore, even if adopting a relatively new framework seems like a risky investment of time and resources, I would encourage organizations to at least become familiar with it. You never know, you just might find some great ideas that may be applicable for your environment.

In the next post in this series, I will focus on the topic of HITRUST certification, and what it means in the context of compliance with other regulatory requirements such as HIPAA, HITECH, and PCI.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.