Latest HIPAA News

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.

FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers

Posted by HIPAA Journal

An ongoing voice phishing (vishing) campaign is being conducted targeting remote workers from multiple industry sectors. The threat actors impersonate a trusted entity and use social engineering techniques get targets to disclose their corporate Virtual Private Network (VPN) credentials.

The Federal Bureau of Investigation (FBI) and the DHS Cybersecurity and infrastructure Security Agency (CISA) have issued a joint advisory about the campaign, which has been running since mid-July.

The COVID-19 pandemic forced many employers to allow their entire workforce to work from home and connect to the corporate network using VPNs. If those credentials are obtained by cybercriminals, they can be used to access the corporate network.

The threat group first purchases and registers domains that are used to host phishing pages that spoof the targeted company’s internal VPN login page and SSL certificates are obtained for the domains to make them appear authentic. Several naming schemes are used for the domains to make them appear legitimate, such as [company]-support, support-[company], and employee-[company].

The threat group then gathers information about company employees by scraping social media profiles and compiles dossiers on specific employees. The types of information collected include personal information such as an employee’s name, address, personal phone number, job title, and length of time at the company. That information is then used to gain the trust of the targeted employee.

Employees are then called from a voice-over-IP (VOIP) number. Initially the VOIP number was anonymous, but later in the campaign the attackers started spoofing the number to make it appear that the call was coming from a company office or another employee in the firm. Employees are then told they will receive a link that they need to click to login to a new VPN system. They are also told that they will need to respond to any 2-factor authentication and one-time password communications sent to their phone.

The attackers capture the login information as it is entered into their fraudulent website and use it to login to the correct VPN page of the company. They then capture and use the 2FA code or one-time password when the employee responds to the SMS message.

The attackers have also used SIM-swap to bypass the 2FA/OTP step, using information gathered about the employee to convince their mobile telephone provider to port their phone number to the attacker’s SIM. This ensures any 2FA code is sent directly to the attacker. The threat actors use the credentials to access the company network to steal sensitive data to use in other attacks. The FBI/CISA say the end goal is to monetize the VPN access.

The FBI/CISA recommend organizations restrict VPN connections to managed devices using mechanisms such as hardware checks or installed certificates, to restrict the hours that VPNs can be used to access the corporate network, to use domain monitoring tools to monitor web applications for unauthorized access and anomalous activities.

A formal authentication procedure should also be introduced for employee-to-employee communications over the public telephone network where a second factor is required to authenticate the phone call prior to the disclosure of any sensitive information.

Organizations should also monitor authorized user access and usage to identify anomalous activities and employees should be notified about the scam and instructed to report any suspicious calls to their security team.

The post FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers 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.

July 2020 Healthcare Data Breach Report

Posted by HIPAA Journal

July saw a major fall in the number of reported data breaches of 500 or more healthcare records, dropping below the 12-month average of 39.83 breaches per month. There was a 30.8% month-over-month fall in reported data breaches, dropping from 52 incidents in June to 36 in July; however, the number of breached records increased 26.3%, indicating the severity of some of the month’s data breaches.

 

1,322,211 healthcare records were exposed, stolen, or impermissibly disclosed in July’s reported breaches. The average breach size was 36,728 records and the median breach size was 6,537 records.

Largest Healthcare Data Breaches Reported in July 2020

14 healthcare data breaches of 10,000 or more records were reported in July, with two of those breaches involving the records of more than 100,000 individuals, the largest of which was the ransomware attack on Florida Orthopaedic Institute which resulted in the exposure and potential theft of the records of 640,000 individuals. The other 100,000+ record breach was suffered by Behavioral Health Network in Maine. The breach was reported as a “malware” attack that prevented records from being accessed. 129,871 healthcare records were compromised in that attack.

