Healthcare Cybersecurity

November 2021 Healthcare Data Breach Report

The number of reported healthcare data breaches has increased for the third successive month, with November seeing 68 data breaches of 500 or more records reported to the HHS’ Office for Civil Rights – a 15.25% increase from October and well above the 12-month average of 56 data breaches a month. From January 1 to November 30, 614 data breaches were reported to the Office for Civil Rights. It is looking increasingly likely that this year will be the worst ever year for healthcare data breaches.

The number of data breaches increased, but there was a sizable reduction in the number of breached records. Across the 68 reported breaches, 2,370,600 healthcare records were exposed, stolen, or impermissibly disclosed – a 33.95% decrease from the previous month and well below the 12-month average of 3,430,822 breached records per month.

Largest Healthcare Data Breaches Reported in November 2021

In November, 30 data breaches of 10,000 or more records were reported to the HHS’ Office for Civil Rights, and 4 of those breaches resulted in the exposure/theft of more than 100,000 records. The average breach size in November was 34,862 records and the median breach size was 5,403 records.

The worst breach of the month saw the protected health information of 582,170 individuals exposed when hackers gained access to the network of Utah Imaging Associates. Planned Parenthood also suffered a major data breach, with hackers gaining access to its network and exfiltrating data before using ransomware to encrypt files.

Sound Generations, a non-profit that helps older adults and adults with disabilities obtain low-cost healthcare services, notified patients about two ransomware attacks that had occurred in 2021, which together resulted in the exposure and potential theft of the PHI of 103,576 individuals.

Name of Covered Entity Covered Entity Type Individuals Affected Type of Breach Location of Breached PHI Cause of Breach
Utah Imaging Associates, Inc. Healthcare Provider 582,170 Hacking/IT Incident Network Server Unspecified hacking incident
Planned Parenthood Los Angeles Healthcare Provider 409,759 Hacking/IT Incident Network Server Ransomware attack
The Urology Center of Colorado Healthcare Provider 137,820 Hacking/IT Incident Network Server Unspecified hacking incident
Sound Generations Business Associate 103,576 Hacking/IT Incident Network Server Two ransomware attacks
Mowery Clinic LLC Healthcare Provider 96,000 Hacking/IT Incident Network Server Malware infection
Howard University College of Dentistry Healthcare Provider 80,915 Hacking/IT Incident Electronic Medical Record, Network Server Ransomware attack
Sentara Healthcare Healthcare Provider 72,121 Hacking/IT Incident Network Server Unspecified hacking incident at a business associate
Ophthalmology Associates Healthcare Provider 67,000 Hacking/IT Incident Electronic Medical Record, Network Server Unspecified hacking incident
Maxim Healthcare Group Healthcare Provider 65,267 Hacking/IT Incident Email Phishing attack
True Health New Mexico Health Plan 62,983 Hacking/IT Incident Network Server Unspecified hacking incident
TriValley Primary Care Healthcare Provider 57,468 Hacking/IT Incident Network Server Ransomware attack
Broward County Public Schools Health Plan 48,684 Hacking/IT Incident Network Server Ransomware attack
Consociate, Inc. Business Associate 48,583 Hacking/IT Incident Network Server  
Doctors Health Group, Inc. Healthcare Provider 47,660 Hacking/IT Incident Network Server Patient portal breach at business associate (QRS Healthcare Solutions)
Baywood Medical Associates, PLC dba Desert Pain Institute Healthcare Provider 45,262 Hacking/IT Incident Network Server Unspecified hacking incident
Medsurant Holdings, LLC Healthcare Provider 45,000 Hacking/IT Incident Network Server Ransomware attack
One Community Health Healthcare Provider 39,865 Hacking/IT Incident Network Server Unspecified hacking incident
Educators Mutual Insurance Association Business Associate 39,317 Hacking/IT Incident Network Server Malware infection
Victory Health Partners Healthcare Provider 30,000 Hacking/IT Incident Network Server Ransomware attack
Commission on Economic Opportunity Business Associate 29,454 Hacking/IT Incident Network Server Hacked public claimant portal

