A Model for HIPPA Security Policy Deployment

1

A Model for HIPPA Security Policy Deployment

Can the cost of HIPAA security compliance be quantified?

Introduction

This research examines the issues related to the cost of compliance for the HIPAA security regulation. The cost to comply, while relevant to any organization affected by this ruling, was slightly neglected by the legislature as the rule was being drafted. Quite simply, the rule provides no insight into the costs associated with complying with its statutes. This leads the authors to focus on several questions concerning this issue. First, is there a method for quantifying the risk of not being compliant with the HIPAA security rule, and is there a way to indicate what risk a health organization inherits by ignoring their responsibilities to this rule? Second, based on the quantified risk for a specific organization, is there any method, model, or equation that can be utilized to calculate a reasonable IT security budget earmarked for this effort? Finally, given a budget, is there a model or procedure for dispersing this monetary resource in the most effective and constructive manner? These questions provide the context from which the authors approached this paper. It is divided into three parts. The first part provides a concise introduction to the HIPAA security rule. The second part introduces a model for estimating the cost of not properly complying with the HIPAA security rule. The third part discusses our Policy Deployment Model for Minimum HIPPA Security.

Part I - The HIPAA Final Security Rule

The Health Insurance Portability and Accountability Act (HIPAA), passed in 1996 by the Senate and House of Representatives, charged the Department of Health and Human Services (HHS) with the implementation and enforcement of its measures.[1] The purpose, as originally drafted, had four primary objectives: To assure health insurance portability by eliminating job lock due to pre-existing medical conditions; to reduce healthcare fraud and abuse; to enforce standards for health information; and finally, to guarantee security and privacy of health information.[2]

As articulated by Blue Cross Blue Shield:

“The Health Insurance Portability and Accountability Act of 1996 is intended to reduce the costs and administrative burdens of health care by making possible the standardized, electronic transmission of many administrative and financial transactions that are currently carried out manually on paper.”[3]

Because the scope of the HIPAA rules are so broad and comprehensive, the focus of this paper is limited to the final security rule, published by the Department of Health and Human Services on February 20th, 2003. The final security rule mandates that all covered entities provide confidentiality, integrity, and availability of all electronic protected health information (EPHI) that is collected, maintained, used, or transmitted.[4] A covered entity is defined as a health plan, a healthcare clearinghouse, or a healthcare provider that stores or transmits EPHI.[5]

The security rules were written to adhere to three basic tenets. Each tenet focuses on providing a regulatory architecture that can be applied to entities of any size. The regulation must be comprehensive, scalable, and technology neutral.[6] To achieve these three principals, the rule was written more as a set of generally enforceable guidelines, intended to require each covered entity to interpret how this rule should apply to their own best security controls.

Because of its tone, these general statutes lack a level of granularity, which would help guide organizations on how to implement them. Each security standard is broken down into required and addressable implementation specifications. Covered entities must implement required specifications and have a choice to implement the addressable specifications.[7] “The entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework.”[8]

The regulation declares four actions that a covered entity may take for addressing the implementation specifications: (1) implement one or more of the addressable implementation specifications; (2) implement one or more alternative security measures; (3) implement a combination of both; or (4) not implement either an addressable implementation specification or an alternative security measure.[9]

The focus of this paper addresses how to determine, based off of risk, how much in resources should be spent, to comply with these rules. The nature of the rule requires that each covered entity acknowledge that the rules must be addressed, but leaves great freedom as to how to address them. This situation calls for some type of decision matrix and risk analysis model that would help guide organizations on how their particular entity should account for these rules from both a risk perspective and from a policy deployment perspective. It is the intent of the authors to articulate that by combining both methods, an organization is given a greater understanding of how they should act and spend money towards compliance with these rules. The following sections provide two models, that when used together, provide a clear way of addressing these problems.

Part II - A Model for Estimating the Cost of Non-Compliance of HIPAA Security

A major hindrance overshadowing the issue of network security, and more specifically HIPPA security, is convincing executives that securing their networks is a prudent and necessary investment. A 1999 Information Security Magazine Survey indicates that 69% of respondents feel that the greatest obstacle towards better network security lies with senior management.[10] “One of the biggest challenges is getting senior management to take the problem seriously, and to commit resources to it.”[11]

More recently, executives have focused an increasing amount of attention on the issue due to recent regulation. Another study encompassing 7,500 senior information technology executives, found that 62 percent of these companies will increase spending on security for 2003, compared to 50 percent in 2002.[12] Roughly two-thirds of those polled said they adopted security measures to limit liability, and almost half said it was to comply with regulations such as Sarbanes-Oxley and HIPAA.[13] Legal and regulatory requirements for data integrity/confidentiality and consumer privacy are seen as the most compelling arguments for a strong security program.[14] But even with this new found compliance, it seems that few executives truly understand how their efforts, and dollars, will pay off.

