Comply with HIPAA

Software Associates helps medical device and healthcare technology vendors achieve compliance with the HIPAA Security Rule using a unique 6 step business threat analysis methodology. This unique program helps accelerate your security and compliance activities and reduce time and cost to provable HIPAA compliance.

The objectives of threat modeling

The objective of a threat modeling process is to understand the security issues, how  they  impact the organization, and the most cost-effective way of mitigating attacks; whether they are threats from viruses and phishing attacks, disclosure of PHI in social media or theft of intellectual property related to design and implementation of a medical device.

Why  is threat modeling relevant for HIPAA compliance?

Putting it simply – if you have 1 dollar to spend on compliance you have to spend it in the right way. That means identifying the top threats in the physical, software and operational areas and implementing the right controls for HIPAA compliance.

Threat modeling excels in analyzing complex operational, software and hardware systems that integrate disparate infrastructures and technologies – an integrated system of Windows client operating systems, Java GUI, message queuing, Linux servers and open source databases such as MySQL is not an unusual example.

Threat analysis is valuable in identifying systems integration vulnerabilities, for example when  integrating your product with hospital EHR (electronic healthcare record) systems.

In new medical device development, from a software security and compliance perspective, threat analysis is best used throughout the entire SDLC (Software development life cycle) starting with the design – which typically accounts for 50% of the security vulnerabilities.

The problem: Can you afford do do it on the cheap?

The cost of implementing security countermeasures in working code or integrated systems is high. There is often a temptation to look for DIY or bolt-on patches, leaving design and implementation defects in place. HIPAA requires a top-down risk analysis; threat analysis enables us to pinpoint the “hot” areas of risk and implement the most cost-effective security countermeasures. And yes – you may have to change platform and rewrite code.

The solution: Keep it simple

With business threat analysis, application domain experts can quickly build and analyze threat models and policies without endangering the project schedule and deliverables. Knowledge is retained, shared and maintained within the group and program management has total transparency to system risk without the need for additional resources.

A security audit / risk assessment can be performed in days by a small team instead of weeks by large forces of outside consultants using pre-built checklists.

What are your alternatives?

Word and Excel

The analyst has the freedom to describe threats and vulnerabilities and express her analytical qualification in a free format with no restrictions dictated by the tool. However, the overhead of the data management and the calculation tasks is very high because of the lack of a built-in ability to represent the interrelations between entities and to dynamically alter the threat model. In reality the data model required for threat modeling is far beyond the capabilities of spreadsheet programs. In addition, most of these solutions also lack the necessary reporting functionality.


There are predefined sets of HIPAA security recommendations available on the Internet or from a compliance consultant. This approach may work for standard applications where all possible security issues are known in advance. The odds of that happening are rather low.   You are better off flipping a coin.

Using Business Threat Analysis for HIPAA compliance

The Software Associates 6 step process for business threat analysis uses the Practical Threat Analysis (PTA) data model and quantitative risk assessment methods. The process provides an easy way to maintain dynamic threat models that are capable of reacting to changes in regulation, environment and product.

By providing estimated asset values, using the threat model we can calculate Value at Risk and provide decision makers with a prioritized list of HIPAA security controls. Control priorities are expressed as a function of asset values, estimated damage in the case of an attack, threat probability and the degree of mitigation provided by the controls.

We recommend that  medical device vendor software teams adopt threat modeling practices from day one of design and throughout the system development life cycle.  The threat model provides intuitive and easy ways for iterative interaction between threat analysts and developers. It supports a collaborative process of evaluating threats risks and ranking the cost-effectiveness of proposed countermeasures. The team’s “threat analyst” can be the program/product manager, system architect or development lead who can start being productive with the CASE tool within hours.

How does threat analysis specifically relate to HIPAA?

HIPAA requires a top-down risk analysis and mandates adopting the right controls to minimize unauthorized disclosure of PHI assets. CFR 45 Appendix A (the HIPAA Security rule)  prescribes a set of  controls(security countermeasures) in the administrative, technical and physical domains without analyzing the underlying vulnerabilities or considering asset value.

By analyzing the impact of threats that exploit human and technical  vulnerabilities,  medical device vendors can understand precisely where and how to invest in controls in order to best protect the HIPAA covered entities that are their customers.

Defining a common terminology and process for threat modeling and analysis

In this section, we define a number of fundamental concepts in order to help the reader to easily understand the threat modeling and quantitative risk calculations.

Vulnerability is a weakness, limitation or a defect in one or more of the system’s elements that can be exploited to disrupt the normal functionality of the system. The weakness or defect may be either in specific areas of the system, its layout, its users, operators, and/or in its associated regulations, operational and business procedures.

