Healthcare Data Security

August 2020 Healthcare Data Breach Report

Posted by HIPAA Journal

37 healthcare data breaches of 500 or more records were reported to the HHS’ Office for Civil Rights in August 2020, one more than July 2020 and one below the 12-month average.

The number of breaches remained fairly constant month-over-month, but there was a 63.9% increase in breached records in August. 2,167,179 records were exposed, stolen, or impermissibly disclosed in August. The average breach size of 58,572 records and the median breach size was 3,736 records.

 

 

Largest Healthcare Data Breaches Reported in August 2020

 

Name of Covered Entity Covered Entity Type Individuals Affected Type of Breach Location of Breached PHI Incident
Northern Light Health Business Associate 657,392 Hacking/IT Incident Network Server, Other Blackbaud ransomware attack
Saint Luke’s Foundation Healthcare Provider 360,212 Hacking/IT Incident Network Server Blackbaud ransomware attack
Assured Imaging Healthcare Provider 244,813 Hacking/IT Incident Network Server Ransomware attack
MultiCare Health System Healthcare Provider 179,189 Hacking/IT Incident Network Server Blackbaud ransomware attack
Imperium Health LLC Business Associate 139,114 Hacking/IT Incident Email Phishing attack
University of Florida Health Healthcare Provider 135,959 Hacking/IT Incident Network Server Blackbaud ransomware attack
Utah Pathology Services, Inc. Healthcare Provider 112,124 Hacking/IT Incident Email Phishing attack
Dynasplint Systems, Inc. Healthcare Provider 102,800 Hacking/IT Incident Network Server Ransomware attack
Main Line Health Healthcare Provider 60,595 Hacking/IT Incident Network Server Blackbaud ransomware attack
Northwestern Memorial HealthCare Healthcare Provider 55,983 Hacking/IT Incident Network Server Blackbaud ransomware attack
Richard J. Caron Foundation Healthcare Provider 22,718 Hacking/IT Incident Network Server Blackbaud ransomware attack
UT Southwestern Medical Center Healthcare Provider 15,958 Unauthorized Access/Disclosure Other Unconfirmed
City of Lafayette Fire Department Healthcare Provider 15,000 Hacking/IT Incident Network Server Ransomware attack
Hamilton Health Center, Inc. Healthcare Provider 10,393 Unauthorized Access/Disclosure Email Misdirected Email

 

Causes of August 2020 Healthcare Data Breaches

Hacking/IT incidents dominated the breach reports in August, with the 24 reported incidents making up 64.9% of the month’s data breaches. 2,127,070 records were compromised in those breaches, which is 98.15% of all records breached in August. The average breach size was 88,628 records and the median breach size was 11,550 records.

There were 8 unauthorized/access disclosure incidents involving 32,205 records. The average breach size was 4,026 records and the median breach size was 992 records. There were 5 loss (2) and theft (3) incidents reported. The average breach size was 1,581 records and the median breach size was 1,768 records.

While phishing attacks usually dominate the healthcare data breach reports, in August, attacks on network servers were more common. The increase in network server attacks is largely due to ransomware attacks, notably, an attack on Blackbaud, a business associate of many healthcare organizations in the United States. Blackbaud offers a range of services to healthcare providers, including patient engagement and digital data storage related to donors and philanthropy.

Between February 7, 2020 and May 20, 2020, hackers had access to Blackbaud’s systems and obtained backups of several of its clients’ databases before deploying ransomware. Blackbaud paid the ransom to ensure data stolen in the attack were destroyed.

Only a small percentage of its clients were affected by the attack, but so far at least 52 healthcare organizations have confirmed that their donor data were compromised in the attack. We have data for 17 of those attacks and so far, more than 3 million individuals are known to have been affected. That number is likely to grow significantly over the next few weeks now the deadline for reporting the breach is approaching.

There were also two major phishing incidents reported in August. Imperium Health suffered an attack in which the records of 139, 114 individuals were potentially compromised, and Utah Pathology Services suffered an attack involving the records of 112,124 individuals.

Healthcare Data Breaches by Covered Entity Type

