February 16, 2016

Last Updated on January 12, 2024

PPS is really starting to feel the impact of the June 2015 HITRUST Alliance pronouncement that a number of key healthcare organizations—including  Anthem, Health Care Services Corp., Highmark, Humana, and UnitedHealth Group—would be requiring their business associates (vendors) to obtain CSF certification. Prior to the last few months, HITRUST was only an occasional topic as most (potential) client conversations centered on the more widely leveraged third-party attestation programs like ISO 27001, SOC2, FedRAMP and Shared Assessments.  But recently the pendulum has swung to where HITRUST is a very frequent topic. While the fundamental process (Scope, Risk Assessment, Gap Assessment, Gap Remediation, Operate/Monitor, Audit, Certify) of building an Information Security Management System (ISMS) largely applies across all information security and attestation frameworks, there is an interesting element of HITRUST that makes it (and our client conversations about it) a bit different: MyCSF.
MyCSF (based on RSAM) is a governance, risk management, and compliance (GRC) tool whose use is integral to the HITRUST program. At a minimum, an organization looking to leverage the HITRUST program for self-assessment, validation, or certification is required to use MyCSF to initiate the process and to conduct its initial risk assessment. This initial risk assessment is done via a questionnaire that to some extent combines scoping, risk assessment, and control enumeration functionality. The output of the risk assessment is a listing of which of the 149 HITRUSCT CSF controls are applicable (required), as well as the required risk treatment level (a 1-to-3 scale) for each control. It should be noted that the applicable controls will never be less than the 64 baseline controls that HITRUST mandates. What we have seen is that we are typically being engaged as a consultant at one of two points in the process: 1) At the project’s onset; or 2) After the client conducts the MyCSF Self Assessment.
In the former case, we are usually being engaged at the requirements onset and helping the organization understand the pros and cons of different attestation (e.g., HITRUST, ISO 27001, SOC2) approaches and/or the potential of pursuing multiple attestation now and/or in the future. In the latter case, the organization has gotten through the Self Assessment and risk analysis and is either not fully confident in the way they used the tool and/or they’re not sure they have the expertise/bandwidth to complete the project without some outside support in the required timeframe.
Engaging a consultant after completing the MyCSF Self Assessment seems like the logical approach. In essence, you now have a Risk Treatment Plan that you and the consulting firm can work on collaboratively.  The challenge with this approach is that the quality and accuracy of the Risk Treatment Plan is fully predicated on the quality and accuracy of the HITRUST Scope and the Risk Assessment.
The MYCSF Risk Treatment Plan is like a ladder against a wall, which you and the consulting firm can climb. But if the consulting firm was not privy to the initial scoping/MyCSF assessment they can’t tell you for sure that it’s the right wall. That’s because they don’t have the right understanding of your business and the HITRUST/ISMS scope.
We just started working on a project where we were engaged after the MyCSF Self Assessment. In order to minimize the “right ladder/wrong wall” risk, Pivot Point Security is working with the client to establish the data flow diagrams that are called for at multiple points in the HITRUST CSF (V7). This is one of our favorite approaches for establishing the scope of an ISMS. By understanding the flow of sensitive (in-scope) data from ingress through egress, and understanding the key processes that act on it, you become rapidly contextualized to the business, the assets (people, systems, applications, networks, facilities) that support the processes, the inherent risks in the processes, key control treatments that currently (don’t) exist, internal challenges, external influences like customer contracts and cyber liability insurance policies, texts, as well as relevant and the laws/regulations that shape the scope and downstream risk management decisions.
So in this case, the data flows will give us enough insight into the scope and risk assessment to determine if the Risk Treatment Plan ladder is against the right wall; and, if not, we can circle back and address it.
I’m looking forward to doing more work with HITRUST as I’m intrigued to see how well the mandated risk assessment process and the prescriptive risk/risk treatment that HITRUST has overlaid on ISO 27001 works.