The idea is that organisations that implement HITRUST—a sort of "one framework to rule them all"—will have done all or almost all of the work necessary to conform to a variety of cyber security regulations and standards.
The framework is a creation of the HITRUST Alliance. The name was originally short for "Health Information Trust Alliance" and focused on HIPAA and similar regulations, but the company has since expanded the framework to embrace other industries, such as financial services and defence contracting.
In any market segment where cyber security pros face an alphabet soup of regulations or industry standards, HITRUST aims to make their lives easier. But how does adding yet another framework to the mix help?
To understand how this works, we need to first understand what we mean when we talk about a security framework. This isn't some whiz-bang software tool or hardware appliance; instead, it's a set of policies and procedures meant to improve your organisation's cyber security strategies.
There are innumerable frameworks available out there, some put out by for-profit companies, some by industry cyber security orgs, and some by government agencies. This last category will become important for our discussion: many government regulations that touch on cyber security have at their heart prescribed frameworks that companies need to implement in order to be in compliance.
HITRUST's framework, known as the HITRUST CSF, works along these same lines. What makes HITRUST special is that it isn't attempting to impose its own unique security philosophy onto its users; rather, it consolidates multiple existing public domain security frameworks into a single document.
For instance, plenty of these frameworks require all passwords within an organisation to be eight characters or more; therefore, the HITRUST CSF includes an eight-character password requirement for those organisations to which that control applies. We'll discuss in more detail how you determine which HITRUST controls apply to your organisation in a moment.
HITRUST vs. HIPAA, HITECH, NIST, and more
So does this mean that, if you implement the HITRUST CSF at your enterprise, you're automatically compliant with HIPAA or HITECHor the NIST Cybersecurity Framework? Well, not exactly.
HITRUST's "Introduction to the HITRUST CSF" lists 44 "major security and privacy standards, regulations, and frameworks" that it draws on (you can find them all under the heading "HITRUST Authoritative Sources").
But for each of those standards, regulations, and frameworks, there are different ways to prove you've implemented them, and a different person, organisation, or regulatory body you'd have to show that proof to.
For instance, if you work for a health care organisation, you might have to show an auditor from the U.S. Health and Human Services Department that you're compliant with HIPAA; if you take credit card payments, you'd have to show the card companies that you've properly implemented PCI-DSS. And you can't just show an auditor from one of these bodies your HITRUST certification and send them on their way.
But because the HITRUST CSF incorporates the requirements from all these other bodies into its own ruleset, organisations that have done the work to become HITRUST certified have already done most of the work of meeting the requirements for the underlying framework, and the process of certification will have produced most of the documentation you need.
"Auditors can ask you any questions at any time," explains Aaron Zollman, CISO and VP, Implementations at healthcare financial technology start-up Cedar, who shepherded his company through two HITRUST audits.
"But the questions that they would ask you are going to read very similarly to the questions that HITRUST asked you. When they come in, they're going to ask you, 'In accordance with HIPAA security rule part 164.308, show me your compliance with section 308A1,' and you're going to say, 'What I'm going to do is I'm going to open my HITRUST book to section 00.a and I'm going to pull the evidence that I've already pulled for that.'
"You don't have to redo the work. You take the evidence you prepared for HITRUST and you give it to them in response to that audit."
As you might be able to tell from Zollman's description, other frameworks are incorporated into the HITRUST CSF by creating HITRUST rules that correspond to rules in other frameworks.
This process is called mapping and is the bulk of the work that goes into the creation and maintenance of the HITRUST CSF. For example, the Varonis blog gives some details on the HITRUST to NIST mappings that incorporate NIST's Critical Infrastructure Security Framework into the HITRUST CSF.
Another important thing to keep in mind is that, as we've noted, many of the underlying frameworks have similar or identical rules, which can be mapped onto a single HITRUST CSF rule.
So if, for instance, there's some rule on data handling found in identical form in both the HIPAA and PCI-DSS requirements, a HITRUST-certified company could implement the single corresponding HITRUST CSF rule and move a step closer to both HIPAA and PCI-DSS certification, without duplicating its efforts.
HITRUST controls and HITRUST requirements
As you might imagine, with all those underlying frameworks, the HITRUST CSF is fairly large and unwieldy. The PDF of the latest version clocks in at 548 pages. But not every organisation applies all those details in the same ways. To understand how this works, we need to define two important concepts: HITRUST controls and HITRUST requirements.
HITRUST rules are broken up into 19 high-level subject areas, known as control domains:
- Information Protection Program
- Endpoint Protection
- Portable Media Security
- Mobile Device Security
- Wireless Security
- Configuration Management
- Vulnerability Management
- Network Protection
- Transmission Protection
- Password Management
- Access Control
- Audit Logging & Monitoring
- Education, Training and Awareness
- Third Party Assurance
- Incident Management
- Business Continuity & Disaster Recovery
- Risk Management
- Physical & Environmental Security
- Data Protection & Privacy
Each control domain consists of a number of control objectives, which define broad cyber security goals, and each objective in turn consists of controls, which mandate specific tasks infosec staff needs to perform.
For example, in version 9.4 of the HITRUST CSF under the umbrella of the Information Protection Program domain is objective 01.02, "Authorized Access to Information Systems," which aims "to ensure authorised user accounts are registered, tracked, and periodically validated to prevent unauthorised access to information systems."
One of the controls that is part of this objective is 01.b, "User Registration," which requires that "there shall be a formal documented and implemented user registration and de-registration procedure for granting and revoking access."
The more granular and specific means the HITRUST CSF mandates for achieving the goals outlined in controls like these are called requirements.
Importantly, the HITRUST CSF, like many of its underlying frameworks, recognises that achieving a goal like the one laid out by the User Registration control will look different for organisations that are of different sizes and subject to different levels of risk. That's why each control has a number of requirement levels tailored to different kinds of organisations, with different requirements for each.
For instance, when it comes to the User Registration control, all organisations are subject to Level 1 requirements, which include the need to maintain a formal record of everyone registered to use a service, and to automatically remove or disable accounts that have been inactive for a period of 60 days or more.
Systems that are subject to banking regulations also need to meet Level 2 requirements; for instance, group, shared, or generic accounts and passwords are forbidden on such systems. Organisations that need to comply with FISMA regulations also need to meet Level 3 requirements, which require that a security token or biometric reader be used to authenticate users.
The process of becoming HITRUST certified begins with a detailed institutional self-assessment. This takes the form of a questionnaire that asks you about your organisation's size, risk exposure, and other factors. The answers to this questionnaire will determine which controls, which requirements, and which requirement levels you'll need to implement.
Who needs HITRUST certification?
As we've seen, HITRUST itself is not a government-mandated framework. Rather, it helps you more efficiently implement various frameworks that the government does require. So even though HITRUST is widely used in the U.S. health care industry, the Health and Human Services department doesn't require its use.
That said, HITRUST CSF has become a de facto industry standard in many cases. For instance, Cedar, the company Aaron Zollman works for, is in HIPAA jargon a "business associate," which means it doesn't directly provide patient services but does provide support services to organisations that do and handles personal health information for patients in the process.
"The providers we work with will often put in their contracts that we 'must have a HITRUST or equivalent third-party assessment against HIPAA and security principles,'" he says.
The core of the HITRUST certification process is the audit. Organisations seeking HITRUST certification hire a third-party auditor licensed by the HITRUST Alliance. This auditor begins with the data generated by your self-assessment and then dives into your security processes and controls in detail.
Zollman breaks down the process: "For Cedar, we're subject to HIPAA, we're of a certain size, and our architecture is primarily cloud-based," he explains. "We have a certain number of records over a given threshold, and so what HITRUST will do is say, 'Great, the number of controls that you have to attest to is 297.'
"Now, the auditor is then going to come in over a period of three months and check your environment, examining every one of those controls, line by line by line: 'Prove to me that you're doing this. Show me where it's documented on the policy. Show me how you verify it. Show me the last time you went through and verified it, and what evidence logs you created around that.'"
Zollman emphasises that this process should consist of more than just an auditor walking through a checklist.
"You want to develop a relationship with your auditor before you need the audit, because once they pull out the green pen, they're really formally auditing," he explains. "If a requirement statement is something like 'Passwords are a minimum of eight characters,' it's pretty easy to agree on what that means, but sometimes the statements are harder to understand—'The system evaluates risks at the network edge,' or something like that.
"Then you're going to have a conversation with your auditors like, 'We're in the cloud, but there's no more caching in this case.' It's important for you to develop a relationship with your auditor to have those conversations before the audit formally begins so that there are no surprises coming to the audit."
HITRUST certification cost
HITRUST certification is not cheap. In addition to a payment to your auditor, you'll need to pay the HITRUST Alliance directly to review your auditor's output, and there are various optional add-on tools and services the HITRUST Alliance will sell you as well, like a web portal for storing your audit evidence. Prices for all of this will vary depending on the size and complexity of your organisation.
The IS Partners blog estimates that prices can range from $50,000 to $200,000; Cloud City's blog thinks that small organisations might pay as "little" as $36,000, but acknowledges that fees can climb into six figures for many companies.
But while the sticker price may induce some shock, keep in mind that a HITRUST certification will get you most of the way towards compliance with multiple industry standards and government regulations. For many companies, it's an investment that's worth it.