How to avoid security risks through better data practices

A recent security incident at the Nashville Metro Public Health Department in Tennessee exposed the information of thousands of individuals with HIV/AIDS. According to the Tennessean news site, this information was accessible in a public folder on a shared server open to all health department employees for nine months.

Investigation of the incident suggested no evidence that the data had been inappropriately accessed, concluding that the incident did not constitute a breach. The agency did not discipline anyone, but rather used the incident as a teaching moment for its staff and made improvements to its server infrastructure to better accommodate sensitive data.

Unfortunately, this scenario is all too common in healthcare. Data is often viewed as an afterthought instead of an organizational asset to be proactively managed and protected internally and externally.

The facts in this case suggest a complicated data journey that opened the door for security risk.

A director-level employee with detailed knowledge of the data in question moved the database from a secure folder to a public folder for the intended recipient to access. It’s worth noting that this employee met many standard data protocol practices. It just so happened that in making the data available, the employee moved the database into a public folder accessible to ALL agency employees.



Most organizations experience similar data journeys. Even the best written policies and employee training are likely to fail in this circumstance. If an employee thinks he is helping a colleague get data that is consistent with that colleague's role and position, he may not even think that what he’s doing is a violation of policy. Effective risk assessment coupled with a solid data governance plan may have mitigated this breach—and many more just like it.

Given the long duration of time that the sensitive data was accessible to all employees, one would think that periodic risk assessment or audit might have surfaced this risk sooner. While generally accepted practice is that enterprise risk assessment is performed annually, many organizations do not perform to this level. It’s also possible that Metro Public Health was between assessment periods. User access audits would not have necessarily surfaced anything unusual as the employee who moved the database had legitimate access to it.

The scope and methods employed to conduct risk assessment and audits are critical. How could a data-centric risk assessment have identified this issue?

Accounts for all ePHI. If the risk assessment process first accounted for all ePHI in a formal inventory—a step emphasized by the Office for Civil Rights as fundamental to an accurate and thorough risk assessment under HIPAA—one would expect that:

• The data set would have been identified in the inventory.
• The data set would have been "located" in the environment.
• The controls around the data set would have been verified for appropriateness.

Employing these best-practice risk assessment steps, starting with the data, the agency would have realized that this data set did not belong in a publicly accessible location. Unfortunately, most organizations never execute an accurate and thorough ePHI inventory as part of the risk assessment.

Includes a thorough systems inventory. Even if an ePHI inventory was not performed as part of a risk assessment, if a systems inventory that enumerates servers, applications, databases, etc. is conducted, one would expect that this database would have been identified. The presence of sensitive data would have been noted, the controls around it would have been evaluated, and the agency would have realized this data did not belong in a publicly accessible location.

Targets employee education. Would your average employee consider this an "environmental or operational change" necessitating a risk analysis? Probably not. We have yet to see an employee information security training module that illustrates this scenario, moreover one that defines what most employees would consider a "data request" as an "environmental or operational change."

Establishes controls at the data layer. Healthcare organizations need to adopt a data-centric approach to data protection, where controls are established at the data layer. For example, the agency could have encrypted this specific database to further fortify it and render it unreadable to the workforce at large. The agency could have also implemented data loss prevention where rules and policies would have prevented the movement of the sensitive data. These are just two examples of data-centric security approaches that would have averted this incident.

This incident illustrates how data governance supports data protection. Data governance programs introduce data request processes for users who are not typically authorized access to a data domain. Data requests are fielded by data owners, custodians or stewards in the best position to make decisions on granting access. If the agency had implemented a data governance program, the epidemiologist requiring the data would have been oriented to a proper request process.

Data governance introduces more rigorous oversight and audit of an organization's most sensitive data assets. It is cliché but true: there is no such thing as perfect security. But investing resources in and around the data, technically and operationally, will improve security program performance and reduce enterprise risk.