Privacy Breaches at Insurance ExchangesThree Incidents Involve Consumers Getting Wrong Data
A privacy breach at the Vermont health insurance exchange involving "recycled" usernames resulted in an individual accessing the personal information of another applicant.
The revelation of the Vermont breach comes on the heels of several recent Congressional hearings that revealed the lack of end-to-end security testing at the federal HealthCare.gov website for Obamacare before it launched on Oct. 1 for open enrollment.
During one of those hearings, CMS officials said a glitch that resulted in a North Carolina consumer being able to access the information of a South Carolina consumer on HealthCare.gov site was "fixed immediately" after it was reported to the agency (see: CIO at CMS Stepping Down.)
In addition, the Associated Press reports that an applicant using Oregon's state insurance exchange, Cover Oregon, received in the mail a printout of her application with a letter instructing her to fill out some missing information. However, with the documents were also several pages of other individuals' applications.
Officials at Cover Oregon did not respond to Information Security Media Group's request for comment.
The breach report filed by Greg Needle, privacy officer of the Vermont Health Connect, to the Centers for Medicare and Medicaid Services, indicates that on Oct. 17, an individual contacted the exchange's call center regarding an application submitted online the week of Oct. 7. The individual stated he received by U.S. mail a non-return address envelope containing a print-out of the application he filled out online, which included his Social Security Number, address and other information.
On the back of the envelope and on the last page of the printed out application was a hand-written note that read, "Vermont Health Connect is Not a Secure Website."
The breach report notes: "VHC investigated immediately and determined that two accounts were linked via a recycled username and it was possible for a brief period of time that the two username holders could access the same information. It was also possible for a brief period one individual accessed the inadvertently shared account and was able to see and create screen shots of the other person's information."
The report also notes: "Only the one user account was created from the two linked usernames. VHC is still investigating but has determined that this recycling of passwords or linked user accounts was an isolated event."
The individual, according to the report "was contacted by VHC and was reassigned a new account access and assured their account was secured."
The privacy incident at Vermont Health Connect that was reported to CMS on Oct. 17 was "successfully closed" by CMS on Oct. 23, according to an internal VHC e-mail provided to Information Security Media Group by the VHC spokeswoman.
Security experts say there are a variety of issues that may have contributed to the Vermont breach.
"My guess, without knowing more about this situation, is that the security problem involved some sort of internal account/file that was created by staff for a consumer," says Kevin Coleman, who heads research and data at HealthPocket, Inc., a technology and research firm that ranks health plans.
"Moreover, the description of the hard copy mail being sent to a consumer would also suggest this was some sort of internal/account file. If I am right, this could be a procedural problem, technical problem, or both," he says.
Coleman says software systems have IDs that normally prevent two identically named accounts from existing in the same file directory at the same time.
"This is software 101. If IDs can be recycled for user accounts then there should be a system to delete the prior account's information prior to the ID being available for recycling," he says. "Software systems are typically built to prevent those type of errors so you do not have to rely on training and monitoring of staff behavior."
Security expert Mac McMillan says the Vermont breach was likely a problem with the exchange's provisioning process. "Usually when this happens it's because someone has reassigned a name. They need to review their account provisioning process to determine where the issue likely occurred and then fix it accordingly," says McMillan, co-founder and CEO of security consulting firm CynergisTek Inc. "In general, accounts should be provisioned from a generic template or from scratch. Permissions should be applied to groups, not to individual user accounts. Account naming should allow for similar type names," he says. For example, "John Smith is j.smith and Joe Smith is jo.smith," he explains.
One formula for a globally unique username is using first initial + last name + random digits, McMillan says. "While it's possible to get the same first/last name combo, adding the random digits makes the chances of a recycled account highly unlikely. Combine smart GUID-based username selection with proper provisioning practices, and this becomes a minor issue that goes away."
In addition to the incidents in Vermont and Oregon, Minnesota's state insurance exchange, MNsure, experienced a breach before the site launched for open enrollment on Oct. 1. In that case, an unencrypted e-mail containing an attachment with personal information about insurance brokers in the state who applied to sell plans on the exchange was mistakenly set by an MNsure worker to the office of an outside broker (see: Auditor Analyzes Minn. Exchange Breach).
An investigation into the case by Minnesota's legislative auditor confirmed that the incident was an accident. However the auditor's report suggested a list of measures that MNsure should take to prevent breaches like that in the future. That included improved employee training and using encryption.
Bolstering Security Practices
HealthPocket's Coleman notes that breaches like those reported by the state insurance exchanges highlight the need for more thorough employee training and sound end-to-end security testing.
"These state exchanges, just like private businesses, really have to look carefully at every aspect of security, from how they train employees to how they're authenticating users creating accounts on these sites," Coleman says.
Also, when glitches are discovered and addressed, more security testing needs to be performed, he says. "It's important to do regression testing when software fixes are implemented and new code is added." That's because the changes made to coding can create new problems. "You can fix an issue and create new unintended bugs or vulnerabilities," he says.
As for the ongoing work at HealthCare.gov to fix technical problems and improve performance and of the federal website, officials expect that by December the site will be able to support 50,000 visitors at a time, and 800,000 visits a day, a CMS spokeswoman said during a Nov. 25 press briefing. Work to improve performance of the site's systems is ongoing, including expansion of storage capacity, she said.