Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/11/2012
11:38 AM
50%
50%

Utah's Medicaid Data Breach Worse Than Expected

Utah Department of Technology Services (DTS) reveals 780,000 individuals have been affected by the theft of sensitive Medicaid information. That's far worse than initial estimates.

Master's Degree Programs For IT Pros And Clinicians
Master's Degree Programs For IT Pros And Clinicians
(click image for larger view and for slideshow)
A new tally of files stored on a server that contained Medicaid information at the Utah Department of Technology Services (DTS) reveals that 780,000 individuals have been affected by the theft of sensitive information. That's far worse than initial estimates.

The data breach occurred on March 30, when a configuration error occurred at the password authentication level, allowing the hacker, located in Eastern Europe, to circumvent DTS's security system.

"The server was a test server and when it was put into production there was a misconfiguration. Processes were not followed and the password was very weak," Stephanie Weiss, spokesperson for DTS, told InformationWeek Healthcare.

On Monday DTS, along with the Utah Department of Health (UDOH), announced that an additional 255,000 people had their social security numbers (SSNs) stolen by hackers from a computer server last week. Until last Friday, authorities had estimated that only 25,096 individuals had their SSNs compromised. That brought the revised figure up to 280,096.

DTS officials said the 280,096 victims were individuals whose information was sent to the state by their healthcare provider in a transaction called a Medicaid Eligibility Inquiry to determine their status as possible Medicaid recipients.

[ Most of the largest healthcare data security and privacy breaches have involved lost or stolen mobile computing devices. For possible solutions, see 7 Tools To Tighten Healthcare Data Security. ]

Another 500,000 individuals had less sensitive personal information stolen, comprising names, addresses, dates of birth, and medical diagnostic codes, among other information. That brings the total number affected to more than 780,000. Officials cautioned that some victims may have been counted twice, and the number of people affected could be reduced as the investigation continues.

The information was hacked from 224,000 files that contained Medicaid Eligibility Inquiries and from the records of Medicaid and Children's Health Insurance Plan (CHIP) recipients.

One single file can potentially contain claims information on hundreds of individuals. DTS has started the process of identifying these additional victims, and the state will be sending letters directly to them as they are identified. To provide a remedy, victims whose SSNs were stolen will receive one year of free credit-monitoring services.

"I am not the least bit surprised," said Daniel Berger, president and CEO of Redspin Inc., a company that provides IT risk assessments at hospitals and other medical facilities. In an interview with InformationWeek Healthcare Berger said, "While the majority of healthcare data breaches to date have been the result of non-malicious incidents, it's always been only a matter of time before the hackers arrived. Digitized medical records are now a high-value target."

Looking ahead, Tom Hudachko, spokesman for UDOH, said the department will send its report to the U.S. Department of Health and Human Services as they assess potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

"DTS is listed as a business associate of ours, so they will be responsible for filing their own separate report with HHS's Office of Civil Rights (OCR), and we will also be filing a report with OCR and with the Centers for Medicare and Medicaid Services," Hudachko told InformationWeek Healthcare. "We've spent some time thinking about a potential fine, but right now we're trying to figure out how we're going to take care of the victims' immediate needs."

In the meantime, DTS has implemented new data security procedures. "We've reviewed our process to prevent this type of incident from happening again," Weiss said. "We've put in place some additional network monitoring and intrusion-detection capabilities."

To shore up their data protection procedures, Rick Kam, president and co-founder of ID Experts, said DTS and UDOH should perform an inventory of the sensitive information their organization manages. "Whether it is considered personally identifiable information (PII) or protected health information (PHI), both have regulatory security requirements to protect it and to notify individuals if security is breached," Kam told InformationWeek Healthcare.

In order to reduce the risk of data theft, Kam recommends that organizations take the following steps:

-- Ask for and keep only PII/PHI that is necessary, and properly dispose of that data.

-- Perform annual risk assessments where PII/PHI exists, whether it is managed within your organization or by third parties, to identify any threats and vulnerabilities and to find the best ways to mitigate risk.

-- Determine the "at risk value" of the PII/PHI to justify appropriate levels of investment in risk mitigation systems used to protect it.

-- Implement and test risk mitigation tools on a periodic basis to make sure they are working effectively.

"Hackers are testing for configuration errors, simple authentication procedures, or weak passwords. It is highly probable that this situation could have been avoided," Kam said.

The 2012 InformationWeek Healthcare IT Priorities Survey finds that grabbing federal incentive dollars and meeting pay-for-performance mandates are the top issues facing IT execs. Find out more in the new, all-digital Time To Deliver issue of InformationWeek Healthcare. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
unnamed
50%
50%
unnamed,
User Rank: Apprentice
4/19/2012 | 8:16:12 PM
re: Utah's Medicaid Data Breach Worse Than Expected
This is going to continue as long as people don't step back and take a look at the big picture. This is a violation of federal laws and the state of Utah is at fault. Kinda funny how the one state that has no separation of religion and state, is the only state to get "breached" I strongly encourage that everyone VOICE their opinion. This is WRONG! and the cover up sickens me.
gardoglee
50%
50%
gardoglee,
User Rank: Apprentice
4/14/2012 | 2:14:49 PM
re: Utah's Medicaid Data Breach Worse Than Expected
One thing which bothers me greatly in the reporting on this is that they keep implying, or even saying directly, that the data other than SSN is not as sensitive or important. OK, I realize the SSN is useful for identity theft, but the procedure codes will contain terribly private and sensitive data for many of those affected, and in the long term could be used in many malicious ways.
Bprince
50%
50%
Bprince,
User Rank: Ninja
4/12/2012 | 4:47:14 AM
re: Utah's Medicaid Data Breach Worse Than Expected
This seems to be getting worse and worse. Underscores the importance of monitoring configuration changes.
Brian Prince, InformationWeek/Dark Reading Comment Moderator
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: It is too bad the ceiling is made of glass!
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.
CVE-2019-19142
PUBLISHED: 2020-01-17
Intelbras WRN240 devices do not require authentication to replace the firmware via a POST request to the incoming/Firmware.cfg URI.