Healthcare providers were the worst affected covered entity with 24 data breaches reported in August. Three breaches were reported by health plans and five breaches were reported by business associates; however, a further 9 breaches had some business associate involvement.

States Affected by August 2020 Data Breaches

Data breaches were reported by entities in 24 states in August. Pennsylvania was the worst affected state with 6 breaches of 500 or more healthcare records, followed by Kentucky with 4, Texas with 3, and Arizona, Ohio, and Washington with 2.  One breach was reported in each of Arkansas, California, Colorado, Connecticut, Florida, Iowa, Idaho, Illinois, Indiana, Maryland, Maine, Michigan, Missouri, New York, Oklahoma, South Carolina, Utah, and Wisconsin.

HIPAA Enforcement Activity in August 2020

There were no HIPAA enforcement actions announced in August by either the HHS Office for Civil Rights or state attorneys general.

The post August 2020 Healthcare Data Breach Report appeared first on HIPAA Journal.

Senators Demand Answers from VA on 46,000-Record Data Breach

Posted by HIPAA Journal

On September 14, 2020, the U.S. Department of Veteran Affairs announced it had suffered a data breach that had impacted 46,000 veterans. Several Senate Democrats are now demanding answers from the VA on the breach and the cybersecurity measures the VA has put in place to prevent data breaches.

Hackers gained access to an application used by the VA’s Financial Services Center to send payments to community healthcare providers to pay for veterans’ medical care. Six payments intended for community care providers were redirected to bank accounts under the control of the hackers and veterans’ data in the system was exposed and potentially stolen.

When the breach was discovered, the application was taken offline and will remain down until a full review has been conducted by the VA’s Office of Information and Technology. Affected veterans have been offered complimentary credit monitoring services and the VA is currently working on compensating the community care providers whose payments were redirected.

Officials at the VA Office of Information and Technology told Senate and House veterans’ affairs committees that approximately 17,000 community care providers were affected by the breach, although the VA has now said that while 17,000 community care providers use the application, only 13 were affected.

In a letter to VA Secretary Robert Wilkie, Sens John Tester, Patty Murray, Sherrod Brown, Richard Blumenthal, Mazie K. Hirono, Joe Manchin III, Kyrsten Sinema, Margaret Wood Hassan, and Jeanne Shaheen expressed “serious concerns” about the ability of the VA to protect veterans’ and community care providers’ data and called for the VA to provide assurances that the department is capable of safeguarding personal and financial data.

“Based on information currently available, it appears this cybersecurity incident was carried out by those able to find weaknesses in the way VA authenticates community care health care providers using VCAs and processes payments for their services,” said the Senators.

“This incident raises numerous concerns not just for this incident, but more broadly with how VA is approaching protecting the PII and other important data within its vast data systems and networks,” wrote the Senators. “This is not a new vulnerability for VA. Rather, it is a long-standing weakness of the Department as identified by independent reviews conducted by the VA OIG and the Government Accountability Office (GAO) for more than 10 years.”

The Senators reference two GAO reports from June 2019 and July 2019 that make several recommendations for agencies on cybersecurity, risk management and data protection, including recommendations specifically for the VA. They have called for the VA to provide information on the current status of the VA’s efforts to implement those recommendations.

The Senators have called for the VA to provide a state-level breakdown of all impacted community care providers and to provide information on the steps that have been taken to assure community care providers and veterans that their personal and financial data will be secure. The Senators want to know who discovered the breach – whether it was the VA or the VA Office of Inspector General. They also requested information on the systems used by the VA Financial Services Center.

The Senators also raised concern that the VA is in a reactive posture waiting for cybersecurity vulnerabilities to arise and want to know what proactive assessments have been conducted to identify vulnerabilities, the frequency of those assessments, and what steps the VA will take to ensure greater oversight of business rules and IT and cybersecurity processes to ensure vulnerabilities are identified and addressed before they are exploited.

“This most recent data breach is unacceptable. It also exposes the fact that VA has not taken the necessary steps to ensure oversight, accountability, and security of the vast financial, health, and other personal data it collects and processes to perform its critical services for America’s veterans,” wrote the Senators. “It is imperative VA take aggressive and decisive action to address this current incident and lay out a strategy to prevent such problems from arising in the future.”