Name of Covered Entity State Covered Entity Type Individuals Affected Type of Breach
Florida Orthopaedic Institute FL Healthcare Provider 640,000 Hacking/IT Incident
Behavioral Health Network, Inc. MA Healthcare Provider 129,571 Hacking/IT Incident
NCP Healthcare Management Company MA Business Associate 78,070 Hacking/IT Incident
Walgreen Co. IL Healthcare Provider 72,143 Theft
Allergy and Asthma Clinic of Fort Worth TX Healthcare Provider 69,777 Hacking/IT Incident
WellCare Health Plans FL Health Plan 50,439 Unauthorized Access/Disclosure
Maryland Health Enterprises DBA Lorien Health Services MD Healthcare Provider 47,754 Hacking/IT Incident
Central California Alliance for Health CA Health Plan 35,883 Hacking/IT Incident
University of Maryland Faculty Physicians, Inc. / University of Maryland Medical Center MD Healthcare Provider 33,896 Hacking/IT Incident
Highpoint Foot & Ankle Center PA Healthcare Provider 25,554 Hacking/IT Incident
Accu Copy of Greenville, Incorporated NC Business Associate 21,800 Hacking/IT Incident
CVS Pharmacy RI Healthcare Provider 21,289 Loss
Owens Ear Center TX Healthcare Provider 19,908 Unauthorized Access/Disclosure
University of Utah UT Healthcare Provider 10,000 Hacking/IT Incident
Rite Aid Corporation PA Healthcare Provider 9,200 Theft

Causes of July 2020 Healthcare Data Breaches

Hacking and other IT incidents dominated the breach reports in July, accounting for 69.4% (25 incidents) of the month’s breaches and 86.3% of breached records (1,141,063 records). The mean breach size was 45,643 records with a median size of 7,000 records.

There were 6 unauthorized access/disclosure incidents reported. 76,553 records were breached in those incidents, with a mean breach size of 12,759 records and a median size of 2,123 records.  There were 4 breaches categorized as theft involving the PHI/ePHI of 83,306 individuals. The mean breach size was 20,827 records and the median breach size was 5,332 records. One loss incident was reported that involved the PHI/ePHI of 20,827 individuals.

Many pharmacies across the United States were looted during the period of civil unrest in the wake of the death of George Floyd, with the Walgreens, CVS, and Rite Aid pharmacy chains hit particularly hard. In addition to the theft of prescription medications, devices containing ePHI and paperwork containing sensitive patient information were also stolen in the break-ins.

Phishing attacks usually dominate the healthcare breach reports and while email-related breaches were the most common type of breach in July, network server breaches were in close second, most commonly involving the use of malware or ransomware. The increase in the latter is certainly a cause of concern, especially considering the rise in human-operated ransomware attacks that involve the theft of patient data prior to file encryption. These attacks see patient data exposed or sold if the ransom is not paid, but there is no guarantee that stolen data will be deleted even if the ransom is paid. Phishing and ransomware attacks are likely to continue to be the leading causes of data breaches over the coming months.

Spam filters, web filters, and end user training are essential for reducing susceptibility to phishing attacks, along with multi-factor authentication on email accounts. Ransomware and other forms of malware are commonly delivered by email and these measures are also effective at blocking attacks. It is also essential for vulnerabilities to be patched promptly. Many of the recent ransomware attacks have involved the exploitation of vulnerabilities, even though patches to address the flaws were released several weeks or months prior to the attacks. Brute force tactics continue to be used on RDP, so it is essential for storing passwords to be set. Human operated ransomware attacks often see attackers gain access to healthcare networks weeks before ransomware is deployed. By monitoring networks and event logs for anomalous user behavior, it may be possible to detect and block an attack before ransomware is deployed.

Healthcare Data Breaches by Covered Entity Type

There were 26 data breaches reported by healthcare providers in July 2020, 4 by health plans, and 6 breaches were reported by business associates of HIPAA-covered entities. A further three breaches were reported by a covered entity but had some business associate involvement.

July 2020 Healthcare Data Breaches by State

The 36 data breaches were reported by HIPAA-covered entities and business associates in 21 states. California and Texas were worst affected with 4 breaches apiece, followed by Florida and Pennsylvania with three breaches, and two breaches in each of Illinois, Massachusetts, Maryland, North Carolina, and Wisconsin. One breach was reported in each of Alaska, Arizona, Colorado, Connecticut, Michigan, Nebraska, New Mexico, New York, Ohio, Rhode Island, Utah, and West Virginia.

HIPAA Enforcement in July 2020

The HHS’ Office for Civil Rights has issued multiple notices of enforcement discretion this year spanning the duration of the nationwide COVID-19 public health emergency; however, that does not mean that OCR has scaled back enforcement of HIPAA Rules. OCR accepts that it may be difficult to ensure continued compliance with all aspects of HIPAA Rules during such difficult times, but entities that are discovered to have violated the HIPAA Rules can and will still face financial penalties for noncompliance.

