ORLANDO, Fla. — Given that the majority of health care data breaches occur at the application layer, health care organizations need to make application risk management a high priority. Doing so requires far more than simply investing in application security tools, according to John B. Sapp Jr., the director of product development standards for security, risk and compliance at McKesson Corp.
By and large, health care organizations’ networks and operating systems are secure Sapp said during a session at the Healthcare Information and Management Systems Society’s HIMSS 2011 conference. Applications, on the other hand, are not. As he put it, “You’ve locked the back door and the windows, but you’ve left the front door open.”
The leading sources of vulnerabilities, Sapp said, tend to be Web 2.0-enabled legacy systems or those built using the outdated .NET Framework 2.0. These apps lend themselves to such vulnerabilities as cross-site scripting, SQL injections, dictionary attacks, and the storage of sensitive data in cache or in memory, he said.
The Health Insurance Portability and Accountability Act (HIPAA) Security Rule does offer some suggestions related to access control and authentication, but, unlike Payment Card Industry compliance, this guidance is not explicit, Sapp noted.
That’s where application risk management comes in. Through this process, organizations identify their most vulnerable apps, the most severe vulnerabilities, and the ones that are most difficult — and costly — to remediate. To truly succeed, the application risk management process must be transparent, agile and sustainable — meaning that it can be updated.
The first steps, Sapp said, include selecting a risk management model from such groups as the National Institute for Standards and Technology, the International Organization for Standardization or the Information Systems Audit and Control Association, as well as choosing your approach to managing risk. In the latter case, the options are a monarchy, which may work for a single-physician practice; an autonomy, which multifacility groups may go for, or a federation, which employs centralization or decentralization where it fits best. (Anarcho-syndicalism is not an option.)
From there, organizations need to define an application risk-management governance structure and evaluate software for both static and dynamic analysis. The security risk assessment documentation those systems produce should be stored in a central location that is easy to search.
Overall, application risk management is bound to represent a cultural shift for many health care organizations. It could bring up contentious issues: Does a pharmacist really needs to know a patient’s birth date and Social Security number? In the interest of saving time, should medical professionals share passwords? (Sapp’s personal opinion? No and no.)
As providers invest in a variety of software systems in the rush to achieve meaningful use compliance, however, application security and risk management should be just as important to an organization as usability, Sapp said.