The post Senators Demand Answers from VA on 46,000-Record Data Breach appeared first on HIPAA Journal.

Hospital Ransomware Attack Results in Patient Death

Posted by HIPAA Journal

Ransomware attacks on hospitals pose a risk to patient safety. File encryption results in essential systems crashing, communication systems are often taken out of action, and clinicians can be prevented from accessing patients’ medical records.

Highly disruptive attacks may force hospitals to redirect patients to alternate facilities, which recently happened in a ransomware attack on the University Clinic in Düsseldorf, Germany. One patient who required emergency medical treatment for a life threatening condition had to be rerouted to an alternate facility in Wuppertal, approximately 20 miles away. The redirection resulted in a one-hour delay in receiving treatment and the patient later died. The death could have been prevented had treatment been provided sooner.

The attack occurred on September 10, 2020 and completely crippled the clinic’s systems. Investigators determined that the attackers exploited a vulnerability in “widely used commercial add-on software” to gain access to the network. As the encryption process ran, hospital systems started to crash and medical records could not be accessed.

The medical clinic was forced to de-register from emergency care, postponed appointments and outpatient care, and all patients were advised not to visit the medical clinic until the attack was remediated. A week later and normal function at the hospital has still not resumed, although the hospital is now starting to restart essential systems.

According to a recent Associated Press report, 30 servers at the hospital were affected. A ransom demand was found on one of the encrypted servers. The hospital alerted law enforcement which made contact with the attackers using the information in the ransom note.

It would appear that the attackers did not intend on attacking the hospital, as the ransom note was addressed to Heinrich Heine University in Düsseldorf, to which the medical clinic is affiliated. Law enforcement officials made contact with the attackers using the information in the ransom note and told the attackers that the hospital had been affected and patient safety was at risk.

The attackers supplied the keys to decrypt files and made no further attempts to extort money. No further contact has been possible with the attackers. Law enforcement is continuing to investigate and it is possible that charges of manslaughter could be brought against the attackers.

Until now there have been no confirmed cases of ransomware attacks on healthcare facilities resulting in the death of a patient, but when attacks cripple hospital systems and patients are prevented from receiving treatment for life threatening conditions, such tragic events are sadly inevitable.

Several ransomware gangs have publicly stated that they will not conduct attacks on medical facilities, and if hospital systems are affected, keys to decrypt files will be provided free of charge. However, even if keys are provided to decrypt files, recovery from an attack is not a quick process. Other ransomware operations have made no such concessions and continue to attack healthcare facilities.

The post Hospital Ransomware Attack Results in Patient Death appeared first on HIPAA Journal.

Resources to Help Healthcare Organizations Improve Resilience Against Insider Threats

Posted by HIPAA Journal

September 2020 is the second annual National Insider Threat Awareness Month (NITAM). Throughout the month, resources are being made available to emphasize the importance of detecting, deterring, and reporting insider threats.

NITAM is a collaborative effort between several U.S. government agencies including the National Counterintelligence and Security Center (NCSC), Office of the Under Secretary of Defense Intelligence and Security (USD(I&S)), National Insider Threat Task Force (NITTF), Department of Homeland Security (DHS), and the Defense Counterintelligence and Security Agency (DCSA). NITAM was devised last year to raise awareness of the risks posed by insiders and to encourage organizations to take action to manage those risks.

Security teams often concentrate on protecting their networks, data, and resources from hackers and other external threat actors, but it is also important to protect against insider threats. An insider is an individual within an organization who has been granted access to hardware, software, data, or knowledge about an organization. Insiders include current and former employees, contractors, interns, and other individuals who have been given access to data or systems. Those trusted insiders could accidentally or deliberately take actions which are disruptive to the business. Those actions could cause damage to company facilities, systems, or equipment, result in financial harm, or expose or disclose intellectual property and sensitive data.

To combat insider threats, organizations need to establish an insider threat mitigation program to detect, deter, and respond to threats from malicious and unintentional insiders. The program should protect critical assets against unauthorized access and malicious acts, and the workforce should be trained how to identify insider threats and conditioned to report any suspicious behavior or activities. The program should also involve the collection and analysis of information to help identify and mitigate insider threats quickly.