Causes of November 20021 Healthcare Data Breaches

Hacking/IT incidents dominated the breach reports in November, accounting for 50 of the reported breaches. Ransomware continues to be extensively used in attacks on healthcare providers and their business associates, with the attacks often seeing sensitive patient data stolen and posted on data leak sites. The theft of patient data in these attacks also makes lawsuits more likely. Planned Parenthood, for example, was hit with a class action lawsuit a few days after mailing notification letters to affected patients.

2,327,353 healthcare records were exposed or stolen across those hacking incidents, which is 98.18% of all records breached in November. The average breach size for those incidents was 42,316 records and the median breach size was 11,603 records.

There were 11 unauthorized access/disclosure breaches in November – half the number of unauthorized access/disclosure breaches reported in October. Across those breaches, 37,646 records were impermissibly accessed or disclosed. The average breach size was 3,422 records and the median breach size was 1,553 records. There were also two reported cases of theft of portable electronic devices containing the electronic protected health information of 5,601 individuals.

November Healthcare Data Breaches by Covered Entity Type

Healthcare providers were the worst affected covered entity type with 50 reported breaches, with four of those breaches occurring at business associates but were reported by the healthcare provider. 8 data breaches were reported by health plans, 3 of which occurred at business associates, and business associates self-reported 10 data breaches. The pie chart below shows the breakdown of breaches based on where the breach occurred.

Geographic Distribution of November Healthcare Data Breaches

Healthcare data breaches of 500 or more records were reported by HIPAA-regulated entities in 32 states and the District of Columbia.

State Number of Reported Data Breaches
California & New York 7
Maryland & Pennsylvania 4
Colorado, Kentucky, Ohio, & Utah 3
Illinois, Indiana, Michigan, Minnesota, New Mexico, Tennessee, Texas, Virginia, and the District of Columbia 2
Alabama, Arizona, Arkansas, Florida, Georgia, Idaho, Kansas, Massachusetts, Missouri, Nebraska, New Hampshire, New Jersey, North Carolina, Oregon, South Carolina, and Washington 1

HIPAA Enforcement Activity in November 2021

There was a flurry of HIPAA enforcement activity in November with financial penalties imposed by federal and state regulators. The HHS’ Office for Civil Rights announced a further 5 financial penalties to resolve alleged violations of the HIPAA Right of Access. In all cases, the healthcare providers had failed to provide patients with a copy of their requested PHI within a reasonable period of time after a request was received.

Covered Entity Penalty Penalty Type Alleged Violation
Rainrock Treatment Center LLC (dba Monte Nido Rainrock)

 

$160,000

 

Settlement HIPAA Right of Access
Advanced Spine & Pain Management $32,150

 

Settlement HIPAA Right of Access
Denver Retina Center $30,000

 

Settlement HIPAA Right of Access
Wake Health Medical Group

 

$10,000

 

Settlement HIPAA Right of Access
Dr. Robert Glaser

 

$100,000 Civil Monetary Penalty HIPAA Right of Access

The New Jersey Attorney General and the Division of Consumer Affairs announced in November that a settlement had been reached with two New jersey printing firms – Command Marketing Innovations, LLC and Strategic Content Imaging LLC – to resolve violations of HIPAA and the New Jersey Consumer Fraud Act. The violations were uncovered during an investigation into a data breach involving the PHI of 55,715 New Jersey residents.

The breach was due to a printing error that saw the last page of one individual’s benefit statement being attached to the benefit statement of another individual.  The Division of Consumer Affairs determined the companies failed to ensure confidentiality of PHI, did not implement sufficient PHI safeguards and failed to review security measures following changes to procedures. A financial penalty of $130,000 was imposed on the two firms, and $65,000 was suspended and will not be payable provided the companies address all the security failures identified during the investigation.

The post November 2021 Healthcare Data Breach Report appeared first on HIPAA Journal.

New Data Reveals Extent of Ransomware Attacks on the Healthcare Sector

