Insurance carriers, third party administrators (TPAs), and self-insureds had claims data exposed when a cloud-hosted claims management service inadvertently left their databases and files unprotected on a public server.
Another week, another infosecurity failure that exposed oodles of personal information.
This time, it’s a leak that not only exposed insurance claims data, but allegedly included internal documents that reveal how some entities planned to defend against specific claims.
According to a source who contacted DataBreaches.net, as part of research on data leaks, the self-described “technology enthusiast” (“TE”) downloaded some random data from a publicly available subdomain on Amazon Web Services (AWS). Inspection of the files revealed many GB of SQL database backups with “names, social security numbers, addresses, dates of birth, phone numbers, as well as various financial and medical injury data.”
TE informs DataBreaches.net that after discovering the treasure trove of personal information on or about August 30, he immediately began to notify the proper agencies and authorities. DataBreaches.net withheld publication until now to give TE time to notify more entities and to give the software firm time to notify its affected clients.
According to TE, much of the data appeared to be related to Kansas residents, and included what appeared to be a copy of the entire Kansas State Self Insurance Fund SIMS database. TE informs DataBreaches.net that the address book in the database contains over 1,099,000 entries with names, addresses, social security numbers/tax ID numbers, phone numbers, state, and zip code.
Approximately 30 minutes after TE contacted Kansas to alert them to the exposure of their database, public access to the AWS subdomain was terminated, he reports.
Another exposed database contained data from the CSAC Excess Insurance Authority (CSAC-EIA). According to TE, in the CSAC Excess Insurance Authority area, there are nearly 3 million payment entries dating back to 1987 that contain the following fields:
The “address book” table in that database reportedly has over 570,000 entries containing some or all of the following data types for each entry/row: name, Social Security Number, phone number, address, ethnicity, city, state, zip code, and birth date.
The CSAC-EIA data also reportedly includes 4.7 million “notepad” entries regarding claims, such as fraud investigation notes. TE provided this redacted example:
“Surveillance Called [REDACTED] Investigations Inc [REDACTED] The 41213 appt will not work for surveillance will need to follow on 41613 915AM [REDACTED] for neck only [REDACTED] address is [REDACTED] Advised of different color truck as well [REDACTED] will follow up with me after the one day of surveillance to see what or where we need to follow next”
Note that DataBreaches.net did not download any of the leaked data and descriptions in this post of the leaked data rely on statements from TE, whose previous tips and information to this site have been reliable.
In a statement to DataBreaches.net, TE writes that files on the public server also contained:
TONS of financial transaction data. Bank accounts with routing numbers, check numbers, amounts, dates… and not everyone is a client. Any person or company that got paid-out is at least mentioned…
There were also thousands of scanned PDF files that appear to be insurance claim forms with some medical/health information. According to TE, the records are reportedly all stamped “GSRMA,” which is likely the Golden State Risk Management Authority. GSRMA describes itself as “a risk-sharing insurance pool that offers a full line of programs to cover the many unique exposures of public entities throughout the State of California.” GSRMA participates in the CSAC-Excess Insurance Authority (EIA) General Liability Program for excess liability coverage.
TE informs DataBreaches.net that CSAC EIA data exposed online included what appears to be notes on court proceedings involving city and/or county defendants. He provided this redacted example from the “Insured’s defense” field:
“Questionable/concerning. It appears there was a valid warrant. Its possible they had too many plants growing which is why many were seized. However, there is no indication that any were left despite the medical marijuana cards. We need to verify why they were all taken and if there was appropriate reason to if the cards were provided to the officers. The destroying of the marijuana is not to take place unless the court orders it. In this case it appears the DEA’s office told the DA’s office to destroy the plants w/out court order. Defense is assigned to [REDACTED].
DEA’s office is involved. The plaintiff’s criminal background will discredit them in front of a jury. Their poor judgment of having a minor child in the home with all the pot and guns will also not look good before a jury.”
Another exposed database contained data from Salt Lake County (Utah). Their database reportedly contained approximately 29,000 SSNs, along with names, addresses, phone numbers, and claim numbers. Also included were brief descriptions of claims, such as “HIT HEAD ON TOWEL HOOK IN SHOWER,” “VACCINE SPRAY GOT IN EYES ,” etc.
TE notes that what’s being reported here is only a partial description of the scope of the leak.
Although TE has not fully analyzed all the data, he guestimates that there were a minimum of 1.5 million individuals who had personal details exposed, probably 1 million SSNs, more than 5 million financial transactions detailed, over 1,000 entities that had data exposed, and hundreds of thousands of injury reports. Not all entities are necessarily clients of the software firm.
So who’s responsible for the leak? The databases were all on a publicly available subdomain on AWS associated with California-based Systema Software. Systema Software makes software for web-based claims management, including their SIMS Claims™ product. Systema also provides cloud services to host SIMS Claims data. California contracted with Systema in August, 2014. AARLA contracted with Systema in January of this year.
In addition to everything described above, TE also reports that all of the databases appeared to contain login information: session IDs, login names, and password hashes.
The leak also exposed Systema’s proprietary information. TE informs DataBreaches.net that he found a directory with raw data internal conversion scripts. “I’m sure competitors would love to get their hands on this stuff,” he comments. Note: TE has reportedly spent countless hours engaged in responsible disclosure of this breach and has taken steps to protect the data he downloaded.
Systema Software did not respond to an inquiry sent by DataBreaches.net asking for more details as to how the leak occurred, for how long, and how many individuals had their personal details exposed. Nor did they respond to a question asking whether Systema will be notifying individuals whose data were exposed or if their clients will be taking care of any required notifications. This post will be updated if they do respond. At the time of this posting, there is no statement on their web site or Facebook page disclosing the breach.
In response to another inquiry sent by DataBreaches.net, the Kansas Dept. of Health & Environment provided the following statement:
When we were notified of this breach last week, we started working with Systema to determine how many Kansans were affected by this breach and what information was included. Based on our current information, we are confident that Systema is working to protect the information of anyone included in this breach. KDHE and the State of Kansas will continue to work with Systema to ensure they take appropriate action.
Which, of course, does not directly answer the question as to whether Systema or KDHE will be notifying everyone whose data were exposed, and whether they will be offered any mitigation services such as credit monitoring and/or identity theft restoration services. As of the time of this posting, there is no breach notice on KDHE’s web site.
CSAC, contacted by email on Sunday evening, did not acknowledge this site’s notification nor provide any statement (see correction below). TE subsequently informed DataBreaches.net that he was able to reach their IT department on Monday. As of the time of this posting, there is no notice on their web site, either.
DataBreaches.net will continue to follow this incident and to provide updates as more details become available. If any reader does receive a notification of the incident, please forward a copy to breaches(at)databreaches.net.
UPDATE AND CORRECTIONS: This post was corrected post-publication to reflect that it was not CSAC that was involved in the leak, but CSAC Excess Insurance Authority, a separate organization. DataBreaches.net had emailed CSAC, not CSAC-EIA, and apologizes to CSAC for the error and confusion. Additionally, although the name York Insurance Services Group appeared in some of the files in CSAC-EIA database and was originally reported by this site as being affected, neither the data nor the system were York’s. In a statement to DataBreaches.net, a spokesperson for York explained:
None of the data exposed is York data. York is a risk services firm and we offer many services, one of which is staff augmentation of claims adjusters. CSAC-EIA has York claims adjusters working for CSAC-EIA on Systema’s system at CSAC-EIAs direction on CSAC-EIA claims (data).
DataBreaches.net apologizes for any confusion on that point.
Update 2 (Sept. 17): CSAC-EIA sent the following statement to DataBreaches.net in response to an inquiry as to notification of individuals:
EIA’s Cyber attorney is reviewing the incident to determine the appropriate action. He is working in concert with Systema’s legal team to comply with both State and Federal laws.
Update 3 (Sept. 23): Salt Lake County claims that 29,000 individuals were not affected, but they don’t offer an actual confirmed number yet. The table upon which “TE” (Chris Vickery) based his claim does have 29,000 rows, although Chris acknowledges to DataBreaches.net that he did not analyze the table to eliminate duplicates or to get a count on the number of unique individuals.