The SARS-CoV-2 pandemic has created a new set of challenges. The changes made by organizations in response to the pandemic, such as the expansion of remote working to include the entire workforce, has increased the risk of espionage, unauthorized disclosures, fraud, and data theft. It is more important than ever for organizations to have an effective insider threat mitigation program.

The main focus of NITAM 2020 is improving resilience to insider threats. This can be achieved by improving awareness through education of the workforce, using the resources made available in September to learn how to detect and mitigate the actions of insider threats, and to improve protection against those threats.

The DHS Cybersecurity and Infrastructure Security Agency (CISA) is helping to raise awareness of insider threats and has published resources that can be used by healthcare organizations to improve organizational resilience and mitigate risks posed by insider threats. Games, videos, graphics, posters, and case studies to promote NITAM are available here.

The post Resources to Help Healthcare Organizations Improve Resilience Against Insider Threats appeared first on HIPAA Journal.

OCR Publishes New Resources for MHealth App Developers and Cloud Services Providers

Posted by HIPAA Journal

The Department of Health and Human Services’ Office for Civil Rights has announced it has published additional resources for mobile health app developers and has updated and renamed its Health App Developer Portal.

The portal – Resources for Mobile Health Apps Developers – provides guidance for mobile health app developers on the HIPAA Privacy, Security, and Breach Notification Rules and how they apply to mobile health apps and application programming interfaces (APIs).

The portal includes a guidance document on Health App Use Scenarios and HIPAA, which explains when mHealth applications must comply with the HIPAA Rules and if an app developer will be classed as a business associate.

“Building privacy and security protections into technology products enhances their value by providing some assurance to users that the information is secure and will be used and disclosed only as approved or expected,” explained OCR. “Such protections are sometimes required by federal and state laws, including the HIPAA Privacy, Security, and Breach Notification Rules.”

The portal provides access to the Mobile Health Apps Interactive Tool developed by the Federal Trade Commission (FTC) in conjunction with the HHS’ Office of the National Coordinator for Health IT (ONC) and the Food and Drug Administration (FDA). The Tool can be used by the developers of health-related apps to determine what federal rules are likely to apply to their apps. By answering questions about the nature of the apps, developers will discover which federal rules apply and will be directed to resources providing more detailed information about each federal regulation.

The portal also includes information on patient access rights under HIPAA, how they apply to the data collected, stored, processed, or transmitted through mobile health apps, and how the HIPAA Rules apply to application programming interfaces (APIs).

The update to the portal comes a few months after the ONC’s final rule that called for health IT developers to establish a secure, standards-based API that providers could use to support patient access to the data stored in their electronic health records. While it is important for patients to be able to have easy access to their health data to allow them to check for errors, make corrections, and share their health data for research purposes, there is concern that sending data to third-party applications, which may not be covered by HIPAA, is a privacy risk.

OCR has previously confirmed that once healthcare providers have shared a patients’ health data with a third-party app, as directed by the patient, the data will no longer be covered by HIPAA if the app developer is not a business associate of the healthcare provider. Healthcare providers will not be liable for any subsequent use or disclosure of any electronic protected health information shared with the app developer.

A FAQ is also available on the portal that explains how HIPAA applies to Health IT and a guidance document explaining how HIPAA applies to cloud computing to help cloud services providers (CSPs) understand their responsibilities under HIPAA.

The post OCR Publishes New Resources for MHealth App Developers and Cloud Services Providers appeared first on HIPAA Journal.

OCR Highlights the Importance of Creating and Maintaining a Comprehensive IT Asset Inventory

Posted by HIPAA Journal

The risk analysis is one of the most important requirements of the HIPAA Security Rule, yet it is one of the most common areas of noncompliance discovered during Office for Civil Rights data breach investigations, compliance reviews, and audits. While there have been examples of HIPAA-covered entities ignoring this requirement entirely, in many cases noncompliance is due to the failure to perform a comprehensive risk analysis across the entire organization.