Management cannot draw a clear connection between the dollars spent on securing and fortifying networks, and the intrinsic return on this type of investment. Given that many executives focus undying attention to the bottom line; their aversion to this type of investment is understandable. Network security is viewed today, as fire sprinklers were viewed a century ago; a waste of money. In 1882, sprinklers were considered to be as dubious an investment as information security is today. CEOs and CFOs want to see quantifiable proof of their return on investment before they outlay any funds.[15] In some ways, their argument is as sound as the one supporting network security.

However, the number of successful security breaches continues to rise.[16] For example, the number of verifiable worldwide hacker incidents for the month of January 2003 is about 20,000, which far exceeds the previous record of 16,000 set in October of 2002.[17] According to the Computer Security Institute’s Computer Crime and Security 2003 Survey, 80 percent of the respondents acknowledged financial losses to computer breaches with each intrusion averaging in the millions of dollars.[18]

Even with the potential for the tremendous financial losses illustrated in the previous paragraph, there is still no complete model designed to suggest and justify how much money should be spent to help negate these risks. “Lacking any way to translate such statistics into expenditures and losses per organization, per computer, or per user, the true impact of these figures remains uncertain.”[19]

In 1882, a man named George Parmalee set a Bolton, England, cotton factory on fire to help sell his newly invented sprinkler system.[20] His intention was to convince the factory owner that while the probability of fires may be remote, the damage incurred from just one incident could be devastating; and that any investment aimed at deterring such an event was well worth it. While the approach introduced in this paper excludes the utilization of any combustible devices, some of the underlying concepts remain similar to what George Parmalee tried in the late 1800s. This model intends to articulate what costs and liability factors are presented to CIOs who do not take HIPAA compliance seriously. The authors call this model, the “Cost of Non-Compliance HIPAA Security Model”. The specifics of this model are detailed below.

Explanation of the Model

”Hand in hand with the increase in awareness of the need for computer security has come the need for a method of quantifying the impact of potential threats on organizations.”

The underlying framework of this model is centered on a general risk analysis. Risk analysis is defined as: The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. It is a tool used as part of any risk management system and is synonymous with risk assessment.[21] The first major publication addressing the topic of risk analysis,[22] was the Federal Information Processing Standards (FIPS) Publication Number 65.[23] Published in August of 1979, the FIPS Publication became the de facto standard from which all subsequently published Risk Assessment methodologies are compared. The end results of the FIPS risk analysis model are annual loss exposure values based on estimated costs and recognized potential losses.[24]

Since the publication of the 1979 FIPS model, there have been various other approaches and models designed to attack this issue from alternate angles. The FIPS model uses a quantitative approach, while other, newer models, use a qualitative approach for ease of preparation and speed of execution.[25] It was felt by some security experts that the quantitative approach was too complicated and time consuming to implement on a mass scale, and sought out to find an easier approach to implement. This resulted in the creation of several new qualitative approaches. The authors identify two of these methods. The first was a replacement to the FIPS 65 publication, released in 2001, and titled “Risk Management Guide for Information Technology Systems”. The second is the Facilitated Risk Analysis Process (FRAP).

The authors chose, for this paper, a model created by Rita C. Summers, which is based on the original FIPS 65 framework. This model provides the underlying architecture for the cost model discussed in this paper.[26] Summers’ model proposes a simple four step method towards risk analysis. First, identify an organization’s assets that could possibly be compromised by security breaches, and assign monetary values to them. Second, identify the threats and the vulnerabilities faced by this organization. Third, calculate the annual loss expectancy (ALE) for each threat. Finally, identify potential safeguards and estimate how much each one would help reduce exposures.[27]

The Cost of Non-Compliance HIPAA Security Model uses the first three steps that Summers proposes as its foundation, but replaces the fourth step with an alternate approach. Instead of analyzing how different safeguards will help reduce exposure, the authors are interested in using this model for a different kind of output. As the title suggests, the output provided by the fourth step of this model will articulate how much could be lost by a particular organization, if investments are not made to help secure a given network for HIPAA compliance. Therefore, this model’s final step quantifies the risk of doing nothing to influence executives to spend the appropriate dollars towards this effort. The next several paragraphs will describe each step in greater detail.

Step I - Identify Assets

“The Task of identifying assets that need to be protected is a less glamorous aspect of information security. But unless we know these assets, their locations and value, how are we going to decide the amount of time, effort or money that we should spend on securing the assets?”[28]