In July, OCR announced two settlements had been reached with HIPAA covered entities to resolve HIPAA violation cases. A settlement of $1,040,000 was agreed with Lifespan Health System Affiliated Covered Entity to resolve HIPAA violations discovered during the investigation of a 2017 breach report submitted following the theft of an unencrypted laptop computer.

OCR discovered multiple compliance failures. Lifespan had not implemented encryption on portable devices that stored ePHI, even though Lifespan was aware of the risk of ePHI exposure. There were also device and media control failures, the failure to enter into business associate agreements with vendors, and an impermissible disclosure of 20,431 patients’ ePHI.

Metropolitan Community Health Services dba Agape Health Services was investigated over a 2011 data breach of 1,263 patient records and OCR discovered longstanding, systemic noncompliance with the HIPAA Security Rule. A settlement of $25,000 was agreed with OCR to resolve the violations, with the small size of the healthcare provider taken into consideration when determining an appropriate penalty amount.

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

Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed

Posted by HIPAA Journal

A new report has revealed the personal and protected health information of patients and other sensitive data are being exposed online without the knowledge of covered entities and business associates through public GitHub repositories.

Jelle Ursem, a security researcher from the Netherlands, discovered at least 9 entities in the United States – including HIPAA-covered entities and business associates – have been leaking sensitive data via GitHub. The 9 leaks – which involve between 150,000 and 200,000 patient records – may just be the tip of the iceberg. The search for exposed data was halted to ensure the entities concerned could be contacted and to produce the report to highlight the risks to the healthcare community.

Even if your organization does not use GitHub, that does not necessarily mean that you will not be affected. The actions of a single employee or third-party contracted developer may have opened the door and allowed unauthorized individuals to gain access to sensitive data.

Exposed PII and PHI in Public GitHub Repositories

Jelle Ursem is an ethical security researcher who has previously identified many data leaks on GitHub, including by Fortune 500 firms, publicly traded companies, and government organizations. Ursem decided to conduct a search to find out if any medical data had been leaked on GitHub. It took just 10 minutes to confirm that it had, but it soon became clear that this was far from an isolated case.

Ursem conducted searches such as “companyname password” and “medicaid password FTP” and discovered several hard-coded usernames and passwords could be found in code uploaded to GitHub. Those usernames and passwords allowed him to login to Microsoft Office 365 and Google G Suite accounts and gain access to a wide range of sensitive information such as user data, contracts, agendas, internal documents, team chats, and the protected health information of patients.

“GitHub search is the most dangerous hacking tool out there,” said Ursem. Why go to the trouble of hacking a company when it is leaking data that can be found with a simple search on GitHub?

Ursem attempted to make contact with the companies concerned to alert them to the exposure of their data and ensure the information was secured, but making contact with those organizations and getting the data secured proved problematic, so Ursem contacted databreaches.net for assistance.

Together, Dissent Doe of DataBreaches.net and Ursem worked together to contact the organizations concerned and get the data secured. In some cases, they succeeded – with considerable effort – but even after several months of attempts at contacting the companies concerned, explaining the severity of the situation, and offering help to address the problems that led to the exposure of data, some of that data is still accessible.

9 Leaks Identified but There are Likely to be Others

The report details 9 leaks that affected U.S. entities – namely Xybion, MedPro Billing, Texas Physician House Calls, VirMedica, MaineCare, Waystar, Shields Health Care Group, AccQData – and one unnamed entity: Unnamed because the data is still accessible.

The most common causes of GitHub data leaks were developers who had embedded hard-coded credentials into code that had been uploaded into public GitHub repositories, the use of public repositories instead of private repositories, and developers who had abandoned repositories when they were no longer required, rather than securely deleting them.

For example, Ursem found that a developer at Xybion – a software, services and consulting company with a presence in workplace health issues – had left code in a public GitHub repository in February 2020. The code included hard-coded credentials for a system user that, in connection with other code, allowed Ursem to access billing back-office systems that contained the PHI of 7,000 patients, together with more than 11,000 insurance claims dating back to October 31, 2018.