The CyberPeace Institute has released new data on cyberattacks on the healthcare industry. According to the latest figures, 295 cyberattacks are known to have been conducted on the healthcare sector in the past 18 months between June 2, 2020, and December 3, 2021. The attacks have been occurring at a rate of 3.8 per week and have occurred in 35 countries.

Those attacks include 263 incidents that have either been confirmed as ransomware attacks (165) or are suspected of involving ransomware (98), with those attacks occurring in 33 countries at a rate of 3.4 incidents a week. Over the past 18 months, at least 39 different ransomware groups have conducted ransomware attacks on the healthcare sector. Those attacks have mostly been on patient care services (179), followed by pharma (35), medical manufacturing & development (26), and other medical organizations (23).

The CyberPeace Institute studied darknet publications, correspondence with ransomware gangs, and interviews and identified 12 ransomware groups that had stated they would not conduct attacks on the healthcare sector during the pandemic, yet still continued to attack healthcare organizations, with at least six of the 12 having conducted attacks on hospitals.

The definition of healthcare used by the gangs differs from what many people would assume to be healthcare. For instance, while all 12 of the ransomware gangs said they would not attack hospitals, many used vague terms to describe healthcare, such as medical organizations. While that may suggest all healthcare was off-limits, many of the gangs considered the pharmaceutical industry to be fair game, since pharma companies were said to be profiting from the pandemic.

Three ransomware operations admitted mistakes had been made and healthcare organizations had been attacked in error. They said publicly that when a mistake is made, the keys to decrypt files would be provided free of charge.  However, there were cases where there was some dispute about whether an organization was included in the gangs’ definitions of exempt organizations.

It should be noted that when an attack occurs and files are encrypted, the damage is already done. Even if the keys to decrypt data are provided free of charge, the attacked organizations still experience disruption to business operations and patient services. The process of restoring data from backups is not a quick process and attacked organizations still have to cover extensive mitigation costs. 19% of attacks have been confirmed as resulting in canceled appointments, 14% saw patients redirected, and 80% have involved the exposure or a leak of sensitive data.

The CyberPeace Institute said some threat actors have specifically targeted the healthcare sector. One example provided was a member of the Groove ransomware operation who was actively seeking initial access brokers who could provide access to healthcare networks. The Groove ransomware operation had the highest percentage of healthcare targets than other sectors based on its data leak site.

Data from Mandiant have revealed 20% of ransomware victims are in the healthcare sector, suggesting the industry is being extensively targeted. The FIN 12 threat actor is known to target the healthcare sector, and ransomware operations such as Conti, Pysa, and Hive have high percentages of healthcare organizations in their lists of victims (4%, 9%, and 12% respectively).

While there has been some targeting of the healthcare sector, many ransomware gangs use spray and pray tactics and indiscriminately conduct attacks that result in healthcare organizations being attacked along with all other industry sectors. These attacks often involve indiscriminate phishing campaigns, attacks on Remote Desktop Protocol, (RDP), or brute force attacks to guess weak passwords.

“Regardless of whether the targeting of healthcare organizations is by mistake, design, or indifference, ransomware operators are acting with impunity and are de facto defining what organizations constitute legitimate targets and what is off-limits,” concluded the CyberPeace Institute. “Their simplistic distinctions ignore the complexities and interconnectedness of the healthcare sector, in which attacking pharmaceuticals during a pandemic can have an equally devastating human impact as attacking hospitals.”

The post New Data Reveals Extent of Ransomware Attacks on the Healthcare Sector appeared first on HIPAA Journal.

Third Version of Log4j Released to Fix High Severity DoS Vulnerability

The original vulnerability identified in Log4j (CVE-2021-44228) that sent shockwaves around the world due to its seriousness, ease of exploitation, and the extent to which it impacts software and cloud services, is not the only vulnerability in the Java-based logging utility.

