How often should I conduct a HIPAA Security Risk Analysis?
There is no definitive answer for this as it depends on the level of risk in an organization, the potential impact of that risk and the overall criticality of the systems. It also depends on the overall complexity of the organization and network as well as the extent to which the network and systems are in flux. For example, a dynamic network environment may introduce risk into the system that would need to be evaluated more frequently. Furthermore , risk management is an ongoing process, so to a certain extent, while a complete risk analysis effort may only be conducted periodically, small areas of risk may be evaluated frequently – for example analyzing the risk in a critical server or newly deployed web application that accesses eHPI. However, as a rule of thumb most organizations will want to perform a formal HIPAA Security Risk Analysis as least once a year. Some of our customers insist on a consistent schedule of quarterly analysis.
How do I convey to management the ROI of a HIPAA Security Risk Analysis?
There are several ways to view ROI.
- Cost of breach: It’s impossible to estimate an exact up-front cost for a breach that has not yet occurred, yet most agree that the hard costs can be high. Of course, the cost of a breach is not only the hard costs of forensic analysis, credit reporting for customers, fines and attorney fees, but also the hidden costs. Brand damage is hard to calculate, but easy to comprehend. Another less known impact is the extent that a security breach turns into an organization-wide fire drill. All IT initiatives come to a halt. The board members may be involved, as well as many top executives, a legal team and of course the IT department.
- Cost savings: A risk analysis can often be leveraged as input into IT department resource allocation. A risk analysis really provides executive visibility in how the IT department is functioning. This is not only an essential governance function (how do you effectively manage an area that you don’t really understand and can’t internally validate the results of initiatives) but it also aligns management and IT department initiatives and focuses resource allocation to the most important initiatives.
- Maximizing value of current assets: Most organizations find that much of their risk is a function of external vendors or the internal systems those vendors support. In many instances that risk is due to a vendor that is not operating consistent with their contract terms, Business Associate Agreement (BAA), or service level agreement (SLA). An objective third-party analysis can provide tangible findings that can be forwarded to these vendors and leveraged into free fixes, additional features and future discounts.
What’s most overlooked during analysis?
In our experience, most healthcare organization risk is not from missing controls, rather from controls that exist but are not working as intended. What is most overlooked is a deep dive into the actual configuration and operation of controls to evaluate if they are really working. For example: most organizations have a DMZ (demilitarized zone) which is the name given to a network on which Internet facing servers are hosted to segregate them from the rest of the internal network in the event that they get compromised. A web server or email server are common examples. The idea is that these servers have to be accessible directly from the Internet to function, so they are vulnerable to direct attack from hackers. As such a safe approach is to put them on a DMZ: “hey, our web server got compromised, but at least the attacker was not able to access our entire internal network because the server was on a DMZ”. However, many DMZ’s that we evaluate are implemented with lax firewall rules such that if an Internet-facing server were compromised the entire internal network would actually be at risk. Meanwhile, because the organization thinks they have a true DMZ, those servers are not secured as well as they should. In this case, a DMZ actually gives you a false sense of security and increases your risk. Another scenario is when a healthcare network has a DMZ but firewall rules are added to the gateway firewall that route internet traffic directly to internal hosts. So rather than moving a server to the DMZ, this is a scenario where the DMZ is not actually used. In both these scenarios, I’ve heard a million times: “oh, we’re not worried about that – we have a DMZ.” The real question with a DMZ, as with all controls is, yes, but is it really working the way you think it is. This applies with any control, such as: encryption (but you are storing the encryption key along with the encrypted media), laptop encryption (but it does not activate because, say, an employee travels with the device in sleep mode and uses weak screen saver passwords)…. The list goes on and on, but the key point is that if you are not evaluating controls to really determining if they are really working effectively, then you are likely missing much of the critical risk – often the risk that is easy and cost-effective to address.
What do you find to be some of the hidden traps of HIPAA Security Risk Analysis?
Failure to understand that a risk analysis requires a methodology in which the IT environment is analyzed in the context of the entire IT ecosystem.. This includes the data (where is the ePHI?), the critical application and network components, the existing controls, the complexity of the network, data, systems and other components, as well as the particular threats and impacts. Failing to take a holistic an contextual view of the whole system will fail to provide a true view of risk and result in unnecessary, expensive and impractical findings that could have a negative impact on compliance and meaningful use initiatives.
This trap manifests itself into two primary scenarios:
- Automated tools: confusing running automated tools on a network for a risk analysis is a big trap. Automated tools generate huge lists of findings, many false positives and should not be confused with a risk analysis. The false positives make the IT department look bad and unnecessarily suck up resources as the IT team runs around and tries show that the findings are invalid. Further, automated tools have no context and even the valid findings from a tool are not necessarily relevant to a particular health IT environment. IT teams are already under-staffed and over-worked. A bunch of irrelevant findings just compound this.
- Check-box approach: A close cousin to the automated tools scan is the check-box approach to a risk analysis. In this case the analysts is likely not technical and cannot really validate if controls are working; DMZ “check” – Firewall: “check” – encryption: “check” – patch management system: “check”. A key problem with this approach is not only that it misses a big part of the risk, but also because it can yield very expensive recommendations. Consider this scenario: intrusion detection system (IDS) “missing” (forget that perhaps and IDS may not even be appropriate for this environment) – enterprise-wide data-loss prevention (DLP) system: “missing” , etc. The problem is that a check-box approach fails to consider that the HIPAA Security Rule is flexible and allows for controls as well as other compensating mitigation factors to impact what controls are in place and how they are leveraged. A check-box approach to a risk analysis misses easy-to-fix critical risk, while calling out expensive and unnecessary controls.
Both of these traps set you back in terms of managing IT resources (both budget and people) as well as achieving meaningful use and HIPAA Security Rule compliance.
What should and organization look for when selecting a HIPAA Security Risk Analysis vendor?
Several factors should be considered to avoid the traps and maximize value:
- Healthcare experts: A true risk analysis requires a contextual view of the specific risk in health IT environments, so its critical to go with a team that has extensive healthcare experience.
- Objectivity: One thing is clear – most of the security risk is a function of existing controls that are not working effectively. Don’t go with a vendor that sells hardware, software or offers to fix what they find. They will find new controls to sell you rather than configuration tweaks, operational workarounds or other mitigating factors that minimize risk while addressing compliance requirements. A risk analysis that is performed by a company that wants to sell you something else will likely make compliance harder to achieve, require expensive follow-up and always make you wonder if their judgement was clouded by an opportunity to upsell. Furthermore, in other industries we’ve seen risk analysis projects be deemed invalid by regulators that question the objectivity of analysis completed by a firm that has a role in IT deployments.
- Technical expertise: A team with strong technical capabilities are less likely to run automated tools or leverage a check-box list. You are looking for expert analysis.
Is there anything else you recommend an organization to do other than a HIPAA Security Risk Analysis?
Yes, a HIPAA Security Risk Analysis is a foundational component of any structured risk management program, but there are many related areas to consider on an ongoing basis, for example:
- Automated scanning: While we don’t consider the running of automated tools to take the place of a structured and methodical risk analysis, many of the tools available should be run periodically by IT staff as part of management of the network and systems.
- Validating controls: In general, IT teams (and management too) should take a skeptical view of controls. Periodically review them. This can be done by a third-party, but can also be achieved internally. Assume a control is not working and have someone take a critical look at it – preferably not the same person who is in charge of the configuration of the control.
- Security assessments: Other testing, which may or may not be a part of a HIPAA Security Risk Analysis can be conducted as needed. For example, web application security assessments, penetration testing, wireless system testing and social engineering are all modular and distinct test components that can identify risk in key areas of IT environments that are most at risk of ePHI data disclosure.