What Security Means to a Healthcare CIO

As always I find the most interesting security posts are not vendor/consultant-style about how many security mechanisms can dance on the head of a pin, but rather about engineering security to work in real world systems, here is an excerpt from John Halamka on Life as a Healthcare CIO:

As vice chairman of the federal Healthcare Information Technology Standards Committee, I have been on the front lines in the debate over the standards and implementation guidance needed to support the exchange of health care information. Over the past few months, I've learned a great deal from the committee's privacy and security workgroup. Here are my top five lessons:

1. Security is not just about using the right standards or purchasing products that implement those standards. It's also about the infrastructure on which those products run and the policies that define how they'll be used. A great software system that supports role-based security is not so useful if everyone is assigned the same role and its accompanying access permissions. Similarly, running great software on an open wireless network could compromise privacy.

First off, great point about RBAC, which is my current poster child for "security silver bullet that delivers silver to the vendors but not much to the customer." Second "It's also about the infrastructure on which those products run and the policies that define how they'll be used." - to me this is exactly why security is fundamentally an integration problem

2. Security is a process, not a product. Hackers are innovative, and security practices need to be constantly enhanced to protect confidentiality. Security is also a balance between ease of use and absolute protection. The most secure library in the world -- and the most useless -- would be one that never loaned out any books.

3. Security is an end-to-end process. The health care ecosystem is as vulnerable as its weakest link. Thus, each application, workstation, network and server within an enterprise must be secured to a reasonable extent. The exchange of health care information between enterprises cannot be secured if the enterprises themselves are not secure.

Confidentiality, integrity and availability - pick any two.

4. The U.S. does not have a single, unified health care privacy policy -- it has 50 of them. That means that products need to support multiple policies -- for example, those of a clinic that uses simple username/password authentication and those of a government agency that requires smart cards, biometrics or hardware tokens.

This will be interesting to watch in the Cloud as well and why I think one of the main enabling factors for the Cloud will be decentralized policy languages

5. Security is a function of budget. Health care providers' budgets vary widely. New security requirements must take into account the implementation pace that the various stakeholders can afford. Imposing "nuclear secrets" security technology on a small doctor's office is not feasible. Thus, the privacy and security workgroup has developed a matrix of required minimum security standards to be implemented in 2011, 2013 and 2015, recognizing that some users will go beyond these minimums.

I tip my hat to healthcare IT and security people, they have a way harder job, much higher stakes, and usually less resources than the rest of us. I still like the flat tax idea, simply align the percentage you want to spend on security for each project and try to get as much efficacy out of that effort that you can.