After releasing version 2.15.0 to fix the flaw, it was determined that version 2.15.0 was still vulnerable in certain non-default configurations due to an incomplete patch. The new vulnerability is tracked as CVE-2021-45046 and was fixed in version 2.16.0 of Log4j. Initially, the vulnerability was assigned a CVSS score of 3.7 (low severity); however, the severity score has since been increased to critical (CVSS 9.0), as while this flaw was initially reported as a denial-of-service bug, it was later determined that it could be exploited to allow data exfiltration and remote code execution.

According to Apache, “When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.”

Apache strongly recommended organizations upgrade again to version 2.16.0 to prevent exploitation of the new vulnerability; however, a further vulnerability has now been identified, which is tracked as CVE-2021-45105. CVE-2021-45105 is a high severity DoS bug (CVSS 7.5) and affects all versions of Log4j from 2.0-beta9 to 2.16.0.

According to the Apache Software Foundation (ASF), “Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.”

CVE-2021-45105 has now been corrected in version 2.17.0, which is the third version of Log4j to be released in 10 days. Further information on the Log4j vulnerabilities and the latest updates can be found here.

The post Third Version of Log4j Released to Fix High Severity DoS Vulnerability appeared first on HIPAA Journal.

Learnings from a Major Healthcare Ransomware Attack

One of the most serious healthcare ransomware attacks occurred in Ireland earlier this year. The Health Service Executive (HSE), the Republic of Ireland’s national health system, suffered a major attack that resulted in Conti ransomware being deployed and forced its National Healthcare Network to be taken offline. That meant healthcare professionals across the country were prevented from accessing all HSE IT systems, including clinical care systems, patient records, laboratory systems, payroll, and other clinical and non-clinical systems which caused major disruption to healthcare services across the country.

Following the attack, the HSE Board commissioned PricewaterhouseCoopers (PWC) to conduct an independent post-incident review into the attack to establish the facts related to technical and operational preparedness and the circumstances that allowed the attackers to gain access to its systems, exfiltrate sensitive data, encrypt files, and extort the HSE.

Cybersecurity Failures that are Common in the Healthcare Industry

PWC’s recently published report highlights a number of security failures that allowed HSE systems to be infiltrated. While the report is specific to the HSE cyberattack, its findings are applicable to many healthcare organizations in the United States that have similar unaddressed vulnerabilities and a lack of preparedness for ransomware attacks. The recommendations made by PWC can be used to strengthen defenses to prevent similar attacks from occurring.

While the HSE ransomware attack affected a huge number of IT systems, it started with a phishing email. An employee was sent an email with a malicious Microsoft Excel spreadsheet as an attachment on March 16, 2021. When the attachment was opened, malware was installed on the device. The HSE workstation had antivirus software installed, which could have detected the malicious file and prevented the malware infection; however, the virus definition list had not been updated for over a year, which rendered the protection near to non-existent.

From that single infected device, the attacker was able to move laterally within the network, compromise several accounts with high-level privileges, gain access to large numbers of servers, and exfiltrate data ‘undetected’.  On May 14, 2021, 8 weeks after the initial compromise, Conti ransomware was extensively deployed and encrypted files. The HSE detected the encryption and shut down the National Health Network to contain the attack, which prevented healthcare professionals across the country from accessing applications and essential data.

During the 8 weeks that its systems were compromised, suspicious activity was detected on more than one occasion which should have triggered an investigation into a potential security breach, but those alerts were not acted upon. Had they been investigated the deployment of ransomware could have been prevented and potentially also the exfiltration of sensitive data.

Simple Techniques Used to Devastating Effect

According to PWC, the attacker was able to use well-known and simple attack techniques to move around the network, identify and exfiltrate sensitive data, and deploy Conti ransomware over large parts of the IT network with relative ease. The attack could have been far worse. The attacker could have targeted medical devices, destroyed data at scale, used auto-propagation mechanisms such as those used in the WannaCry ransomware attacks, and could also have targeted cloud systems.

The HSE made it clear that it would not be paying the ransom. On May 20, 2021, 6 days after the HSE shut down all HSE IT system access to contain the attack, the attackers released the keys to decrypt data. Had it not been for a strong response to the attack and the release of the decryption keys the implications could have been much more severe. Even with the keys to decrypt data it took until September 21, 2021, for the HSE to successfully decrypt all of its servers and restore around 99% of its applications. The HSE estimated the cost of the attack could rise to half a billion Euros.

