HIMSS: Security cant be back-door issue anymore
ORLANDO, Fla.--There’s a simple definition of security and privacy: As a patient or provider, you want no unexpected use of your data, said Eric Pupo, MBA, who serves as chief architect in the Office of the National Coordinator for Health IT (ONC), during a Feb. 22 HIMSS11 educational session.
However, that’s probably the only simple aspect of privacy and security when it comes to meaningful use. “We’ve identified the healthcare security framework as one of the main issues and risks associated with meaningful use, not just in Stage 1, but also for Stages 2 and 3."
As more information is exchanged, there will be more risks associated with that, including the exchange itself, storage and encryption of information, said Pupo, former HIMSS Privacy and Security Committee chair.
“Risk assessments are required as part of Stage 1, but as we move into Stage 2 and 3, it’s important that we have some regulatory level-setting done and that industry take the lead on implementation,” he said. “The feedback that comes from the healthcare community will be very important in setting objectives for the framework.”
Tools are limited when it comes to risk assessment and security controls for several reasons. Although a raft of control frameworks exist, most of them have an excessive number of associated security requirements, he said. For example, there are 145 total security controls in the National Institute of Standards and Technology (NIST) Special Publication 800-53 alone.
In the face of immediate external pressures, such as healthcare reform and reimbursement, security gets pushed to the back, often because it’s considered an impediment to speedy data transfer, Pupo said. Generally, it tends to be a back-office issue anyway, “not considered sexy as part of health IT in general,” he added.
Also, a soup of regulations and frameworks, especially at the state level, compounds the problem.
No minimal set of federal-level guidelines exists in support of risk analysis aligning the current health security framework, outside entities and meaningful use. Prior to Stage 1, there was consideration given to using Federal Information Security Management Act (FISMA) assessment to require that, but it’s perceived in some organizations as a paperwork exercise that lacks real-time threat monitoring, he said.
Also absent is an educational program to help practices and hospitals understand what the Centers for Medicare & Medicaid Services are looking for to meet security and meaningful use requirements, Pupo said.
An effective national framework would combine elements of frameworks such as FISMA with actual penetration testing and evaluation. It would modularize frameworks to support federal-private sector exchanges without impeding private sector exchanges. In addition, it would require “provable” threat monitoring, rather than basic risk assessment. Finally, it should include a base set of guidelines that can be drawn from NIST 800-53.
Getting there will require:
For example, the government might come up with an objective for meaningful use, but unless the industry does that and vendors implement tools to support it, “you’re not going to be a situation where you’re going to get effective risk assessment done, or have effective security tools.”
“Your input is needed to make sure this is effective and that it works,” he said.
However, that’s probably the only simple aspect of privacy and security when it comes to meaningful use. “We’ve identified the healthcare security framework as one of the main issues and risks associated with meaningful use, not just in Stage 1, but also for Stages 2 and 3."
As more information is exchanged, there will be more risks associated with that, including the exchange itself, storage and encryption of information, said Pupo, former HIMSS Privacy and Security Committee chair.
“Risk assessments are required as part of Stage 1, but as we move into Stage 2 and 3, it’s important that we have some regulatory level-setting done and that industry take the lead on implementation,” he said. “The feedback that comes from the healthcare community will be very important in setting objectives for the framework.”
Tools are limited when it comes to risk assessment and security controls for several reasons. Although a raft of control frameworks exist, most of them have an excessive number of associated security requirements, he said. For example, there are 145 total security controls in the National Institute of Standards and Technology (NIST) Special Publication 800-53 alone.
In the face of immediate external pressures, such as healthcare reform and reimbursement, security gets pushed to the back, often because it’s considered an impediment to speedy data transfer, Pupo said. Generally, it tends to be a back-office issue anyway, “not considered sexy as part of health IT in general,” he added.
Also, a soup of regulations and frameworks, especially at the state level, compounds the problem.
No minimal set of federal-level guidelines exists in support of risk analysis aligning the current health security framework, outside entities and meaningful use. Prior to Stage 1, there was consideration given to using Federal Information Security Management Act (FISMA) assessment to require that, but it’s perceived in some organizations as a paperwork exercise that lacks real-time threat monitoring, he said.
Also absent is an educational program to help practices and hospitals understand what the Centers for Medicare & Medicaid Services are looking for to meet security and meaningful use requirements, Pupo said.
An effective national framework would combine elements of frameworks such as FISMA with actual penetration testing and evaluation. It would modularize frameworks to support federal-private sector exchanges without impeding private sector exchanges. In addition, it would require “provable” threat monitoring, rather than basic risk assessment. Finally, it should include a base set of guidelines that can be drawn from NIST 800-53.
Getting there will require:
- A structure to which an organization can relate its security program that is independent of technology and technology platforms.
- A description of common elements that an organization should have in its security program, implemented differently depending on compliance and risk requirements.
- A mechanism for mapping and assessing against current compliance requirements.
- A scalable model capable of integrating new or emerging requirements.
- Guidance resources for selection and implementation of appropriate security controls and processes.
- A means for determining effectiveness and compliance against measurable industry best practices.
For example, the government might come up with an objective for meaningful use, but unless the industry does that and vendors implement tools to support it, “you’re not going to be a situation where you’re going to get effective risk assessment done, or have effective security tools.”
“Your input is needed to make sure this is effective and that it works,” he said.