In order to perform a comprehensive risk analysis to identity all threats to the confidentiality, integrity, and availability of electronic protected health information (ePHI), you must first know how ePHI arrives in your organization, where it flows, where all ePHI is stored, and the systems that can be used to access that information. One of the common reasons for a risk analysis compliance failure, is not knowing where all ePHI is located in the organization.

In its Summer 2020 Cybersecurity Newsletter, OCR highlighted the importance of maintaining a comprehensive IT asset inventory and explains how it can assist with the risk analysis process. An IT asset inventory is a detailed list of all IT assets in an organization, which should include a description of each asset, serial numbers, names, and other information that can be used to identify the asset, version (operating system/application), its location, and the person to whom the asset has been assigned and who is responsible for maintaining it.

“Although the Security Rule does not require it, creating and maintaining an up-to-date, information technology (IT) asset inventory could be a useful tool in assisting in the development of a comprehensive, enterprise-wide risk analysis, to help organizations understand all of the places that ePHI may be stored within their environment, and improve their HIPAA Security Rule compliance,” explained OCR in the newsletter.

An IT asset inventory should not only include physical hardware such as mobile devices, servers, peripherals, workstations, removable media, firewalls, and routers. It is also important to list software assets and applications that run on an organization’s hardware, such as anti-malware tools, operating systems, databases, email, administrative and financial records systems, and electronic medical/health record systems.

IT solutions such as backup software, virtual machine managers/hypervisors, and other administrative tools should also be included, as should data assets that include ePHI that an organization creates, receives, maintains, or transmits on its network, electronic devices, and media.

“Understanding one’s environment – particularly how ePHI is created and enters an organization, how ePHI flows through an organization, and how ePHI leaves an organization – is crucial to understanding the risks ePHI is exposed to throughout one’s organization.”

For smaller healthcare organizations, an IT asset inventory can be created and maintained manually, but for larger, more complex organizations, dedicated IT Asset Management (ITAM) solutions are more appropriate. These solutions include automated discovery and update processes for asset and inventory management and will help to ensure that no assets are missed.

When creating an IT asset inventory to aid the risk analysis, it is useful to include assets that are not used to create, receive, process, or transmit ePHI, but may be used to gain access to ePHI or to networks or devices that store ePHI.  IoT devices may not store or be used to access ePHI, but they could be used to gain access to a network or device that would allow ePHI to be viewed.

“Unpatched IoT devices with known vulnerabilities, such as weak or unchanged default passwords installed in a network without firewalls, network segmentation, or other techniques to deny or impede an intruder’s lateral movement, can provide an intruder with a foothold into an organization’s IT network,” suggests OCR. “The intruder may then leverage this foothold to conduct reconnaissance and further penetrate an organization’s network and potentially compromise ePHI.” There have been multiple incidents where hackers have exploited a vulnerability in one of these devices to penetrate an organization’s network and access sensitive data.

Organizations that do not have a comprehensive IT asset inventory could have gaps in recognition and mitigation of risks to ePHI. Only with a comprehensive understanding of the entire organization’s environment will it be possible to minimize those gaps and ensure that an accurate and thorough risk analysis is performed to ensure Security Rule compliance.

Maintaining an IT asset inventory may not be a Security Rule requirement but covered entities must create policies and procedures that govern the receipt and removal of hardware and electronic media that contain ePHI into and out of a facility. An IT asset inventory can also be used for this purpose. The IT asset inventory can also be compared with the results of network scanning and mapping processes to help identify unauthorized devices that have been connected to the network and used as part of vulnerability management to ensure that no devices, software, or other assets are missed when performing software updates and applying security patches.

The NIST Cybersecurity Framework can be leveraged to assist with the creation of an IT asset inventory. NIST has also produced guidance on IT asset management in its Cybersecurity Practice Guide, Special Publication 1800-5. The HHS Security Risk Assessment Tool can also help with IT asset management. It includes inventory capabilities that allow for manual entry or bulk loading of asset information with respect to ePHI.

The post OCR Highlights the Importance of Creating and Maintaining a Comprehensive IT Asset Inventory appeared first on HIPAA Journal.

Study Reveals Increase in Credential Theft via Spoofed Login Pages

Posted by HIPAA Journal

