The "RISKY BUSINESS" Blog

The process of “realization” is an interesting one. 

My first thoughts on HITRUST tended towards the negative; “Why do we need another ISO-27001 derivative information security framework?” “Why not just get ISO-27001 certified?” “Is this going to be another pay-to-play framework like PCI that is more focused on generating revenue than it is on securing data?”  The latter concern was “enforced” by the HITRUST Alliance’s initial policy of only making the CSF available to those willing to pony up a couple of grand.

Fast forward a year plus and things are looking significantly different to me. 

 

• ISO-27001 holds tremendous promise as a form of third party attestation IF it is used right.  That is, it is important that the recipient of a 27001 certificate validates that the ISMS scope, the risks the ISMS scope considers, and the acceptable risk criteria established  align with the services being  utilized, the risks specific to the recipient of the certificate, and acceptable risk criteria established by the recipient. When considered in this context, I have come to see the “prescriptive” elements of HITRUST as being a “pre-definition” of the logical scope, risks, and risk acceptance criteria that are common to healthcare organizations.  So in a sense, the recipient of a HITRUST certification already knows that the scope, risks considered, and risk acceptance criteria are likely well aligned with their expectations. 
• There are some really smart people aligning themselves with HITRUST and it appears to be reaching a critical mass.  Should it hit its “tipping-point” it will move from “should we” to “we need”. 
• HITRUST has comported itself in a manner more consistent with being a trustable entity (think ISO or OWASP) than a non-trustable entity (think PCI).
• When you view HITRUST as ISO-27001 with a pre-defined scope, risk, and acceptable risk criteria the two “standards” don’t seem like an either/or proposition, rather they seem complementary in nature.  If I were a health care organization that would rather have an ISO-27001 certification – I would still choose to leverage the HITRUST CSF to simplify the process and benefit from the standards (e.g., HITECH, NIST, PCI) cross-mapping and the controls implementation guidance it provides.

So if you’re in the healthcare space and you are asking yourself which Information Security framework you should align yourself with … I would argue that there is no reason to make that decision.  By aligning yourself with HITRUST you are simultaneously aligning yourself with ISO-27001 at the same time. Hence, I think that we will soon start seeing healthcare entities with both certifications. 

Groundhog Day is one of my favorite films ... so perhaps it is no coincidence that I have had a string of introductory meetings over the last few weeks that made me feel a bit like Bill Murray.  It seems like many Information Security folks are feeling the same exact pain right now ... so I thought the email that I just sent may prove useful to more than its original recipient

Dear X,

At the close of our meeting you asked me to follow up with a proposal on how I think we (jointly) should approach your information security/information assurance requirements relating to (insert your relevant regulatory compliance issues here).  As you already know, I don't yet have enough knowledge of (insert your company name here) to answer that question definitively.  But "I'm not sure yet" is neither confidence inspiring nor all that useful.  So based on the four main ideas I took out of our meeting  (bullets below) I will lay out my best guess as to what our (joint) approach may be. 

PRIMARY CONCERNS:

• You have a growing demand to "prove" that you are compliant with relevant laws and regulations (most notably HIPAA/PII) which is challenging and time consuming.
• You have a relatively good security posture, although it lacks in documentation and formality.  This results in you feeling good about the 95% you "know", and nervous that the 5% you're not sure about is going to come back to bite you.
• The reason you are where you are, is that you have insufficient resources (time/training/manpower) to address security/assurance/attestation at a more "strategic" level.
• You are looking for a roadmap to confirm the 95%, address the 5%, and simplify the process of proving you are compliant with relevant laws and regulations to management and customers.

RISK-DRIVEN APPROACH
Our approach should be risk driven.  Fortunately, it does not seem as though there are any "urgent" risks that need to be addressed immediately,  which gives us greater flexibility in our approach.  Beginning with the end in mind is a fundamental tactic, so determining what the overall "target" is for our control environment is going to be helpful .  For now, I would restrict our efforts to the information security realm to ensure that we don't end up in a "boil the ocean" exercise (later we can look at integrating our information security controls into a larger Information Technology Control Framework like COBIT if it is warranted).   From an information security framework perspective, I'm a fan of ISO 27001 for a couple of reasons:

• It's proven: ~ 7,000 companies are already leveraging it, and ISO 17799 from which it is derived, has been in place over ten years and has been used by tens of thousands of organizations.
• It's an international standard that is "recognized" by everyone and is widely regarded as the de-facto standard by most.
  ISO 27001 has  been  "mapped" to HIPAA/PII and can be easily mapped to any new standard that you may need to comply with.  This simplifies proving compliance.
• It's certifiable (like ISO 9001) meaning that you can get those portions of your environment that are relevant to the handling of client data certified to be compliant with the standard by an independent entity.  This is the best possible form of attestation.

Alternatives include: a roll your own approach, the BITS Shared Assessment program (more financial services oriented) and HITRUST (purely Healthcare-centric).   I'm pretty confident that ISO 27001 would be the optimal approach for you.

PLANNING FOR ISO 27001
Assuming you agree, and you are not under any  short term requirement to be certified,  I would recommend a 1 - 2 year time target for certification.  You can try to do it faster (if necessary), but the controls in a strong control environment are highly interdependent and trying to move too far too fast often results in sub-optimal results.  Further, doing it faster would drive much of the work effort external to your organization and we have found that ensuring  your key folks are true stakeholders, is very important to long term project success.

Gaining Senior Management buy-in is also critical.  A 27001 Gap Assessment is the best way to get a sense of the work effort necessary to get to ISO 27001 certification and communicate the staffing/budget requirements for the same.  So a Gap Assessment would likely be the first activity relating to ISO 27001, and would provide a measure of where we are,  where we need to get to, and what it will take to do so.

MANAGING THE "INTERIM"
One challenge to the approach outlined is "proving" you are secure to customers/business partners in the interim (between now and ISO 27001 certification).  An approach that we usually (successfully) employ is to use a Vulnerability Assessment and Penetration Test (VA/PT) to "substantiate the net-effectiveness" of your current control environment.  In addition to being short term attestation, the VA/PT also provides valuable input into the ISO 27001 Gap Assessment (and longer term, the Risk Assessment that is integral to ISO 27001).  Where attestation requirements are a bit higher, we often supplement the VA/PT results with a Security Data Flow Diagram (SDFD) depicting key security treatments throughout your client's data-lifecycle.  The SDFD is also leveraged during the ISO 27001 Risk Assessment phase.

Please call me on my cell (732) 267-6324 when you have a few minutes to discuss this further.

 

PS: You might also want to check out our ISO 27001 Case Study and other ISO 27001 resources for further information! 

Call me jaded but my level of distrust goes up when an organization:

• Pronounces itself as the "Information Security" guardian of an industry segment
• Develops a "proprietary" framework/standard that it rationalizes based on the uniqueness of the industry
• Develops its own certification programs and charges exorbitant fees to qualify entities for certification

Perhaps I am just cynical based on our mutual experience with the  "Payment Card Industry Standards Council" and the PCI-DSS program which has only succeeded in reducing the risk to the payment brands at the expense of the merchants and the card owners. 

My lack of trust in all things PCI-related is well illustrated by the recent "gift card" I gave to my nephew for graduating high school.  He called me embarrassed to report that the card balance was zero and that the credit card company had told him that it had already been used.  After a considerable time on the line the credit card company finally "admitted" that the card had been used five days prior to my purchasing it.   If the credit card companies can't prevent/detect this proactively - what faith can we have in them or their ability to govern?

On learning of HITRUST I was hopeful that it would be different.  But on first blush it looks like they have stolen a page or two out of the Payment Card Industry Standards Council playbook.  For example,  the costs involved for a consulting/auditing firm to be "qualified" exceed $20,000.  Initially the standard was only available at a significant cost. On a more positive note, the Alliance recently announced that the Common Security Framework (the standard) will now available for free (however, after 30 minutes on the site today - I still can't find it).

Hopefully, I am wrong and HITRUST will be a shining beacon for Information Assurance - but I'm not so sure.  I would rather have a comprehensive, non-industry specific, standard (e.g., ISO-27001) achieve sufficient status that these entities don't feel the need to develop proprietary standards.  The benefits would be significant.