It was a similar story with MaineCare – a state- and federally-funded program that provides healthcare coverage to Maine residents. In that case, hard-coded credentials gave Ursem administrative access to the entire website, access to the internal server infrastructure of MaineCare / Molina Health, MaineCare SQL data sources, and the PHI of 75,000 individuals.

The Typhoid Mary of Data Leaks

The report highlights one developer, who has worked with a large number of healthcare organizations, whose GitHub practices have led to the exposure of many credentials and the PHI of an estimated 200,000 clients. That individual has been called the “Typhoid Mary of Data Leaks”.

The developer made many mistakes that allowed client data to be exposed, including leaking the credentials of 5 employers on GitHub and leaving repositories fully accessible after work had been completed. In one case, the actions of that developer had allowed access to the central telephone system of a large entity in debt collection, and in another credentials allowed access to highly sensitive records for people with a history of substance abuse.

While it was not possible to contact that individual directly, it appears that the work of DataBreaches.net and Ursem has gotten the message through to the developer. The repositories have now been removed or made private, but not before the data was cloned by at least one third party.

This was just one example of several outsourced or contracted developers who were being used by HIPAA-covered entities and business associates, whose practices exposed data unbeknownst to the CEs and BAs.

“No matter how big or small you are, there’s a real chance that one of your employees has thrown the front door key under the doormat and has forgotten that the doormat is transparent,” explained Dissent Doe of DataBreaches.net. Regardless of whether your organization uses GitHub, HIPAA Journal believes the report to be essential reading.

The collaborative report from Jelle Ursem and DataBreaches.net explains how the leaks occurred, why they have gone undetected for so long, and details several recommendations on how data breaches on GitHub can be prevented – and detected and addressed quickly in the event that mistakes are made. You can download the full PDF report on this link.

Many thanks to Dissent Doe for notifying HIPAA Journal, to Jelle Ursem for discovering the data leaks, and for the hard work of both parties investigating the leaks, contacting the entities concerned, and highlighting the problem to help HIPAA-covered entities and their business associates take steps to prevent GitHub data breaches moving forward.

The post Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed appeared first on HIPAA Journal.

Medical Software Database Containing Personal Information of 3.1 Million Patients Exposed Online

Posted by HIPAA Journal

A database containing the personal information of more than 3.1 million patients has been exposed online and was subsequently deleted by the Meow bot.

Security researcher Volodymyr ‘Bob’ Diachenko discovered the database on July 13, 2020. The database required no password to access and contained information such as patients’ names, email addresses, phone numbers, and treatment locations. Diachenko set about trying to identify the owner of the database and found it had been created by a medical software company called Adit, which makes online booking and patient management software for medical and dental practices. Diachenko contacted Adit to alert the company to the exposed database but received no response. A few days later, Diachenko discovered the data had been attacked by the Meow bot.

The Meow bot appeared in late July and scans the internet for exposed databases. Security researchers such as Diachenko conduct scans to identify exposed data and then make contact with the data owners to try to get the data secured. The role of the Meow bot is search and destroy. When exposed database are found, the Meow bot’s script overwrites the data with random numerical strings, appended with the word “meow”.

The individual or group behind the Meow bot is unknown, nor the motives behind the attacks, of which there have been hundreds. Many threat actors search for exposed cloud databases and steal or encrypt data and issue a ransom demand, but there appears to be no financial motive behind the Meow bot attacks.

It is not entirely clear whether data is stolen prior to being overwritten, but several security researchers have suggested data theft is not the aim, instead the purpose may be to prevent the information of data subjects from being obtained by cybercriminals and/or to send a message to data holders that the failure to secure data will result in data being destroyed.

The deletion of the database may have prevented the data from falling into the hands of cybercriminals, but a previous study conducted by Comparitech showed malicious actors are constantly searching for exposed data and often find exposed Elasticsearch databases and Amazon S3 buckets within hours of them being exposed. Since the database was exposed for at least 10 days before the search and destroy Meow bot attack, it is probable that it was found and obtained prior to its destruction; potentially by multiple parties.

In this case, the personal data was limited, but that information could still be of use to cybercriminals for phishing campaigns.

The post Medical Software Database Containing Personal Information of 3.1 Million Patients Exposed Online appeared first on HIPAA Journal.

NIST Publishes Final Guidance on Establishing Zero Trust Architecture to Improve Cybersecurity Defenses