Ireland’s Largest Employer Had No CISO

PWC said the attack was possible due to a low level of cybersecurity maturity, weak IT systems and controls, and staffing issues.  PWC said there was a lack of cybersecurity leadership, as there was no individual in the HSE responsible for providing leadership and direction of its cybersecurity efforts, which is very unusual for an organization with the size and complexity of the HSE. The HSE is Ireland’s largest employer and had over 130,000 staff members and more than 70,000 devices at the time of the attack, but the HSE only employed 1,519 staff in cybersecurity roles. PWC said employees with responsibility for cybersecurity did not have the necessary skills to perform the tasks expected of them and the HSE should have had a Chief Information Security Officer (CISO) with overall responsibility for cybersecurity.

Lack of Monitoring and Insufficient Cybersecurity Controls

The HSE did not have the capability to effectively monitor and respond to security alerts across its entire network, patching was sluggish and updates were not applied quickly across the IT systems connected to the National Health Network. The HSE was also reliant on a single anti-malware solution which was not being monitored or effectively maintained across its entire IT environment. The HSE also continued to use legacy systems with known security issues and remains heavily reliant on Windows 7.

“The HSE is operating on a frail IT estate that has lacked the investment over many years required to maintain a secure, resilient, modern IT infrastructure. It does not possess the required cybersecurity capabilities to protect the operation of the health services and the data they process, from the cyber attacks that all organizations face today,” concluded PWC. “It does not have sufficient subject matter expertise, resources, or appropriate security tooling to detect, prevent or respond to a cyber attack of this scale. There were several missed opportunities to detect malicious activity, prior to the detonation phase of the ransomware.”

Similar vulnerabilities in people, processes, and technology can be found in many health systems around the world, and the PWC recommendations can be applied beyond the HSE to improve cybersecurity and make it harder for attacks such as this to succeed.

The PWC report, recommendations, and learnings from the incident can be found here (PDF).

The post Learnings from a Major Healthcare Ransomware Attack appeared first on HIPAA Journal.

Max-Severity Apache Log4j Zero-day Vulnerability Extensively Exploited in the Wild

A maximum-severity vulnerability has been identified in Apache Log4j, an open-source Java-based logging library used by many thousands of organizations in their enterprise applications and by many cloud services.

The vulnerability, dubbed Log4Shell and tracked as CVE-2021-44228, is serious as they come, with some security researchers claiming the flaw is the most serious to be discovered in the past decade due to its ease of exploitation and the sheer number of enterprise applications and cloud services that are affected.

The vulnerability can be exploited without authentication to achieve remote code execution and take full control of vulnerable systems. The vulnerability affects Apache Log4j between versions 2.0 to 2.14.1, and has been fixed in version 2.15.0.

The advice is to ensure the upgrade is performed immediately as a proof-of-concept exploit for the flaw is in the public domain, extensive scans are being performed for vulnerable systems, and there have been many cases of the flaw being exploited in the wild. Some reports suggest the improper input validation bug has been exploited in the wild for some time before it was discovered by researchers at Alibaba Cloud on November 24.

The vulnerability was first detected being exploited against Minecraft, which still uses Java, although many web apps and business applications use Java and are vulnerable to attack and the vulnerability affects multiple Apache frameworks such as Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, and others.

The vulnerability can be exploited by manipulating log messages to execute arbitrary code from LDAP servers when message lookup substitution is enabled. This is a Java deserialization issue due to the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing code that’s returned. By manipulating the log messages to trigger a look-up to an attacker-controlled server, an attacker can execute code on the victim’s system. Exploiting the bug requires the attacker to get a vulnerable application to log a special string, which is trivial for threat actors and requires a single line of code.

According to UK security researcher Marcus Hutchins, threat actors attacked Minecraft servers by simply pasting a short message into the chatbox. The bug is known to have been exploited to deploy cryptocurrency miners, to install botnet code on IoT devices, and initial access brokers have been scrambling to exploit the code, so it is inevitable that it will provide the initial access to allow ransomware attacks.

