We sat down with CynergisTek Inc. CEO Mac McMillan to discuss how his healthcare clients are approaching their...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
health information security investments at a time when they're being squeezed by narrower budgets and increased HIPAA compliance mandates. McMillan also serves as a member of the HIMSS Privacy & Security Policy Task Force.
Most of these guys take a checklist and they go down it and say, 'Okay, do I have a policy for security management? Yes? Okay, I'm all set, there's no risk there.' But that's not a risk assessment.
CEO, CynergisTek Inc.
What would you say are the weakest, most vulnerable spots of a hospital's network security?
Mac McMillan: Well, the No. 1 weakest link, still, is people. People doing things that aren't very smart, people doing things that are inappropriate, people doing things because they're in a hurry or because they're overburdened, overworked and have too many things on their plate. But essentially, our biggest weakness continues to be the sum of wounds we inflict on ourselves by our own staff.
[The] second biggest weakness we continue to have is mobile devices: How we're dealing with those, how we're protecting those, how much data we're allowing to be on those, and the magnitude of the losses when we lose a laptop that's unencrypted or the like.
This is coming at organizations faster than they have had time to develop a mobile security or mobile device security strategy. So, it's like they're poking fingers in the dike and the dike is about to burst.
The last biggest weakness is the general lack of resources that we still see with respect to privacy and security in healthcare. We still have a number of organizations that don't have dedicated security professionals or don't have a security professional with any real experience, background or certifications, etc. We see programs that are woefully underfunded in terms of what it really takes to secure data properly.
Are hospitals upgrading platforms and apps that have better onboard security, or are they turning to third-party security solutions running on top of their legacy apps?
McMillan: I think to the extent that they can, they are trying to acquire solutions that have better organic security functionality. The problem is, unfortunately, there aren't a lot of vendors who are really embracing or providing technology with that functionality. Part of the problem is that the industry doesn't have a standard from a security perspective with respect to what it buys, requires or uses.
The only technology we have in healthcare today that has any mandated security is the electronic health record [EHR]. But for every other healthcare application and medical device that we have, there is no requirement whatsoever for those applications or those devices to have security functionality. So, unless the hospital itself puts a standard or requirement out there that they won't buy any application that at least meets these minimum security requirements, they end up having to rely on [a] third-party system, which actually makes it more costly in the long run and makes their system more complex, which ends up costing healthcare even more at the end of the day.
If we really want to be serious about reducing the cost of healthcare, we would get more serious about standardizing the environment and providing standards for how systems are developed and the functionality that systems have to provide in order to assure a basic level of trust, and then that computing environment doesn't have to require additional, expensive third-party solutions to put security around it.
What is your 'CliffsNotes' version of the risk assessment process for health data security? Best practices that you'd prescribe?
McMillan: Actually, this is one of the few areas that I give OCR [the Department of Health and Human Services' Office for Civil Rights] a lot of credit. In 2009, when HITECH came out, the OCR was charged with publishing guidance for compliance with the rules. But the only guidance that they have published since then was in 2010, on risk analysis, and I thought they did a very good job with it. They took the [National Institute of Standards and Technology Special Publication] 800-30, which is the NIST guideline for conducting risk analysis, and they converted it into a fairly simple-to-read, what I call 'layman's terms' process for how to conduct a compliance risk assessment. It defined the nine steps they needed to follow, it defined the elements of the risk assessment that they needed to address, it covered the periodicity, etc. That's the process we use at CynergisTek, and we have been using it since 2004, when we founded the company.
The reason we did that is because, having a government background myself, one of the things I knew and continue to understand is that whenever the OCR applies a standard to anything, they are going to apply a government standard, and in this case the standard that they have routinely applied is the NIST standards. When you look at breach notification and you look at the encryption standard, they reference the NIST documents. When you look at the security requirements around the data-use agreement for ACOs [accountable care organizations], they reference the FIPS [Federal Information Processing Standard] 200, which references the NIST 800-53 controls matrix. So they always reference those government regulations, and in this case, they did a good job of defining what has to happen.
If organizations would just follow that guidance -- which is conduct a thorough risk analysis and address the physical, the technical and the administrative controls in their environment, and look at their processes and their systems -- a lot of these things would become readily apparent.
What do your clients' risk assessments usually turn up? Common things they typically need to address?
McMillan: Typically you'll find integrity issues with systems themselves in terms of how well they are maintained. You'll find configuration issues with respect to harmful and risky services that are running on systems, or things that are not configured very well in terms of vulnerabilities that are out there. You'll find processes that are missing; you'll find a lack of training as it relates to individuals and their responsibilities.
If it's done correctly, when we do a risk assessment for a hospital, if it's a first time, we'll typically identify anywhere from 150 to 300 items that need to be reviewed. If it's a mature environment, on the administrative side we'll still identify a dozen or so things that still are outstanding; and on the technical side we'll always identify a score of things, because depending on how large it is, how technical it is, and when you look at the threat environment, there are literally hundreds of things on a daily basis that organizations need to address as it relates to their system environment from a patching, configuring and whatnot perspective. If it's done correctly, it uncovers a lot of stuff.
Most of these guys take a checklist, and they go down it and say, 'Okay, do I have a policy for security management? Yes? Okay, I'm all set, there's no risk there.' But that's not a risk assessment. Going through the 42 elements of HIPAA and noting if you have a policy for it or not -- that's not conducting a risk assessment. Clearly, when you read the guidance that's published, you quickly understand that's not a risk assessment.
What basic steps can small providers (solo practitioners, small groups) take to keep their networks safe from predators? As they can't invest in these enterprise systems, is their onboard security good enough?
McMillan: The good news is, since risk assessment is a process, it is absolutely scalable for smaller organizations. When you look at most doctors' offices, they tend to have very little technology, and in most cases don't have in-house technical support. If I was a physician's practice, if you will, I would treat it the same way I treat legal and finance -- I wouldn't do it. I would have my EHR or EMR as SaaS [Software as a Service] -- as opposed to me -- managing it. I would have my network hosted, where all I would have locally would be my workstations, which would be configured on VDI [Virtual Desktop Infrastructure] platforms. None of the data would be at my office; it would be wherever that hosting facility was, and I would take advantage of that facility's security to meet my requirements.
There's nothing that says small providers have to do it themselves; and most small businesses, quite frankly, don't. And certainly today, there are a number of options out there with respect to hosted platforms, hosted services and data hosting, and some of them are quite affordable, and in most cases are probably more affordable than them doing it internally.
But if they are going to do it internally, for the most part they need to have basic security around their network; they need a firewall, they need to have an antivirus running on their network. They need to keep their systems up to date with respect to patching and fixing. And nowadays, if they are using the latest version of Windows, [MS Services] allows them to automatically patch and that sort of thing, so it just depends how much risk they are willing to take on internally.
It's often said that healthcare is two to five years behind other industries, such as manufacturing, banking and finance, etc. Can healthcare walk in their footsteps and secure their networks without learning 'the hard way?'
McMillan: Oh, absolutely. One of the things that I try to do all the time is stress the fact that there is nothing new here. Healthcare is not paving any new ground when it comes to data security. Anything that we're doing has already been done in the government sector, the finance sector or the energy [sector]. We know how it works and whatnot. The problem is that those other industries are spending 6% to 12% of their IT budget on security and healthcare is still spending less than 3%. And without the right technology, a lot of it isn't possible.