The first step to identifying assets attempts to answer the question, “what are a given organization’s critical assets?” In other words, which assets are critical and essential for the day to day operation of the business and which help maintain the businesses long term viability? Once these assets are identified, they then must be classified into distinct categories. This paper classifies all assets into one of five categories; Network Assets; Software Assets; Equipment Assets; Data/Information; and Other.[29] The organization’s identified tangible and intangible assets such as software, information, and personnel would be placed into their appropriate categories.[30] Appendix A provides a comprehensive diagram with a hypothetical organization’s assets identified and classified into their respective categories. Once identified, all assets then need to be assigned an estimate of their intrinsic value. “The value of an asset consists of its intrinsic value and the near-term impacts and long-term consequences of its compromise.”[31]

In reference to the scope of this model, it should be noted that a covered entity is only responsible for those assets that are under their direct ownership. Other property that can be placed on the balance sheet as assets, but are rented or obtained through some sort of partnership, such as any off premise networks, or leased business machines, do not need to be included for this analysis. Finally, while business partners whom the covered entity shares Personal Health Information (PHI) with, are not included in this assessment, their compliance with the HIPAA standards is still mandatory.[32]

Step II - Identify Threats and Vulnerabilities

Once the critical assets of a particular organization have been identified and values have been associated to them, a comprehensive list of threats and vulnerabilities for each asset must be identified. A threat is an entity or event with the potential to harm the system. Threats come in many forms, but typical ones may be: simple or hidden errors, fraud, disgruntled employees, hackers, or viruses.[33] “Threats should be identified and analyzed to determine the likelihood of their occurrence and their potential to harm assets.”[34] Table B.1 provides a more comprehensive list of threats.

Step III - Calculate Annualized Loss Expectancy

After the list of the threats and vulnerabilities has been compiled, the next step is the calculation of the annual loss expectancy. The annualized loss expectancy equation is:[35]

Figure 2.1

“Exposure factor is the measure of damage, harm, or loss resulting from a threat or event usually expressed as a percent (0%-100%).”[36] Exposure factor is the value lost from the threat in relation to a specific asset. Figure C.2 provides a comprehensive list of exposure factors. The annualized rate of occurrence estimates how often a threat might be expected to occur, expressed on an annualized basis (e.g., a threat that is expected to occur once every ten years would have a threat frequency of one tenth or 0.1).[37]

The best way to calculate the ALE, is to create four matrices in a spreadsheet. Each matrix will represent one of the following: asset value, exposure factor, annualized rate of occurrence, or annualized loss expectancy. Each matrix would include assets on the column headers and threats and vulnerabilities on the row header. The intersection of the matrix would include asset value, exposure factor, annualized rate of occurrence, or annualized loss expectancy. The ALE matrix would be the multiplication of the asset value, the exposure factor, and the annualized rate of occurrence. An example of how these matrices would be formatted is illustrated below in Figure 2.2. Appendix C contains a more comprehensive example

Figure 2.2

/ X / / X / / = /

Step IV – Summarize Total ALE for Organization

This step calculates the total ALE for the covered entity and consists of a summation of all the intersections in the ALE matrix. The output of the Cost of Non-compliance HIPAA Security Model is this single number. This determines how much risk one is exposed to, expressed in monetary terms for not being compliant to HIPAA Security.

The total ALE for an Organization would provide the business case needed to get executives to focus more resources towards HIPAA security compliance. It was the intention of the authors to use this model, in conjunction with a formula, to come up with specified monetary levels that a particular organization should spend to avoid a certain degree of liability or potential loss. Essentially, based on the Cost of Non-Compliance HIPAA Security Model, a consulting firm would be able to calculate potential losses for a particular organization and using a formula, could calculate the budget needed to mitigate degrees of risk. This formula would be able to provide the ROI on security investments that every organization has had to do without. It would provide a direct correlation between the amount of money spent, and the level of risk and liability assumed, providing each CIO or CSO with a justifiable budget that would provide the ROI that CEOs and CFOs want to see.[38] Given this budget, we adjust our focus towards the second model introduced in this paper, which is able to take this figure and allocate each dollar et, most efficiently.

Part III - The Policy Deployment Model for Minimum HIPPA Security

The Policy Deployment Model for Minimum HIPAA Security consists of several interrelated management concepts that will be discussed prior to the model itself. For ease of comprehension, each of the three concepts will be contained within its own section. The first discusses the management concept of Hoshin Kanri. The second articulates how Hoshin Kanri is modeled using matrices. Finally, the last section will discuss the theory of closed loop planning, and its role within the Hoshin Kanri management concept.