“I cannot overstate the seriousness of this threat. On the face of it, this is aimed at cryptominers but we believe this creates just the sort of background noise that serious threat actors will try to exploit in order to attack a whole range of high-value targets such as banks, state security, and critical infrastructure,” explained Lotem Finkelstein, director of threat intelligence and research at Check Point.

If it is not possible to immediately update to version 2.15.0, there are mitigations that can prevent exploitation in version 2.10.0 and later. A vulnerability “vaccine” has been released by Cybereason that can be used to protect against exploitation by using the vulnerability to run code that changes the settings to prevent further exploitation. The vaccine could be used to gain some time, although the best option is to update to the latest Apache Log4j version.

The vulnerable code could be anywhere, so fixing the issue is not likely to be straightforward, although Huntress has released a tool that can be used to check if applications are affected – available here.

Mitigations that can be applied if the update cannot be easily performed have been released by Apache. “In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.”

Since there have been many cases of the flaw being exploited, it is important to not only fix the vulnerability but to also assume the flaw has already been exploited and to check logs for any unusual activity after systems and applications have been secured.

The post Max-Severity Apache Log4j Zero-day Vulnerability Extensively Exploited in the Wild appeared first on HIPAA Journal.

Max-Severity Apache Log4j Zero-day Vulnerability Extensively Exploited in the Wild

A maximum-severity vulnerability has been identified in Apache Log4j, an open-source Java-based logging library used by many thousands of organizations in their enterprise applications and by many cloud services.

The vulnerability, dubbed Log4Shell and tracked as CVE-2021-44228, is serious as they come, with some security researchers claiming the flaw is the most serious to be discovered in the past decade due to its ease of exploitation and the sheer number of enterprise applications and cloud services that are affected.

The vulnerability can be exploited without authentication to achieve remote code execution and take full control of vulnerable systems. The vulnerability affects Apache Log4j between versions 2.0 to 2.14.1, and has been fixed in version 2.15.0.

The advice is to ensure the upgrade is performed immediately as a proof-of-concept exploit for the flaw is in the public domain, extensive scans are being performed for vulnerable systems, and there have been many cases of the flaw being exploited in the wild. Some reports suggest the improper input validation bug has been exploited in the wild for some time before it was discovered by researchers at Alibaba Cloud on November 24.

The vulnerability was first detected being exploited against Minecraft, which still uses Java, although many web apps and business applications use Java and are vulnerable to attack and the vulnerability affects multiple Apache frameworks such as Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, and others.

The vulnerability can be exploited by manipulating log messages to execute arbitrary code from LDAP servers when message lookup substitution is enabled. This is a Java deserialization issue due to the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing code that’s returned. By manipulating the log messages to trigger a look-up to an attacker-controlled server, an attacker can execute code on the victim’s system. Exploiting the bug requires the attacker to get a vulnerable application to log a special string, which is trivial for threat actors and requires a single line of code.

According to UK security researcher Marcus Hutchins, threat actors attacked Minecraft servers by simply pasting a short message into the chatbox. The bug is known to have been exploited to deploy cryptocurrency miners, to install botnet code on IoT devices, and initial access brokers have been scrambling to exploit the code, so it is inevitable that it will provide the initial access to allow ransomware attacks.

“I cannot overstate the seriousness of this threat. On the face of it, this is aimed at cryptominers but we believe this creates just the sort of background noise that serious threat actors will try to exploit in order to attack a whole range of high-value targets such as banks, state security, and critical infrastructure,” explained Lotem Finkelstein, director of threat intelligence and research at Check Point.

If it is not possible to immediately update to version 2.15.0, there are mitigations that can prevent exploitation in version 2.10.0 and later. A vulnerability “vaccine” has been released by Cybereason that can be used to protect against exploitation by using the vulnerability to run code that changes the settings to prevent further exploitation. The vaccine could be used to gain some time, although the best option is to update to the latest Apache Log4j version.

