Web-Tones

Managing the number of Security Threats in the Wild?

The are literally hundreds of thousands, if not millions, of security threats ("Threats") in the wild. If you think this statement is hyperbolic then simply poke around IBM X-Force's site for awhile and judge for yourself. What does this have to do with a HIPAA Risk Assessment? Well, ah, everything. No organization, no matter how large, is capable of dealing effectively with this many Threats. The sheer magnitude of the problem is enough to cause analysis paralysis for the uninitiated.

Fortunately, we are not required to deal with the problem discretely at this scale. NIST's de facto Risk Assessment standard (NIST SP800-30 Rev.1 or "Standard") points to a possible (we think only) solution to the problem, and that is Threat Aggregation in the form of Risk Aggregation. The NIST Standard introduces Risk Aggregation as follows:

Organizations may use risk aggregation to roll up several discrete or lower-level risks into a more general or higher-level risk. Organizations may also use risk aggregation to efficiently manage the scope and scale of risk assessments involving multiple information systems and multiple mission/business processes with specified relationships and dependencies among those systems and processes.

OK, but what does this have to do with Threat Aggregation? The NIST Standard defines a Risk (R) as a function of a Threat/Vulnerability  ("T/V") pair (which must be unique) times (as in multiplication) the Impact (I) to your organization should this T actually exploit its corresponding V. The semantic meaning of a Risk encompasses a unique T/V pair. Here's where the Threat Aggregation can help.

Let's assume that we aggregate the hundreds of thousands of threat vectors that could potentially penetrate your network into a Threat that we will call "Social Engineering or Intrusion."  At some level of abstraction (i.e. from a remediation perspective) we are more concerned that the bad guys are "now in our network" then exactly how they got in. Ultimately, we will have to deal with the how, but for now we know that there is a complete set of mission critical controls that apply simply because they got in. These are foundational controls ("Controls"). There are a number of Security Rule Controls (i.e. implementation specifications) implicated simply by the fact that the "bad guys" are now in.

Do you want to comply with the Security Rule? Well then simply remediate (i.e. implement at a level that is "reasonable and appropriate") the twenty-nine Controls identified therein. That's it. If you have implemented the specified Controls then you are in compliance with the Security Rule by definition. It's at the same time that simple and that hard.

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

 

Intersection of a HIPAA Risk Assessment & Security Rule Controls

You may find this odd, I certainly did, that the Security Rule's implementation specifications are nothing more then "run of the mill security controls" just called by an odd & peculiar name. HHS has recently started referring to implementation specifications as controls. Why? Because that is the term of art used in security circles across industries for what the implementation specifications represent. It's definitely a case of a "rose by any other name" would smell as sweet. It turns out that there is a high degree of overlap between the Center for Internet Security's ("CIS") Top twenty Critical Security Controls and those controls that can be found in the Security Rule. This is what you would expect because at then end of the day the Security Rule is not about the implementation of super sophisticated controls, but rather about the implementation of foundational controls.