A new study conducted by IRONSCALES shows there has been a major increase in credential theft via spoofed websites. IRONSCALES researchers spent the first half of 2020 identifying and analyzing fake login pages that imitated major brands. More than 50,000 fake login pages were identified with over 200 brands spoofed.

The login pages are added to compromised websites and other attacker-controlled domains and closely resemble the genuine login pages used by those brands. In some cases, the fake login is embedded within the body of the email.

The emails used to direct unsuspecting recipients to the fake login pages use social engineering techniques to convince recipients to disclose their usernames and passwords, which are captured and used to login to the real accounts for a range of nefarious purposes such as fraudulent wire transfers, credit card fraud, identity theft, data extraction, and more.

IRONSCALES researchers found the brands with the most fake login pages closely mirrored the brands with the most active phishing websites. The brand with the most fake login pages – 11,000 – was PayPal, closely followed by Microsoft with 9,500, Facebook with 7,500, eBay with 3,000, and Amazon with 1,500 pages.

While PayPal was the most spoofed brand, fake Microsoft login pages pose the biggest threat to businesses. Stolen Office 365 credentials can be used to access corporate Office 365 email accounts which can contain a range of highly sensitive data and, in the case of healthcare organizations, a considerable amount of protected health information.

Other brands that were commonly impersonated include Adobe, Aetna, Alibaba, Apple, AT&T, Bank of America, Delta Air Lines, DocuSign, JP Morgan Chase, LinkedIn, Netflix, Squarespace, Visa, and Wells Fargo.

The most common recipients of emails in these campaigns with individuals working in the financial services, healthcare and technology industries, as well as government agencies.

Around 5% of the fake login pages were polymorphic, which for one brand included more than 300 permutations. Microsoft login pages had the highest degree of polymorphism with 314 permutations. The reason for the high number of permutations of login pages is not fully understood. IRONSCALES suggests this is because Microsoft and other brands are actively searching for fake login pages imitating their brand. Using many different permutations makes it harder for human and technical controls to identify and take down the pages.

The emails used in these campaigns often bypass security controls and are delivered to inboxes. “Messages containing fake logins can now regularly bypass technical controls, such as secure email gateways and SPAM filters, without much time, money or resources invested by the adversary,” explained IRONSCALES. “This occurs because both the message and the sender are able to pass various authentication protocols and gateway controls that look for malicious payloads or known signatures that are frequently absent from these types of messages.”

Even though the fake login pages differ slightly from the login pages they spoof, they are still effective and often successful if a user arrives at the page. IRONSALES attributes this to “inattentional blindness”, where individuals fail to perceive an unexpected change in plain sight.

The post Study Reveals Increase in Credential Theft via Spoofed Login Pages appeared first on HIPAA Journal.

New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers

Posted by HIPAA Journal

A new peer-to-peer (P2) botnet has been discovered that is targeting SSH servers found in IoT devices and routers which accept connections from remote computers. The botnet, named FritzFrog, spreads like a computer worm by brute forcing credentials.

The botnet has been analyzed by security researchers at Guardicore Labs and was found to have successfully breached more than 500 servers, with that number growing rapidly. FritzFrog is modular, multi-threaded, and fileless, and leaves no trace on the machines it infects. FritzFrog assembles and executes malicious payloads entirely in the memory, making infections hard to detect.

When a machine is infected, a backdoor is created in the form of an SSH public key, which provides the attackers with persistent access to the device. Additional payloads can then be downloaded, such as a cryptocurrency miner. Once a machine is compromised, the self-replicating process starts to execute the malware throughout the host server. The machine is added to the P2P network, can receive and execute commands sent from the P2P network, and is used to propagate the malware to new SSH servers. The botnet has been active since at least January 2020 and has been used to target government, healthcare, education, and the finance sectors.

“Nodes in the FritzFrog network keep in close contact with each other. They constantly ping each other to verify connectivity, exchange peers and targets and keep each other synced,” explained the researchers. “The nodes participate in a clever vote-casting process, which appears to affect the distribution of brute-force targets across the network. Guardicore Labs observed that targets are evenly distributed, such that no two nodes in the network attempt to “crack” the same target machine.”

