A framework to boost security at healthcare organizations
Four core components—authentication, authorization, audit and identity management—work together to harden systems so they’re more difficult for hackers to attack.
The number of patient records breached in healthcare organizations across the United States to date is about 200 million, which is staggeringly close to three-quarters of the entire insured population. The reasons for these breaches range from hacktivism to personal/criminal/political gain to militarism.
The Office of Civil Rights (OCR) at the Department of Health and Human Services (HHS) only started maintaining the breach list in July 2009. At a cost estimate of $400 per breached record in 2015, the total cost estimate of all breaches since 2009 is more than $75 billion. Just within the past 18 months, the total number of breached records has been close to 150 million. Note that only breaches covering more than 500 records per incident had to be reported to OCR until August 2016; we may therefore have been missing a very “long tail” in the breach curve.
In 2015 alone, the number of records breached was 112 million; the numbers for 2016 to date is far below that amount. Patient records used to have much higher financial value than credit card information; they now have much higher military and political value as we warily look to the future of cyber and biological warfare. The following questions are now at the forefront:
The keys to understanding the security profile of any healthcare organization is authentication, authorization, audit and identity management (AAAIM), mapping its business functions to standard operating procedures (SOPs), verifying and validating software systems and change control methods.
Security and privacy processes are governed by state, federal and sovereign regulations. A little known fact is that the U.S. Healthcare Insurance Portability and Accountability Act (HIPAA) does not mandate encryption. However, it does mandate multi-factor authentication. The most commonly used technique is “two-factor authentication” or 2FA. A combined secure HTTP and 2FA process is fast becoming the industry standard across retail and financial industries.
It is well understood in healthcare systems that encryption both at the protocol layer (“in flight”) and within the storage system (“at rest”) are industry best practices, since reporting to the OCR upon a data breach is optional when encryption at rest and in flight is implemented. This does not, however, prevent the “inside job,” still the largest cause of data breaches. In the U.S., the sobering statistic is that the probability of a hospital’s data being breached is about 90 percent, which is as close to certainty as one can get. The question then becomes what to do after a breach.
The four core security components in a healthcare system are:
Authentication
Authentication is the process of reliably verifying the identity of actors as they interact with components of a healthcare system and is the foundation for the other three components. Policies for adequately strong passwords, multiple factors in the authentication process (what you know, what you have, and who you are), as well as robust implementation of the trusted computing base that enforces it are key to securing the system. It is also important to have systems that are able to leverage the results of authentication to handle the complexity of access control lists (ACL) and other authorization mechanisms needed, and do so across protocols, multiple operating and file systems.
Authorization
A continuous assessment of risk for users and systems is essential for authorization. This makes the process that determines the key risk indicators (KRI), audit trails and system logs critically important. External factors can forensically determine a change in the internal threat vector – this is important since about 50 percent of breaches are committed by internal actors. Access to applications, functions and systems can be role-based, process-based discretionary and risk-based. Risk is usually determined during design and implementation as functional, business or regulatory.
Audit
Audits are the proof-points that verify and validate a system. Creating a multi-protocol logging and audit system is critical, especially within scale-out infrastructures. To paraphrase physicist Lord Kelvin, “If you cannot (map and) measure it, you cannot (change or) improve it.” Audits are principal factors in the change control process. With “digital transformation” becoming the key strategy for healthcare, data integrity and trust comes from logs and audits. Process and vendor audits provide a complete view of the system.
Identity management
Determining the unique identity of patients and their samples across multiple systems and processes remains one of the most complex integration challenges in healthcare. A universal patient ID is required for: a single identifier for multiple health providers, payers and clinical trials; prescription drug reconciliation; precision medicine; controlled substance management and payment or fraud monitoring. National Institutes of Standards and Technology (NIST) Identity Ecosystem Steering Group (IDESG), OpenID Connect and Fast Healthcare Interoperability Resource (FHIR) are example initiatives. Biometrics may ultimately become the true identifier for patients.
Each of these pillars has to behave nicely across Domain Name Services (DNS), Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) as well as multiple protocols (NFS, SMB, HTTP, HDFS and others). At times, they must function properly across firewalls and demilitarized zones (DMZs) along with network authentication protocols like Kerberos.
A snapshot of the current IT system is the first step in determining the security footprint. The next step is a comprehensive risk analysis for the functional, business and regulatory risks both within the organization and its external touch-points. Auditing and logging of each of these components is critical for regulatory compliance, process understanding and future planning. This functional approach toward regulatory compliance divides the IT infrastructure into three areas, described in the chart below: install and pre-operations; resources and quality; and operations. These are basic steps to monitor both external and internal triggers for proactively and forensically managing the threat surfaces.
The compliance mapping process to standards starts with the categorizing of all the current regulations into functions. An example of two functions are shown here.
Authentication and De/Re-identification. The Authentication functions are identified by bubbles (1), (2) and (3) and the de-identification and re-identification (De-ID/Re-ID) function shown by bubble (4).
Standard Operating Procedures (SOPs) are very useful for research organizations and necessary compliance requirements for clinical and healthcare systems.
The following table lists a minimal set of SOPs for lab operations and would correspond to functions in the graphic above: Security Plan: Infrastructure and Service Provider Audit; Installation, Operational and Performance Qualifications (IQ, OQ, PQ); File Access and Verification; and Vulnerability and Intrusion Testing. This mapping process is also critical for regulatory compliance since it makes change control (another compliance metric) much easier.
The IQ/OQ/PQ process is central in the pharmaceutical and biotechnology industries that are governed by the Food and Drug Administration (FDA) within the 21 CFR Part 11 regulation. Following this process as a best practice is highly recommended.
Verification and validation can each be defined simply by two questions: “Is the healthcare software system being built right?” and “Are we building the right system?” Verification refers to design and requirements specifications. Validation describes functional, business and regulatory risks along with test planning and the three-step qualifications: IQ, OQ and PQ. This is summarized in the IEEE guidelines for Software Verification and Validation.
Finally, managing changing systems and user conditions is critical to security systems. It is imperative to constantly train and refresh the IT team’s knowledge about security matters. We live in a period of “continuous integration.” This requires an understanding of the communication process between disparate groups that run the healthcare system and managing the change process. Most of the 18 Protected Health Identifiers (PHI) including names, addresses, phone numbers, etc., can be obtained from sources other than healthcare payers or providers, making the monitoring of external sources an important new area for security. A good summary of PHI is provided in the SAFER Patient ID best practices.
President Ronald Reagan famously used the phrase “Trust but verify” which is actually a Russian proverb (Doveryai, no proveryai). It is time for the healthcare industry to grow up both in terms of innovation and security.
The Office of Civil Rights (OCR) at the Department of Health and Human Services (HHS) only started maintaining the breach list in July 2009. At a cost estimate of $400 per breached record in 2015, the total cost estimate of all breaches since 2009 is more than $75 billion. Just within the past 18 months, the total number of breached records has been close to 150 million. Note that only breaches covering more than 500 records per incident had to be reported to OCR until August 2016; we may therefore have been missing a very “long tail” in the breach curve.
In 2015 alone, the number of records breached was 112 million; the numbers for 2016 to date is far below that amount. Patient records used to have much higher financial value than credit card information; they now have much higher military and political value as we warily look to the future of cyber and biological warfare. The following questions are now at the forefront:
- Who minds our data in a healthcare transaction?
- Who is the custodian of these records over the life of the patient?
- Who is responsible when patient records are breached?
- What are the ethical, legal and social implications (ELSI) of data breaches in healthcare?
The keys to understanding the security profile of any healthcare organization is authentication, authorization, audit and identity management (AAAIM), mapping its business functions to standard operating procedures (SOPs), verifying and validating software systems and change control methods.
Security and privacy processes are governed by state, federal and sovereign regulations. A little known fact is that the U.S. Healthcare Insurance Portability and Accountability Act (HIPAA) does not mandate encryption. However, it does mandate multi-factor authentication. The most commonly used technique is “two-factor authentication” or 2FA. A combined secure HTTP and 2FA process is fast becoming the industry standard across retail and financial industries.
It is well understood in healthcare systems that encryption both at the protocol layer (“in flight”) and within the storage system (“at rest”) are industry best practices, since reporting to the OCR upon a data breach is optional when encryption at rest and in flight is implemented. This does not, however, prevent the “inside job,” still the largest cause of data breaches. In the U.S., the sobering statistic is that the probability of a hospital’s data being breached is about 90 percent, which is as close to certainty as one can get. The question then becomes what to do after a breach.
The four core security components in a healthcare system are:
Authentication
Authentication is the process of reliably verifying the identity of actors as they interact with components of a healthcare system and is the foundation for the other three components. Policies for adequately strong passwords, multiple factors in the authentication process (what you know, what you have, and who you are), as well as robust implementation of the trusted computing base that enforces it are key to securing the system. It is also important to have systems that are able to leverage the results of authentication to handle the complexity of access control lists (ACL) and other authorization mechanisms needed, and do so across protocols, multiple operating and file systems.
Authorization
A continuous assessment of risk for users and systems is essential for authorization. This makes the process that determines the key risk indicators (KRI), audit trails and system logs critically important. External factors can forensically determine a change in the internal threat vector – this is important since about 50 percent of breaches are committed by internal actors. Access to applications, functions and systems can be role-based, process-based discretionary and risk-based. Risk is usually determined during design and implementation as functional, business or regulatory.
Audit
Audits are the proof-points that verify and validate a system. Creating a multi-protocol logging and audit system is critical, especially within scale-out infrastructures. To paraphrase physicist Lord Kelvin, “If you cannot (map and) measure it, you cannot (change or) improve it.” Audits are principal factors in the change control process. With “digital transformation” becoming the key strategy for healthcare, data integrity and trust comes from logs and audits. Process and vendor audits provide a complete view of the system.
Identity management
Determining the unique identity of patients and their samples across multiple systems and processes remains one of the most complex integration challenges in healthcare. A universal patient ID is required for: a single identifier for multiple health providers, payers and clinical trials; prescription drug reconciliation; precision medicine; controlled substance management and payment or fraud monitoring. National Institutes of Standards and Technology (NIST) Identity Ecosystem Steering Group (IDESG), OpenID Connect and Fast Healthcare Interoperability Resource (FHIR) are example initiatives. Biometrics may ultimately become the true identifier for patients.
Each of these pillars has to behave nicely across Domain Name Services (DNS), Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) as well as multiple protocols (NFS, SMB, HTTP, HDFS and others). At times, they must function properly across firewalls and demilitarized zones (DMZs) along with network authentication protocols like Kerberos.
A snapshot of the current IT system is the first step in determining the security footprint. The next step is a comprehensive risk analysis for the functional, business and regulatory risks both within the organization and its external touch-points. Auditing and logging of each of these components is critical for regulatory compliance, process understanding and future planning. This functional approach toward regulatory compliance divides the IT infrastructure into three areas, described in the chart below: install and pre-operations; resources and quality; and operations. These are basic steps to monitor both external and internal triggers for proactively and forensically managing the threat surfaces.
The compliance mapping process to standards starts with the categorizing of all the current regulations into functions. An example of two functions are shown here.
Authentication and De/Re-identification. The Authentication functions are identified by bubbles (1), (2) and (3) and the de-identification and re-identification (De-ID/Re-ID) function shown by bubble (4).Standard Operating Procedures (SOPs) are very useful for research organizations and necessary compliance requirements for clinical and healthcare systems.
The following table lists a minimal set of SOPs for lab operations and would correspond to functions in the graphic above: Security Plan: Infrastructure and Service Provider Audit; Installation, Operational and Performance Qualifications (IQ, OQ, PQ); File Access and Verification; and Vulnerability and Intrusion Testing. This mapping process is also critical for regulatory compliance since it makes change control (another compliance metric) much easier.
The IQ/OQ/PQ process is central in the pharmaceutical and biotechnology industries that are governed by the Food and Drug Administration (FDA) within the 21 CFR Part 11 regulation. Following this process as a best practice is highly recommended.Verification and validation can each be defined simply by two questions: “Is the healthcare software system being built right?” and “Are we building the right system?” Verification refers to design and requirements specifications. Validation describes functional, business and regulatory risks along with test planning and the three-step qualifications: IQ, OQ and PQ. This is summarized in the IEEE guidelines for Software Verification and Validation.
Finally, managing changing systems and user conditions is critical to security systems. It is imperative to constantly train and refresh the IT team’s knowledge about security matters. We live in a period of “continuous integration.” This requires an understanding of the communication process between disparate groups that run the healthcare system and managing the change process. Most of the 18 Protected Health Identifiers (PHI) including names, addresses, phone numbers, etc., can be obtained from sources other than healthcare payers or providers, making the monitoring of external sources an important new area for security. A good summary of PHI is provided in the SAFER Patient ID best practices.
President Ronald Reagan famously used the phrase “Trust but verify” which is actually a Russian proverb (Doveryai, no proveryai). It is time for the healthcare industry to grow up both in terms of innovation and security.
More for you
Loading data for hdm_tax_topic #reducing-cost...