So what happens if you perform a Risk Assessment that does NOT implicate any of the 29 Security Rule Controls (i.e. both addressable and required)? Well it is certainly possible that a remediation plan that is promulgated as a result of said Risk Assessment does you some good, but (and it's a BIG BUT) you really haven't furthered your Security Compliance initiative. Why? Because the latter is ALL about implementing the controls found in the Security Rule.

Expresso pre-populates a customer instance with 150 Risks (threat / vulnerability / impact) pairs that include (i.e. attached to Risks) ALL 29 Security Rule Controls. That's why we can state that an RA can be done in three hours or less. Keeping in mind that the RA is a "pure analysis step" under the Rules. We force our customers to do the hard thinking around assigning probabilities and impacts to their organization for each Risk (only something they should do); BUT we completely eliminate the tediousness of matching T/V pairs. What happens is that the Expresso RA fast tracks them up the Security Rule's literacy curve, we believe, dramatically faster than they would otherwise (even if they had one of our competitors products).

Expresso is somewhat of a logical/mathematical "tautology." Because all the Security Rules' Controls (i.e. implementation specifications--both addressable and required) are implicated (often more than once) with respect to the Risks identified, then "ALL" the customer has to do is re-mediate where necessary, all the Controls identified in the RA. In other words, an Expresso RA is a teaching tool that is valid by definition with respect to identifying what you need to do to completely comply with the Security Rule. It takes the "mystery" out of the process. Fundamentally, ALL you have to do to comply with the Security Rule is implement all of its controls. Yeah, that's not trivial, but at least with Expresso you have a clear legal roadmap that works.

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

Comparing HIPAA Risk Assessment Software?

In the healthcare space there is no de jure standard for conducting a Risk Assessment; however, a de facto standard has emerged in the form of NIST SP800-30 Rev.1 ("Standard"). Surveys and questionnaires are pure "snake oil" when being sold as a substitute for the Standard. In order to circumvent any comparison to the Standard, vendors may use different words or complete disclaimers to describe a purported Risk Assessment offering. Said vendors may indeed provide offerings that help you in some way with your HIPAA compliance initiative ("HCI")-but the truth of the matter is that you can put "lipstick on a pig" but it's still a pig. Offerings that are too good to be true more often than not are just that. 

 

So what's a prospective buyer to do? You would assume that in the age where the Internet is our "go to" tool for conducting research, a relatively quick comparison between vendors offering HIPAA software would produce the kinds of comparisons you need to make an informed decision. That's the way it works for consumer electronics, most software, and millions of other products. However that is often not the way it works for HIPAA software.

 

Simply type "HIPAA risk assessment software" or "HIPAA software" into Google (or your favorite search engine) and you will get a pretty good list of vendors to start your search. We can almost guarantee (unless the marketplace completely changes in the next 2-3 weeks) that you will be disappointed by what you find. On most vendor websites you will have a hard time figuring out what their software does and, instead, what you will see is "contact us for a demo." Further, you will likely have an even harder time figuring out what the vendor's offering costs and, instead, what you get is "contact us for pricing."

 

Sign-up for our FREE newsletter below to read the entire article.

 

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

Does your HIPAA vendor's compliance methodology matter?

If you have hired a HIPAA consultant (or software vendor) to help you with your HIPAA compliance initiative ("HCI") then the following question is relevant legally for a number of varied reasons discussed below: "What is your HIPAA compliance methodology?" There are many ways that a vendor could interpret that question and so if you get that "deer in the headlights look" and you are sincerely looking for an answer (as opposed to a "gotcha") then you might reframe the question as follows: "How do you ensure that if I engage your services you will provide me a roadmap that leads to 100% coverage of the HIPAA requirements (i.e. Security Rule, Privacy Rule, and Breach Notification Rule)?"

Now if you still get that "deer in the headlights look" then you probably have the wrong vendor. Here's why it matters. The only way to comply with HIPAA is to comply with all of its requirements. Sure, this presupposes that the vendor you have selected has a baseline understanding of the requirements. Why would you hire a consultant for your HCI that did not posses said baseline understanding?

At one point, Phase I of the HHS audit protocol listed approximately 169 separate and distinct requirements. The counts were as follows:

1. 78 requirements for the HIPAA Privacy Rule;
2. 81 requirements for the HIPAA Security Rule; and
3. 10 requirements for the HIPAA Breach Notification Rule.

When Phase I of HHS' audit protocol was released it was like (for some) the agency had revealed some mysterious secret. In point of fact, ALL the Phase I protocol did was to enumerate (choosing to count in a particular way) the requirements that have been in the Rules since they were first promulgated and then modified by the Omnibus Rule.

We have always maintained that the only way to comply with HIPAA, or any other regulatory regime for that matter, was to comply at the granularity level of a requirement; anything else was "whistling Dixie" past the compliance graveyard.

Compliance with HIPAA is nuanced and potentially onerous but not necessarily so, at least not to the extent that the masses believe. It depends on how you approach it. Here are the three things you need to comply with each requirement of the HIPAA Rules:

1. Your policy regarding the requirement;
2. The processes that you intend or have implemented to underpin your policy (else the latter is nothing more than flowery language); and
3. The ability to track process results.

 policies + processes + tracking mechanisms = visible demonstrable evidence ("VDE") of compliance with a specific regulatory requirement.

In short, you have to satisfy the compliance equation for each requirement. If you have done that you can reasonably claim that you are in full compliance with HIPAA. If you haven't you can't make said claim. However, even if you are not currently in full compliance with all HIPAA requirements BUT you have a plan for achieving full compliance over time, you are still likely standing on solid legal ground (i.e. assuming that you have met some substantive subset of the requirements). Speaking of legal grounds, a technical consultant, no matter how well versed in the HIPAA Rules cannot, as a matter of law, give you a legal opinion as to your "state of compliance." Only lawyers have the prerogative of doing the latter.

HHS understands that your HCI is a work in progress. That said, HHS expects to see that you have an underlying rigorous methodology that underpins your HCI. You can't appear to be randomly and haphazardly throwing compliance darts hoping that a few hit their respective marks. You will never achieve a "culture of compliance" without a rigorous methodology underpinning your HCI.

So, the moral of this post is that methodology matters, a lot. If your HCI consultant cannot succinctly articulate their compliance methodology then that should raise some serious red flags. If the answer to your methodology question is that "our software takes care of all that" then you should run for cover quickly. Your HCI, while it undoubtedly contains a technical component, is mostly a people and process problem (i.e. an organizational problem). 

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

A Risk Assessment by any other name?

Risk Assessment (“RA”) software is a type of “process ware” that presumably encompasses an industry standard methodology for conducting RAs. In the healthcare space there is no de jure standard for conducting a RA; however, a de facto standard has emerged in the form NIST SP800-30 Rev.1 (“Standard”). NIST is the government agency responsible for providing, inter alia, cybersecurity advice to all U.S. government agencies and what it recommends is the aforementioned Standard. With respect to HIPAA, this Standard is only a recommendation and covered entities (“CEs”) and business associates (“BAs”) are free to choose their own methodologies for achieving the same objective. However, it would both misleading and misguided to suggest that CEs and BAs may select any arbitrary methodology as a substitute for the Standard. In short, the latter should be read between the lines and understood to mean that if OCR is recommending a particular Standard then any substitute that is as good as or better than the Standard is likely to meet the “reasonable and appropriate” requirement of the Security Rule, all others are likely to fall far short. So, for example, if you are buying the “snake oil” that questionnaires and surveys are a viable substitute for the Standard then you are likely to end up in “willful neglect” land. Caveat Emptor.

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

HIPAA & the FTC Act

OCR just released some interesting guidance. This is the first time that I recall OCR touching on the very nuanced intersection between HIPAA and the FTC Act. Essentially, the gist of the guidance is that covered entities (and business associates) have to worry about both. This is especially true as more and more covered entities create patient portals and otherwise leverage the Cloud. Legally, reading between the lines, the message is that the healthcare industry has to worry not only about protected health information (PHI) but also about personally identifiable information (PII) under the FTC Act Section Five. Here's the $$ quote:

Does your organization collect and share consumer health information? When it comes to privacy, you’ve probably thought about the Health Insurance Portability and Accountability Act (HIPAA). But did you know that you also need to comply with the Federal Trade Commission (FTC) Act? This means if you share health information, it’s not enough to simply consider the HIPAA Privacy Rule. You also must make sure your disclosure statements are not deceptive under the FTC Act.

You can find the entire guidance here. This guidance, unlike others instances where HHS has caused more confusion than clarity, is surprisingly succinct and directly on point. It does an excellent job of illustrating the nuanced difference between HIPAA and the FTC Act. 

Looking for a simplified way to train your staff on HIPAA Breach Notification?  For a limited time, we are offering our Breach Notification Training Module F*R*E*E* when you sign up for our monthly newsletter (also free).  Go here to get your free training now! Want to learn more about Expresso, the Risk Assessment Express, click here.

Understanding Expresso?

Download 20161017_HHS_Risk_Analysis_Guidance

If you want to understand what Expresso does then a good starting point is HHS' recent guidance regarding how to conduct a Risk Assessment. This guidance borrows from NIST SP800-30 R1. Expresso abstracts the entirety of NIST's recommended methodology meeting all the requirements as identified in HHS' guidance. Notice that the NIST methodology speaks of Threats, Vulnerabilities, and Risks as specific terms of art that are used to "calculate" the latter.

Although HHS leaves the door open for other methodologies there is a LOT of "snake oil" currently being sold equating surveys and questionnaires with a valid Risk Assessment. If you are going to substitute this nonsense then be prepared to defend it should you be audited, or worse yet, should you have a significant breach. Many of these "substitute approaches" are being sold by technology consultants who may be knowledgeable about the Rules, but who in no way can give you a legal opinion as to whether your selected (often lightweight, arbitrary, and trivial) approach is sufficient to legally satisfy HIPAA.

If in fact said consultants provide legal advice then they are engaged in the unauthorized practice of law.  In short, having a professional opinion as to whether or not you are in compliance is the purview of lawyers as a matter of law. Expresso was designed by lawyers that have a deep understanding of the Rules and the corresponding technology that can guide your compliance initiative in a sure footed manner.

A public demo of Expresso with Q&A can be found here.

This is not to say that there are not some super qualified HIPAA consultants whose value proposition most covered entities and business associates would benefit from. There are. Many of them have been involved in the HIPAA conversation with us for many years now. BUT they are ones that are knowledgeable enough to understand the difference between technical advice and legal advice.