The vulnerable code could be anywhere, so fixing the issue is not likely to be straightforward, although Huntress has released a tool that can be used to check if applications are affected – available here.

Mitigations that can be applied if the update cannot be easily performed have been released by Apache. “In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.”

Since there have been many cases of the flaw being exploited, it is important to not only fix the vulnerability but to also assume the flaw has already been exploited and to check logs for any unusual activity after systems and applications have been secured.

The post Max-Severity Apache Log4j Zero-day Vulnerability Extensively Exploited in the Wild appeared first on HIPAA Journal.

High-Severity Authentication Bug Identified in Hillrom Welch Allyn Cardio Products

A high severity vulnerability has been identified in certain Hillrom Welch Allyn Cardio products that allows accounts to be accessed without a password.

The vulnerability is an authentication bypass issue that exists when the Hillrom cardiology products have been configured to use single sign-on (SSO). The vulnerability allows the manual entry of all active directory (AD) accounts provisioned within the application, and access will be granted without having to provide the associated password. That means a remote attacker could access the application under the provided AD account and gain all privileges associated with the account.

The vulnerability is tracked as CVE-2021-43935 and has been assigned a CVSS v3 base score of 8.1 out of 10.

According to Hillrom, the vulnerability affects the following Hillrom Welch Allyn cardiology products:

  • Welch Allyn Q-Stress Cardiac Stress Testing System: Versions 6.0.0 through 6.3.1
  • Welch Allyn X-Scribe Cardiac Stress Testing System: Versions 5.01 through 6.3.1
  • Welch Allyn Diagnostic Cardiology Suite: Version 2.1.0
  • Welch Allyn Vision Express: Versions 6.1.0 through 6.4.0
  • Welch Allyn H-Scribe Holter Analysis System: Versions 5.01 through 6.4.0
  • Welch Allyn R-Scribe Resting ECG System: Versions 5.01 through 7.0.0
  • Welch Allyn Connex Cardio: Versions 1.0.0 through 1.1.1

Hillrom will address this vulnerability in the next software release; however, as an interim measure to prevent the vulnerability from being exploited, users of the affected products should disable the SSO feature in the respective Modality Manager Configuration settings. In addition, customers should ensure they apply proper network and physical security controls and should apply authentication for server access.

The post High-Severity Authentication Bug Identified in Hillrom Welch Allyn Cardio Products appeared first on HIPAA Journal.

SonicWall Recommends Immediate Firmware Upgrade to Fix Critical Flaws in SMA 100 Series Appliances

SonicWall has released new firmware for its Secure Mobile Access (SMA) 100 series remote access appliances that fixes 8 vulnerabilities including 2 critical and 4 high-severity flaws.

Vulnerabilities in SonicWall appliances are attractive to threat actors and have been targeted in the past in ransomware attacks. While there are currently no known cases of the latest batch of vulnerabilities being exploited in the wild, there is a high risk of these vulnerabilities being exploited if the firmware is not updated promptly. SMA 100 series appliances include the SonicWall SMA 200, 210, 400, 410, and 500v secure access gateway products, all of which are affected.

The most serious vulnerabilities are buffer overflow issues which could be exploited remotely by an unauthenticated attacker to execute code on vulnerable appliances. These are CVE-2021-20038, an unauthenticated stack-based buffer overflow vulnerability (CVSS score of 9.8), and CVE-2021-20045, which covers multiple unauthenticated file explorer heap-based and stack-based buffer overflow issues (CVSS score 9.4). A further heap-based buffer overflow vulnerability – CVE-2021-20043 – allows remote code execution, although an attacker would need to be authenticated (CVSS score 8.8).

The remaining 3 high-severity vulnerabilities are CVE-2021-20041 – an unauthenticated CPU exhaustion vulnerability (CVSS score 7.5); CVE-2021-20039 – an authenticated command injection vulnerability (CVSS score 7.2); and CVE-2021-20044 – a post-authentication remote code execution vulnerability (CVSS score 7.2).