Countermeasure is a procedure, action or mean for mitigating a specific vulnerability. A specific countermeasure may mitigate several different vulnerabilities. In some standards documentation, countermeasures are called “controls” or “safeguards”.

Asset is information, capability, an advantage, a feature, a financial or a technical resource that may be damaged lost or disrupted. The damage to an asset may affect the normal functionality of the system as well as of the individuals and/or organizations involved with the system.

Threat is a specific scenario of a sequence of actions that exploits a set of vulnerabilities and may cause damage to one or more of the system’s assets.

PTA Data model

Asset’s Value is the financial value of an asset that is destroyed of stolen. Assets may be digital (software source, physical (a server) or commercial (a corporate brand).

Threat’s Damage to Asset – financial value of damage caused by a specific threat to a specific asset.

Threat’s Probability is the likelihood that the threat scenario will materialize. In some documentation the threat’s probability is characterized by the term “Annual Occurrence Rate” (AOR).

Threat’s Risk is a quantified measure of the likelihood of loss and/or damage that may be caused to one or more of the system’s assets due to the specific threat. In some documentation the threat’s risk is called “Annual Loss Expectancy” (ALE).

Threat’s Recommended Countermeasures is a set of all the possible countermeasures that reduce the threat’s risk. This set is based on the countermeasures that mitigate the threat’s vulnerabilities.

Threat’s Actual Countermeasures (AKA Threat’s Mitigation Plan) is a subset of threat’s recommended countermeasures that is assumed to be the most effective for mitigating a specific threat. The decision which of the recommended countermeasures will be included in the Threat’s Mitigation Plan is made by the analyst, who uses his expertise to decide which countermeasures are most effective when applied together.

Countermeasure’s Cost is the financial value that is associated with the implementation of a specific countermeasure.

Countermeasure Cost-Effectiveness is the degree of mitigation introduced by a specific countermeasure to the overall risk in the system in relation with the cost of implementing this specific countermeasure.

Additional Terms

Attacker is a person (or group of persons) that may perform the steps of a specific threat scenario.

Attacker Types are the various classes of attackers that are differentiated according to their motivation, qualification, available attack tools and their accessibility to the attacked system’s resources.

Entry Points are the “doors”, either in the system itself or in the human operation associated with it, that are used by attackers to penetrate the system, e.g. Web site, IVR service, SMS server, CRM representatives called by customers over the phone etc.

Area Tags are descriptive tags that are relevant to assets, threats, vulnerabilities and countermeasures. Classifying the various security entities in the threat model according to their areas improves the readability of complex threat models.

HIPAA compliance project steps

1. Before starting a HIPAA compliance project

As mentioned previously, the threat analyst identifies system vulnerabilities, predicts even the most hypothetical threat scenarios and evaluates threat probability and risk to enable prioritizing the corresponding countermeasures.

Before starting out, the analyst should learn the system functionality and architecture. The in-depth understanding of the system is of crucial importance for the correct identification of system vulnerabilities and the building of possible threat scenarios. The following documentation is needed.

  • Functional description of the system including all typical use cases
  • Architectural diagram of the system
  • Documentation for various system modules

These documents must be detailed enough to be used as reference for the decisions regarding the applicability of various threat scenarios to the analyzed system.

2. Tagging areas in the system

Relevant tags on different sub-modules or activities of the system help the analyst in mapping the various entities according to a variety of properties e.g. define area tags for each of the systems components that will enable the association of vulnerabilities with system’s architecture areas

3. Identifying assets

The correct mapping of assets, their financial value and the evaluation of financial loss to the system owner when these assets are damaged or stolen, is one of the most critical tasks in the threat analysis process. The assets value is used as the basis for calculating threat risks and countermeasures priorities.

We often hear claims like “everything we have is important“. While this could be true for some systems, we believe it is not the typical case. It is more likely that assets need to be clearly prioritized. Consider, for example the following partial list of  assets owned a healthcare provider who is a HIPAA covered entity using an innovative medical device for treating ischemic strokes using deep brain stimulation.

  • Windows file and print servers
  • Treatment plans for using the device
  • Cost of treatment
  • The patients EHR (electronic health records)
  • Private keys used for encrypting PHI
  • Master key used for generating private keys

The accurate assessment of the financial value of the damage that may be caused by losing each of the above assets will enable the correct classification of assets according to their importance to the institution and help avoid a situation where the institution invests resources in protecting Windows file and print servers while leaving PHI and EHR unprotected.

In some cases the value of assets is less intuitive especially when they are intangible. For example, the confidence of the public in an innovative medical device may be damaged by attackers who deface the Web site of the medical device vendor. While there is no direct financial lost and no information is disclosed, the trust of customers may be shaken in the vendors ability to protect PHI if they cannot even protect their own Web site.

Due to the importance of asset mapping, we recommend that the asset list and corresponding values be periodically checked by non IT personnel e.g. the company’s CFO, marketing officers and legal consultants. An analysts can quickly do “what-if” analysis by modifying asset values and obtain insight as o the model’s accuracy and completeness.

In practice, it is often easier for the analyst to identify system assets via the process of analyzing specific threats (as described in step 8). It is a fact of human nature that we don’t realize how valuable things are until we lose them. This implies an iterative approach of mapping assets and threats.

4. Identifying the real vulnerabilities

Identifying vulnerabilities requires the analyst to be intimate with the medical device functionality, architecture, implementation and deployment details. The analyst should also be familiar with business and operational procedures and the types of users and other parties that are involved in system operation.

In our experience, analysts often use Google to find generally known vulnerabilities as published by software vendors and security consultants. Most of the items in these check lists are, in many cases, irrelevant to the specific system or may be easily solved by a simple comprehensive routine such as “always install most updated vendor’s security patches”. The thing that should concern us here is that such a list may draw the attention of the analyst away from the real vulnerabilities that are specific to the system that is being analyzed.

We highly recommend a thorough investigation of the medical device system architecture and implementation details working with architects, developers, installers and support engineers as well as with the business managers of the system to discover the real vulnerabilities that are unique to the system and that probably may not be identified without this intimate knowledge. From experience – the most severe vulnerabilities reside in the interfaces between the various elements in complex systems and rarely appear in the standard compliance check lists.

As mentioned before, the identification of the relevant vulnerabilities is a continuous iterative task that is associated with the step of identifying threats (step 8 below) – sophisticated vulnerabilities may be identified when building threat scenarios.

5. Identifying security countermeasures

Identifying countermeasures has two outputs:

  • A list of countermeasures that protect vulnerabilities. The list includes the implementation cost of each countermeasure and the countermeasure’s relevant area tags. If the countermeasure is already applied it should be marked as ‘already implemented’ to enable producing updated statistics of the total risk level in the system.
  • A map of the relationships between countermeasures and vulnerabilities. This map shows which vulnerability may be mitigated by a specific countermeasure. Sometimes a countermeasure is introduced as a solution to a specific vulnerability, but after additional consideration it turns out that it may help in mitigating other vulnerabilities too.

The accurate identification of countermeasures and their relations with vulnerabilities is the basis for building risk mitigation plans as described in the next steps.

6. Classifying attacker Types

Classification of the relevant attacker types may be helpful in focusing the analysis on practical realities. The classification of attackers is useful when we can clearly relate each of the threats with one or more of the attacker types.

Attacker type’s data includes the understanding of his motivation as well as his qualification, available attack tools and his accessibility to the system’s resources. Special care should be given to classification of ‘insiders’ attacker types since their activity may be very dangerous.

A good starting point may be to define an attacker type for each of the user roles that appear in the system use cases and reserve few more attacker types to hackers and other types of bandits.

7. Identifying attacker entry points

The best tactic for this step is to review the list of attacker types and document every possible way the potential attackers could access the system. List of entry points may be revisited and clarified while analyzing threats.

8. Building threat scenarios and mitigation plans

This is the most important step of the threat analysis process. The outcomes are:

A list of system’s threats

  • A map of the relationships between threats and area tags, assets, attacker types, entry points and vulnerabilities
  • An evaluation of the total damage and risk parameters for each of the threats
  • Mitigation plans and residual system’s risk data

Since threats are the most complex entities in the model, the process of identifying and constructing threat’s elements and parameters has a ‘decomposition’ flavor. During this process the analyst will have to return to previous analysis steps in order to create missing entities, such as assets and vulnerabilities that are referenced by the threat that is constructed. In the following we describe the sub-steps of building a threat scenario and a mitigation plan for a single threat.

9. The output of the HIPAA compliance process

The HIPAA risk analysis process provides a number of reports and management level information

  • List of system’s threats sorted by their risk
  • List of system’s threats sorted by the financial damage they cause
  • List of individual countermeasures sorted by their overall risk mitigation effect
  • List of countermeasures sorted by their cost effectiveness (mitigation divided by implementation cost)
  • Maximal financial risk caused to each asset by existing threats
  • Maximal financial risk caused to each asset by existing threats after all mitigation plans are implemented
  • Maximal financial risk caused to each asset by existing threats after partial implementation of mitigation plans (use the ‘already implemented’ flag in countermeasures)
  • Total financial risk including all assets
  • Total financial risk after all mitigation plans are implemented
  • Total financial risk after partial implementation of mitigation plans

Reviewing these results with the client management helps refine the threat model. Using the threat model, enables the client to run “what-if” scenarios without changing hardware/software/operational procedures and deepen management understanding of the company’s risk profile.

Tell your friends and colleagues about us. Thanks!
Share this