Posted by HIPAA Journal

NIST has published the final version of its zero trust architecture guidance document (SP 800-207) to help private sector organizations apply this cybersecurity concept to improve their security posture.

Zero trust is a concept that involves changing defenses from static, network-based perimeters to focus on users, assets, and resources. With zero trust, assets and user accounts are not implicitly trusted based on their physical or network location or asset ownership. Under the zero trust approach, authentication and authorization are discreet functions that occur with subjects and devices before a session is established with an enterprise resource.

The use of credentials for gaining access to resources has been an effective security measure to prevent unauthorized access; however, credential theft – through phishing campaigns for instance – is now commonplace, so cybersecurity defenses need to evolve to better protect assets, services, workflows, and network accounts from these attacks.

All too often, credentials are stolen and are used by threat actors to gain access to enterprise networks undetected. Threat actors often have access to networks for days, weeks, or even months before an attack is detected, during which time they are free to move laterally and compromise an entire network. The increase in remote working, bring your own device initiatives and the use of cloud-based assets that are not located within the traditional network boundary has made the traditional perimeter-based approach to network security less effective.

A zero trust architecture helps to solve these issues and improve cybersecurity defenses. According to NIST, “zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource.”

The guidance document provides an abstract definition of zero trust architecture (ZTA), covers the zero trust basics and logical components of zero trust architecture, and includes general deployment models and use cases where the zero trust approach can improve an organization’s information technology security posture.

In the guidance document NIST explains how the zero trust model can be combined with the NIST Risk Management Framework, NIST Privacy Framework, and other existing federal guidance and outlines how organizations can migrate to zero trust architecture.

Initially, organizations should focus on restricting access to resources to individuals who require access to perform their work duties, and to only grant minimal privileges such as read, write, delete. In many organizations with perimeter-based defenses, individuals tend to be given access to a much broader range of resources once they have been authenticated and logged in to an internal network. The problem with this approach is unauthorized lateral movement is too easy, either by internal actors or external actors using stolen credentails.

The zero trust security model assumes an attacker is present within an environment, so there is no implicit trust. Enterprise networks are treated the same as non-enterprise networks. Under the zero trust approach, organizations continually analyze and evaluate risks to assets and business functions and then enact protections to mitigate those risks.

Migrating to zero trust is not about the wholesale replacement of infrastructure or processes, rather it is a journey that involves incrementally introducing zero trust principles, processes, technology solutions, and workflows, starting with protecting the highest value assets. Most organizations will remain in a hybrid zero trust and perimeter-based environment for some time while they implement their IT modernization plan and fully transition to zero trust architecture.

The guidance document is the result of collaboration with several federal agencies and was overseen by the Federal CIO Council. The document was developed for enterprise security architects, but is also a useful resource for cybersecurity managers, network administrators, and managers to gain a better understanding of zero trust.

The publication can be downloaded from NIST on this link.

The post NIST Publishes Final Guidance on Establishing Zero Trust Architecture to Improve Cybersecurity Defenses appeared first on HIPAA Journal.

OCR Warns of Postal Phishing Scam Targeting HIPAA Compliance Officers

Posted by HIPAA Journal

The Department of Health and Human Services’ Office for Civil Rights is warning healthcare organizations about a phishing scam being conducted by mail that has been designed to scare compliance officers into visiting a website or taking immediate action with respect to a HIPAA risk assessment.

Postcards have been sent to several healthcare organizations that masquerade as an official communication from the Office for Civil Rights. The postcards are addressed to the HIPAA compliance officer and state a mandatory HIPAA compliance risk assessment must be performed. The postcards warn that “HIPAA violations cost your practice. The federal fines for noncompliance are based on perceived negligence found within your organization at the time of the HIPAA violation.” The postcards remind the recipient that “fines can range from $100 to $50,000 per violation (or per record), with a maximum penalty of $1.5 million per year for each violation.”

The postcards claim to have been sent by the Secretary of Compliance of the HIPAA Compliance Division – a position that does not exist – and have a Washington D.C. return address. The link that compliance officers are requested to visit markets consulting services and is a non-governmental site.

OCR has advised all covered entities to alert their workforce about the misleading communication, which appears to have been sent by a private company. OCR stressed that this is not a communication sent by the HHS or OCR.

