The healthcare industry faces challenges in trying to keep its customers' records secure and to run its business-technology systems within regulatory mandates. We've interviewed security expert Gunnar Peterson, managing principal at Arctec Group, a consultancy based in Minneapolis. Peterson's speciality is distributed systems security for large, mission-critical systems in the financial, healthcare, manufacturing, and insurance industries. Peterson also blogs at 1raindrop and has a number of interesting thoughts on the special challenges of health care security.
CIO: How do you see healthcare data security as being different from securing other types of data and transactions from other industries?
Gunnar Peterson: I think that the health care industry has a number of challenges that make the security architect's job, the CSO's job -- in all cases except for one -- much more difficult than in financial services and most other industries. The one thing that's more difficult in financial services is that they have ongoing determined attacks through fraud and other types of financial attacks. That's been with banks long before there were computers. I would argue that almost every other aspect of security is more difficult in healthcare.
It starts with the transaction. One of the nice things that security architects have in the financial world is a very black and white transaction model. The money is in my account, or it's in your account, or it's in the holding company's account. There is no gray area about who's got the money at any given period of time, or where the risk is at any given time. Relatively speaking these transaction models are brutally simple, because lots of players have to sign up for them and there's lots of standardization. And people have been tweaking these models for a long time. When you start a job as a CISO at a financial services firm you are given a transaction model manual, and it's fairly straightforward.
If you compare that to medical records, to healthcare insurance, or other things in that space, there is almost no uniformity, no standardisation in how many of these interactions work. On your very first day as a security architect at a healthcare company, or somebody dealing with medical records, you are going to get either no guidance on the transactions model or thousands of pages of Byzantine, non-uniform protocols, data formats, things that don't reconcile -- and then you are going to have to figure out a way to secure this. So, in financial services, you have a nicely layered lasagna and then you have an endless and endless amount of spaghetti with ten different kinds of sauce in the healthcare world.
Now, much of that organisational mess translates to the technical protocols that we have to use -- access controls, Kerberos, SAML, data encryption -- pick whatever thing you think is going to solve your problem, you have to layer that onto something. If that something is a hodgepodge, you have a hell of a problem. That right there guarantees that the challenge is going to be more difficult in healthcare.
CIO: And that hodgepodge exists because it's more difficult for healthcare technologists to predict transaction flow and how data will be used?
Peterson: I think that's a lot of it. There are a couple of other aspects. Another is that those companies -- and I'm sure you have plenty of numbers that show this -- but those healthcare companies most often put in ten times less money for security. Maybe there's a good reason for that. Maybe that's prudent on their part. I'm sort of agnostic on that. For the person who is in charge of solving those problems, they are trying to solve a much harder problem with fewer resources. That's a problem. With healthcare, you have this unbelievable collision between confidentiality, keeping some of the data private, with all of the other security challenges. So if you managed your way through the spaghetti with ten kinds of sauces and you got through the lack of funding, then you need to try and solve the collision of security and privacy on top of that. That's an incredible problem to try to have to solve.
So if you step back from that at the industry level, the second point I raised was on funding. Who spends the most money on security technologies? Who buys the most Tivoli Access Managers? Who buys the most Oracle Access Managers? Financial services by far. That means that they're the ones driving the security vendor investment. They're the ones that have the ear of IBM, that have the ear of Oracle and the other big companies. Then the big companies go off and they innovate on the requests of their biggest customers. So they're building more and more great stuff for the financial services industry.
CIO: What are the most pragmatic areas where health care IT firms should place their security energies?
Peterson: I've come to the answer, and it's not one I'm necessarily happy about or feel good about. But I think for cost effective solutions for under-funded, under-empowered, under tooled teams maybe monitoring is one of your primary tools. Encrypting all of the data everywhere all of the time is the end game, to solve a lot of these privacy problems and having a good comprehensive encryption strategy. However, that's problematic to actually roll out in the real world for all of the tooling and support and funding reasons I already talked about. It really puts health care, practically speaking, in a tough spot.
Technically, it's not elegant at all. It obviously doesn't address the problem of holes in the system, which I dislike as an engineer. However, if you want to actually do something about it next week, next month, next year, I don't know what other options you really have. Go to your CIO and say, "I know the economy is tough, but I need ten times more money next year to do this encryption project." I don't think you're going to get a slap on the back and hear him or her say, "Hey buddy, let's go play golf and discuss that. It sounds like a great idea."
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.