In contrast to other forms of botnet, FritzFrog has greater resiliency, as control of the botnet is decentralized among different nodes, so there is no single command and control (C2) server, which means there can be no single point of failure. According to Guardicore Labs, FritzFrog has been written in Golang from scratch, with the P2P protocol completely proprietary, with almost everything about the botnet unique and not shared with other P2P botnets.

To analyze how FritzFrog worked and to explore its capabilities, Guardicore Labs’ researchers developed an interceptor in Golang which allowed them to participate in the malware’s key-exchange process and receive and send commands. “This program, which we named frogger, allowed us to investigate the nature and scope of the network. Using frogger, we were also able to join the network by ‘injecting’ our own nodes and participating in the ongoing P2P traffic.” Via frogger, the researchers determined that FritzFrog had succeeded in brute-forcing millions of SSH IP addresses at medical centers, banks, educational institutions, government organizations, and telecom companies.

The malware communicates over port 1234, but not directly. Traffic over port 1234 is easy to identify, so the malware uses a netcat utility program, which is usually used to monitor network traffic. “Any command sent over SSH will be used as netcat’s input, thus transmitted to the malware,” explained the researchers. FritzFrog also communicates over an encrypted channel and is capable of executing over 30 commands, which include creating a backdoor, connecting to other infected nodes and servers in the FritzFrog network, and monitoring resources such as CPU use.

While the botnet is currently being used to plant cryptocurrency mining malware (XMRig) on victims’ devices to mine Monero, the botnet could easily be repurposed to deliver other forms of malware and could be used for several other purposes. Ophir Harpaz, security researcher at Guardicore Labs, does not believe cryptocurrency mining is the main purpose of the botnet, due to the amount of code dedicated to mining Monero. Harpaz believes it is access to organizations’ networks which is the main aim, which can be extremely valuable. Access to breached servers could be sold or used in much more profitable attacks.

It is unclear who created the botnet or where they are located. It has spread globally, but the geographic origin of the initial attacks is not known. FritzFrog is also under active development, with the researchers identifying more than 20 versions of the FritzFrog binary.

The botnet relies on network security solutions that enforce traffic only by port and protocol, so process-based segmentation rules are required. Infection takes advantage of weak passwords that are susceptible to brute force attempts, so it is important for strong passwords to be set and to use public key authentication. The botnet targets IoT devices and routers with exposed SSH keys, so organizations can protect themselves by changing their SSH port or disabling access to SSH when the service is not in use. The researchers also point out that “it is crucial to remove FritzFrog’s public key from the authorized_keys file, preventing the attackers from accessing the machine.”

Guardicore Labs has published a script on GitHub that can be run to identify FritzFrog infections, along with known IoCs.

The post New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers appeared first on HIPAA Journal.

Researchers Raise Concerns About Patient Safety and Privacy with COVID-19 Home Monitoring Technologies

Posted by HIPAA Journal

A team of researchers at Harvard University has investigated COVID-19 home monitoring technologies, which have been developed to decrease interpersonal contacts and reduce the risk of exposure to the 2019 Novel Coronavirus, SARS-CoV-2.

A range of technologies have been developed to reduce the risk of exposure to SARS-CoV-2 and diagnose symptoms quickly to allow interventions that improve patient safety and limit the spread of COVID-19. The researchers define a home monitoring technology as “a product that is used for monitoring without (direct) supervision by a healthcare professional, such as in a patient’s home, and that collects health-related data from a person.” These technologies are being used to monitor patients in their homes for signs of COVID-19 and include smartwatches and mobile apps that connect to wireless networks and transmit health data. Algorithms are then applied to the data obtained by those technologies.

The study, recently published in Nature Medicine, raises several concerns about these home monitoring tools as they were found to increase the risks to patient safety and privacy. The technologies collect and transmit sensitive health data and, as such, they need to have appropriate security protections in place to ensure that information remains private and confidential. Many of these home monitoring tools were developed quickly to keep up with demand and to help limit the spread of COVID-19, and that has introduced risks that have not fully been addressed.