OCR advises HIPAA covered entities and business associates to take steps to verify the legitimacy of any communication that claims to be from the HHS or OCR, and explained that any written communications from OCR will include the following address:

Office for Civil Rights
U.S. Department of Health and Human Services
200 Independence Avenue, SW
Room 509F, HHH Building
Washington, D.C. 20201

Any request to make contact via email will provide an email address for contact that has an @hhs.gov suffix.

The impersonation of federal law enforcement is a crime and any suspected cases should be reported to the Federal Bureau of Investigation.

The post OCR Warns of Postal Phishing Scam Targeting HIPAA Compliance Officers appeared first on HIPAA Journal.

House of Representatives Votes to Remove Ban on HHS Funding a National Patient Identifier System

Posted by HIPAA Journal

The House of Representatives has voted to lift the ban on the Department of Health and Human Services using federal funds to develop a national patient identifier system.

The Health Insurance Portability and Accountability Act (HIPAA) called for the development of a national patient identifier system. As the name suggests, a national patient identifier system would see each person in the united States issued with a permanent, unique identification number, similar to a Social Security number, that would allow each patient to be identified across the entire healthcare system in the United States. If a patient from California visited an emergency room in New York, the patient identifier could be used to instantly identify the patient, allowing the healthcare provider to access their medical history. Currently, the lack of such an identifier makes matching patients with their medical records complicated, which increases the potential for misidentification of a patient.

The extent to which records are mismatched has been shown in multiple studies. For instance, in 2012, a study conducted by the College of Healthcare Information Management Executives (CHIME) found that 20% of its members could trace an adverse medical event to the mismatching of patient records. In 2014, the Office of the National Coordinator for Health Information Technology (ONC) found that 7 out of every 100 patient records were mismatched. Between 50% and 60% of records are mismatched when shared between different healthcare providers. A study conducted by the Ponemon Institute suggested 35% of all denied claims are due to inaccurately matched records or incomplete patient information, which costs the healthcare industry around $1.2 million each year.

It has been 24 years since HIPAA was signed into law, yet there is still no national patient identifier system. A ban was implemented in 1999 preventing the Department of Health and Human Services from funding the development of such as system out of privacy concerns. The ban has remained in place ever since.

Attempts have been made to lift the ban, notably by Reps. Bill Foster (D-IL) and Mike Kelly (R-PA). Last year, their efforts were partially successful, as the House of Representatives voted to remove the ban, only for the Senate to reject the house provision by not including the language removing the ban in the fiscal year 2020 funding bill for the HHS.

On July 30, 2020, the House approved the Foster-Kelly amendment for the House fiscal 2021 appropriations bill covering the departments of labor, health and human services and education. If the Foster-Kelly amendment is included in the Senate fiscal year 2021 funding bill, the HHS will be free to evaluate a range of solutions and find one which is cost-effective, scalable and secure.

Proponents of lifting the ban claim a national patient identifier would increase patient safety and would help with the secure exchange of healthcare information. While support for a national patient identifier is growing, not everyone believes such a system is wise. Opponents to the lifting of the ban believe a national patient identifier would create major privacy risks. The Citizens’ Council for Health Freedom said a national patient identifier “would combine all of your private information, creating a master key that would open the door to every American’s medical, financial and other private data.”

While there are concerns about privacy, the benefits of introducing such a system have been highlighted during the COVID-19 pandemic. Temporary healthcare facilities and testing sites have been set up and laboratories are now processing huge numbers of COVID-19 tests. There have been many reports of healthcare facilities struggling to correctly identify patients and laboratories have found it difficult to match test results with the right patients due to the lack of complete demographic data.

“The coronavirus pandemic continues to demonstrate the importance of accurately identifying patients and matching them to their medical records. Today marks another milestone in keeping patients safe with the passage of the Foster-Kelly Amendment in the House, bringing us closer to a national patient identification solution,” Russ Branzell, CHIME CEO.

“Removing this archaic ban is more important than ever as we face the COVID-19 pandemic,” said Rep. Bill Foster. “Our ability to accurately identify patients across the care continuum is critical to addressing this public health emergency, and removing this ban will alleviate difficult and avoidable operational issues, which will save money and, most importantly, save lives.”

The post House of Representatives Votes to Remove Ban on HHS Funding a National Patient Identifier System appeared first on HIPAA Journal.