Two medium-severity vulnerabilities have also been fixed: CVE-2021-20040 – an unauthenticated file upload path traversal vulnerability (CVSS score 6.5) and CVE-2021-20042 – an unauthenticated ‘confused deputy’ vulnerability (CVSS score 6.3).

The firmware update can be accessed at MySonicWall.com and should be applied as soon as possible to prevent exploitation. SonicWall says there are no temporary mitigations that can be implemented to prevent exploitation of the flaws.

The post SonicWall Recommends Immediate Firmware Upgrade to Fix Critical Flaws in SMA 100 Series Appliances appeared first on HIPAA Journal.

Guidance Issued for Healthcare CISOs on Identity, Interoperability, and Patient Access

The Health Information Sharing and Analysis Center (Health-ISAC) has released guidance for Chief Information Security Officers (CISOs) on adopting an identity-centric approach to enabling secure and easy access to patient data to meet the interoperability, patient access, and data sharing requirements of the 21st Century Cures Act.

New federal regulations tied to the 21st Century Cures Act call for healthcare organizations to provide patients with easy access to their healthcare data and ensure patients can easily share their electronic health information (EHI) data wherever, whenever, and with whomever they want. The failure of a healthcare organization to implement systems to support patient access and interoperability could be considered information blocking and would be subject to fines and penalties.

The new federal requirements are for healthcare providers and insurers to allow data sharing through Application Programming Interfaces (APIs) that operate on the Fast Healthcare Interoperability and Resources (FHIR) standard. Healthcare providers and insurers are required to establish APIs to allow patients to access their EHI; however, providing patients with easy access to their healthcare data has the potential to introduce security vulnerabilities.

Health-ISAC says that in order to provide easy access to patient data, multiple privacy, security, and usability challenges need to be addressed, all of which are rooted in identity. When users request access to their data, strong authentication controls must be in place to verify that the person requesting EHI is who they say they are. For many years, patient matching problems have plagued the healthcare industry, and without a national patient identifier, those problems exist to this day. Those issues must also be addressed to ensure the correct EHI is provided.  Also, if an individual wants to only share part of their EHI, it needs to be possible for a portion of the data to be easily shared.

H-ISAC Framework for Managing Identity

Health-ISAC suggests a Framework for Managing Identity (above) that covers all of those functions; however, privacy and security issues also need to be addressed. For example, if a patient wants to authorize the use of EHI on behalf of someone else that he/she cares for, such as an elderly relative or a minor child, that must be possible. It must also be possible for a patient to delegate access privileges if they are being cared for by someone else, and for appropriate authentication controls to be in place to accommodate such requests. API-level security is also required. FHIR APIs are in the public domain, so they must be secured after authorization to use is granted.

Health-ISAC suggests that healthcare organizations should adopt an identity-centric approach to data sharing to solve these issues. “The most effective way of mitigating the risk that these issues pose to organizations is through the implementation of a modern, robust, and secure identity infrastructure that can securely authenticate and authorize users and incoming requests, enforce the appropriate consent requests, and tightly govern the use of identities,” said Health-ISAC. “By design, this is exactly what the Health-ISAC framework is meant to achieve.”

Additionally, Health-ISAC strongly recommends implementing multi-factor authentication, as while this is not explicitly required by the new ONC and CMS Rules, guidance issued by the government strongly points to the use of MFA. There are risks associated with not implementing MFA due to its importance for authentication.  The HHS’ Office for Civil Rights (OCR) has fined health organizations for HIPAA violations related to inadequate authentication in the past. Health-ISAC has produced a white paper – All About Authentication – which explains the best approach for implementing MFA.

“Identity is a journey. As the healthcare industry focuses on digital adoption, identity will continue to play a foundational role. Whether your implementation of a modern identity system is driven by regulatory and compliance requirements, security and privacy concerns, or a desire to improve customer experience, a well-architected, robust digital identity solution can address all of these drivers,” concludes Health-ISAC.

The post Guidance Issued for Healthcare CISOs on Identity, Interoperability, and Patient Access appeared first on HIPAA Journal.