Their research confirmed that interventions were required to ensure patient safety and to comply with regulatory requirements, privacy laws, and Emergency Use Authorizations(EUAs).While there are privacy laws in the United States, they only somewhat address the privacy concerns with these platforms. There is a blind spot that could allow health data to be collected by a company and for that information to be freely shared with other companies. While there are valid reasons why information may need to be shared, for contact tracing for example, there are other potential uses that are a cause for concern, such as commercializing data gathered from patients.

One of the main problems with these technologies is how they are classified by the Food and Drug Administration (FDA). While some of these technologies are classed as medical devices, and are therefore subject to FDA review, others are not considered medical devices and are therefore not scrutinized by the FDA. Currently, the majority of home monitoring technologies are not considered medical devices and are outside the FDA’s area of control.

“The FDA has recently clarified that it does not consider most software systems and apps for public health surveillance to be medical devices,” wrote the researchers. “The FDA noted products that are intended to track contacts or locations associated with public health surveillance are usually not subject to FDA regulation since they generally do not fulfill the medical-device definition.”

HIPAA includes privacy protections for patients which covers home monitoring technologies, but HIPAA only applies if a technology is provided by a HIPAA-covered entity. If a patient chooses to use home monitoring technologies and is not instructed to do so by a HIPAA-covered entity, HIPAA privacy protections will not apply.

The Secretary of Health and Human Services (HHS) declared COVID-19 to be a nationwide public health emergency on February 4, 2020 and issued three Emergency Use Authorization (EUA) Declarations related to medical devices. One covered in vitro diagnostics for the diagnosis and/or detection of SARS-CoV-2, the second covered personal respiratory protective devices, and the third broadly applies to medical devices, including alternative products that are used as medical devices, such as home monitoring devices. The FDA has similarly issued several EUAs for home monitoring devices, with more expected to be issued in the near future.

The researchers warn that “authorization of home monitoring devices via the EUA pathway does give rise to potential risks.” These are uncleared or unapproved medical devices or are cleared or approved devices for an uncleared or unapproved use, so the issuing of an EUA does not suggest that the product is safe or effective for monitoring. “Another criterion for authorization is the performance of a risk/benefit analysis, and it is difficult to determine where to draw the cut-off for authorization on the basis of this type of analysis. Regulators should always make such decisions carefully and thoroughly, even in times of crisis.”

The researchers also note that “when issuing an EUA, the FDA can waive certain requirements that usually help to reduce risks.” These requirements were intended to prevent harm to the end user and to minimize the risks involved in the manufacture of devices. The researchers recommend that the manufacturers of the devices incorporate as many safeguards as possible to ensure that patient safety and privacy is protected.

There is also a risk of a false positive and false negative results with these monitoring devices, which could mean they fail to diagnose symptoms of COVID-19 and that could result in a delay in receiving treatment, which could have life-threatening consequences. A false negative result could also result in a person not self-isolating, increasing the risk of infecting others.

Reducing the risks associated with these technologies would be possible if the developers adopt an ethical approach and provide reasonable assurances that their products are safe and effective. Vendors must also consider the context in which their products will be deployed and should assess the potential challenges caused by the environment and how the devices interact with the user to ensure that their products are successful.

“In the current public health emergency, US healthcare providers and technology companies should make sure — to the best of their ability — to comply with HIPAA and protect people’s privacy,” suggest the researchers. “As a best practice, developers should try to incorporate HIPAA’s requirements, such as encryption, into their home monitoring [devices] even when HIPAA does not directly apply to their products.”

The researchers recommend that the HHS should develop guidance covering the minimum cybersecurity standards required during the COVID-19 pandemic, to facilitate the rapid implementation of new products while also ensuring appropriate safeguards are implemented to mitigate cyberattacks and ensure that there is a fast response to any vulnerabilities discovered.

“Home monitoring technologies have considerable potential to decrease personal contacts between people and thus exposure to COVID-19, concluded the researchers. “However, the rapid development of new products also poses challenges ranging from safety and liability to privacy. The motto ‘ethics by design, even in a pandemic’ should guide makers in the development of home monitoring products to combat this public-health emergency.”

The post Researchers Raise Concerns About Patient Safety and Privacy with COVID-19 Home Monitoring Technologies appeared first on HIPAA Journal.