Feb 202017

Dan Goodin reports:

Researchers have uncovered an advanced malware-based operation that siphoned more than 600 gigabytes from about 70 targets in a broad range of industries, including critical infrastructure, news media, and scientific research.

The operation uses malware to capture audio recordings of conversations, screen shots, documents, and passwords, according to a blog post published last week by security firm CyberX. Targets are initially infected using malicious Microsoft Word documents sent in phishing e-mails. Once compromised, infected machines upload the pilfered audio and data to Dropbox, where it’s retrieved by the attackers.

Read more on Ars Technica.

Feb 202017

Gus Hurwitz has a great commentary on LabMD v. FTC and an amicus brief filed by privacy law scholars in support of the FTC.

I say “great” because I agree with him completely.

I  hold the privacy law scholars who filed the brief in very high regard, but reading their brief, I felt like it was the ivory tower vs. real world if you’re a small-medium entity in the healthcare sector.

From the gitgo on this case, I have repeatedly noted that small and medium businesses that were covered by HIPAA were never given sufficient notice that we also had to comply with Section 5 of the FTC Act or what such compliance would entail. Where were the notices and guidance prior to LabMD’s incident in February 2008? A presentation to Congress in 2007? A report in 2005 based on a workshop in 2004 that SMB in the healthcare sector might not have even known to consider attending or reading? How would we even know to look at those? My review of web sites prior to 2008 turned up not a single government site or law firm site devoted to HIPAA that even mentioned compliance with the FTC Act. So how would small and medium entities even know to go look for guidance on FTC’s site?

And even if you can convince me that we should have somehow known, then where was the sufficient notice or guidance as to what practices would run us afoul of Section 5?  Where, prior to 2008 when the LabMD incident occurred, was there anything that even remotely approached standards for what might be considered “reasonable” security? What if we did everything right and had one screw-up, like an employee violating policy and installing filesharing software on their workstation? Would that one foul-up warrant FTC enforcement and a 20-year auditing program? And if HHS didn’t even think the incident was a reportable breach and later declined to join FTC in its enforcement action, it seems somewhat preposterous for the FTC to claim that patients suffered actual significant injury – even though there was not a single victim identified and the only “proof” of injury was FTC’s claim that it occurred.

There’s always been something very wrong with the FTC’s case against LabMD, and it’s not just its reliance on testimony from a firm that was later shown to be fabricated evidence.

Without doubt, the FTC has done a better job of collaboration, workshops, and outreach in recent years, but what went on prior to 2008 when the LabMD incident occurred? Citing articles from 2010 and beyond as if it justified what they did before the publication of those materials strikes me as well….. deceptive. If you strip every post-2008 reference or action out of the amicus brief, what are amici left with to justify the FTC’s actions and decisions?

Citing recent research based on large corporations or entities says nothing about what small and medium-sized businesses knew at the time, nor whether the positive benefits to society as a result of large corporations taking FTC enforcement to heart also had or has any positive benefit to society when it comes to small and medium businesses. To the contrary, we know that it has had at least one negative outcome: a small cancer-detection lab went out of business, crushed under the burden of fighting the FTC’s over-aggressive enforcement.

As Gus writes:

There are millions of companies in the United States; almost all of them are closer to LabMD than to the Fortune 1000. The empirical research being presented to the court effectively says that firms with privacy- and security-focused subgroups within their legal departments that have budgets exceeding LabMD’s annual revenue pay a great deal of attention to and engage extensively with the FTC.

Not to be snarky, but that kind of makes LabMD’s point. In the FTC’s worldview, every company can be expected to have a million-dollar legal department. The utter unreasonableness of this worldview is apparent on its face – the only remarkable thing is that the FTC has found lawyers willing to make these arguments in court without a bag on their head.

So while I agree with the law professors that the FTC did and does have authority to regulate HIPAA-covered entities, and while I understand the value in not locking in a cookbook list of “unreasonable” data security practices, amici fail to address the reality of functioning as a(n) SMB and fail to demonstrate the benefit to society of aggressively pursuing SMB who have data security failures. Seriously: do any of the amici believe that a heavy-handed 20-year auditing punishment that FTC offered LabMD as part of its “settlement” offer was warranted or appropriate or has any benefit to society?

Even an example amici cite as support for their claim that there was nothing unusual about the LabMD case – the Eli Lilly case – is questionable, as in that case, there was a breach, and patients knew about it and might experience “insecurity” or worry. In this case, there was no evidence that anyone outside of Tiversa and those they shared the data with ever knew about the exposure. Certainly the patients who did not even know of the exposure did not worry or experience “insecurity.” And statistically speaking, while they would have experienced an increased risk of identity theft (if the data had been downloaded by criminals), even the increased risk still could not be shown to be a “likely” harm. But if FTC was so worried about that, then why did they not notify patients back in 2010 or seek an injunction ordering LabMD to notify them back then? Instead, they took no steps to determine if there had been actual tangible injury and waited until 2016 to order LabMD to notify them.

Yes, Congress intended for the FTC to be proactive in preventing breaches that would harm consumers. But the FTC acknowledged in 1980 that they were not concerned with “merely speculative harms” and there generally should be more than just emotional harm for a practice to be considered “unfair:”

First of all, the injury must be substantial. The Commission is not concerned with trivial or merely speculative harms.12 In most cases a substantial injury involves monetary harm, as when sellers coerce consumers into purchasing unwanted goods or servicesl3 or when consumers buy defective goods or services on credit but are unable to assert against the creditor claims or defenses arising from the transaction. 14 Unwarranted health and safety risks may also support a finding of unfairness.15 Emotional impact and other more subjective types of harm, on the other hand, will not ordinarily make a practice unfair. Thus, for example, the Commission will not seek to ban an advertisement merely because it offends the tastes or social beliefs of some viewers, as has been suggested in some of the comments.16

Yet in LabMD, there was no tangible or substantial harm demonstrated – not a single victim – and the FTC wound up tying itself into a pretzel trying to argue that the risk of harm and the exposure of medical information itself constituted a substantial harm. If that’s the case, then every time there’s an exposed database involving protected health information that includes SSN or health insurance account number, can and should the FTC take enforcement action and put a small business under 20 years of monitoring even if the incident was a “near-miss?”

There are many of us who would like to see the FTC (and OCR) enforce more, not less. But when the FTC takes a sledgehammer to a(n) SMB and exaggerates the harm consumers suffered, nobody benefits. Certainly not small and medium businesses who do not have the resources to hire CPOs and entire security teams. And without SMB, where will our country be economically?


Feb 202017

In the first part of a discussion of an incident reported by CoPilot Provider Support Services, this site reported claims by John Witkowski, a former employee, that CoPilot had not reported accurately on the incident. In this part, we focus on just one of CoPilot’s claims – that they are not a business associate under HIPAA.

When CoPilot Provider Support Services recently disclosed a security incident that they had known about since 2015, they claimed that they were not a business associate under HIPAAtelling Security Media Group that the firm “supports physicians in the furtherance of payment or healthcare operations. As such, it is not a business associate to physicians but it is covered by HIPAA in its relationship to providers. HIPAA permits physicians to disclose PHI to organizations like CoPilot – with or without a BAA [business associate agreement] – since disclosure(s) is in furtherance of payment or healthcare operations.”

Experts consulted by Marianne Kolbasuk McGee for the story found their statements confusing, and possibly inaccurate. DataBreaches.net, too, found the claims somewhat confusing.

CoPilot’s site describes its services and includes the following:

… By taking a consultative approach to our services, each reimbursement support program is customized to our clients’ needs but could involve the following core components:

  • Benefit verifications
  • Prior authorization assistance
  • Billing and coding support
  • Monitoring of payer policy and verification
  • Appeals management

DataBreaches.net’s understanding of the service is that any physician can use the monovischcp.com site, although they should register for it. Once they input their patient’s information, CoPilot makes calls to the health plan to determine eligibility/authorization, and then emails the physician the outcome.

According to John Witowski, the former employee whose claims were discussed in the first article, if the injections are authorized by the health plan, then:

If CareMed can fill the prescription, CoPilot sends it to CareMed to be filled. (This should be Patient/Provider’s choice. CareMed does a test claim on all pharmacy benefit investigation requests CoPilot gets).

DataBreaches.net asked Witkowski if he was ever involved in any discussions about whether the companies needed to comply with HIPAA while he was employed there. He responded, “All the time. It was required training, as they were handling patient information. As far as I knew, we were ‘HIPAA Compliant’. Clearly not.” In a response to a follow-up question as to whether he knew why CoPilot claims it is not a business associate under HIPAA, he replied, “That one confuses me.”

It confuses a lot of us, it seems.

DataBreaches.net asked CoPilot to explain why they believe they are not a Business Associate under HIPAA’s definition at 45 CFR 160.103. They did not reply, so DataBreaches.net asked a few HIPAA lawyers to review CoPilot’s site and their statements and to offer their opinion based on the site and CoPilot’s statements.

Matthew Fisher of Mirick, O’Connell, DeMallie & Lougee, LLP responded:

On first blush, CoPilot’s service of assisting providers in obtaining reimbursement would be an outsourced service whereby CoPilot obtains the provider’s PHI for purposes of doing something on behalf of the provider. That would clearly fit within the definition of a business associate and make CoPilot a business associate. Such an interpretation is supported by the list of services identified on CoPilot’s website that CoPilot states it can perform for others.

However, more information may be necessary to full determine whether CoPilot was in a business associate relationship with the providers regarding the database that was inappropriately accessed. CoPilot’s statement and press release suggest that the coverage verification website was created and maintained by CoPilot as a general service. In looking at the www.monovischcp.com website identified by CoPilot, it is branded under a pharmaceutical company and identified as for informational purposes only. The website may not be part of support services that CoPilot would offer to a provider who contracts with CoPilot. If the website is maintained for general informational purposes, I can see support for the position that CoPilot was not a business associate of the providers who entered information.

To determine CoPilot’s exact status in connection with each provider’s PHI that was impacted does require more information though. The primary piece would be knowing whether the providers sought out the website and entered the information without any form of relationship with CoPilot, or if the verification was part of a suite of services offered by CoPilot to the providers.

DataBreaches.net also sought an opinion from Jeff Drummond of Jackson Walker. Noting that he does not have definitive facts about their customers and is making some assumptions, he wrote:

If CoPilot’s only customers were non-covered entities such as pharmaceutical companies that don’t sell to the public, then CoPilot arguably would not be a business associate.

But the description of CoPilot’s services under reimbursement support sure seems to indicate that some of their customers are providers who are billing patients/payors for their services. At least some of those providers almost certainly are “health care providers” who conduct electronic transactions covered by HIPAA. If so, then CoPilot is a business associate if they provide claims processing services that involve the use or disclosure of individually identifiable health information.

Unless their customers are not covered entities under HIPAA, I don’t see how CoPilot could not be a business associate under HIPAA. Seems impossible to me. I’d want to hear their argument, but it really beggars belief.

The fact that two experienced HIPAA lawyers could not draw definite conclusions based on information provided on the sites suggests that at the very least, CoPilot and/or Depuy Mitek, who publishes the Monovisc site, might want to have some statement about HIPAA on the site and whether the service implicates HIPAA in any way.

Does HHS/OCR Believe CoPilot is Covered?

Importantly, perhaps: after investigating the complaint Witkowski filed about the security incident on December 23, 2015, OCR notified him on November 26, 2016, that

After careful consideration, OCR has determined that it will pursue action regarding your complaint’s allegations. Therefore the covered entity has been notified of the complaint.

So perhaps OCR believes that CoPilot is a Business Associate or covered entity under HIPAA? Yes, there have been cases where they have investigated and then determined that the entity was not covered, but is that likely to be the case here?

The incident does not appear on HHS’s public breach tool at this time, and it is not clear whether CoPilot has submitted it or not, even though they claimed that “out of an abundance of caution,” they had communicated with OCR and “otherwise taken all necessary compliance steps pursuant to HIPAA.”

Perhaps OCR will get an answer from CoPilot as to why the lengthy delay in notification to patients, but if CoPilot is covered by HIPAA, they may find themselves with some serious problems, and not just over the very delayed notification. Then, too, any HIPAA-covered physicians who used or use the service without having any business associate agreement in place may find themselves in trouble if they should have had a business associate agreement in place.

But even if it should turn out that CoPilot is correct in their claims with respect to HIPAA, they could still potentially face complaints from state attorneys general or the Federal Trade Commission over their lack of timely notification over the breach. Absent a written request from law enforcement to delay notification, DataBreaches.net is hard-pressed to think of any valid justification for taking more than one year to notify patients, unless CoPilot intends to argue that its risk assessment indicated that no notification was necessary. But if that’s the case, then why notify at all?

Feb 192017

When CoPilot Provider Support Services recently disclosed a security incident that they had known about since 2015, their statements might have led you to believe that a disgruntled former employee had hacked them or misused previously authorized access, and that law enforcement might be looking into criminal charges. If you thought that, you were wrong on both counts. 

CoPilot Provider Support Services (“CoPilot”) describes itself as a “healthcare administrative services and information technology organization.” One of its services enables physicians to determine if their patients’ medical insurance would cover them for injections of Monovisc and Orthovisc, injections used to treat osteoarthritis. Monovisc and Orthovisc are distributed by Depuy Mitek, a division of Johnson & Johnson. If authorization is approved, the medications may be provided by CareMed Specialty Pharmacy, CoPilot’s affiliated firm. CareMed and CoPilot are both owned by Moby Kazmi; the President of the firms is Nuaman Tyyeb.

CareMed, a specialty pharmacy, is related to CoPilot, a HUB company.

In 2015, a database with 220,000 patients’ protected health information was involved in a data security incident. In its notification to patients more than one year later, CoPilot wrote, in part:

On December 23, 2015, CoPilot received complaints claiming that personal information submitted to the site, including health information, was accessible for downloading from the website. ……… As a result of CoPilot’s investigation, CoPilot believes that it identified the individual who accessed CoPilot’s database through unauthorized means and downloaded certain health information, and that the data was not accessible for downloading by the general public from the website. Subsequently, CoPilot referred the matter to law enforcement. Our understanding is that the law enforcement investigation supports CoPilot’s conclusion about the identity of the responsible individual.

John Witkowski.

The unnamed individual appears to be John Witkowski, who was their Senior VP of Marketing and Sales for seven years, ending in February, 2015. In an extended interview with DataBreaches.net, Witkowski claimed that CoPilot and CareMed have engaged in multiple fraudulent activities over the years, and that several inaccurate claims they’ve made about the data security incident are only the tip of a very large iceberg.

Witkowski explained that in 2014, CareMed settled federal and state charges under the False Claims Act. As part of the settlement, CareMed admitted that its employees posed as employees of physicians’ offices when they sought approval for medications, and that employees also fabricated patient clinical information to get insurers to approve the treatments.

According to Witkowski, almost immediately after settling those fraud charges, CareMed/CoPilot principals engaged in more deceptive conduct: purchasing a pharmacy in New Jersey so that they could get a contract with Express Scripts, who had cancelled their contract after CareMed admitted guilt on the fraud charges. Not knowing that they were dealing with the same principals, Express Scripts would give the new entity network status and CareMed’s principals would continue to have a lucrative contract, Witkowsi claims.

Witkoswki says that when he discovered what CareMed/CoPilot had done, he submitted his  resignation, citing their conduct and risks to patient safety that he alleges were also uncovered during due diligence. He claims that the firm initially did not accept his letter of resignation, later tried to terminate him, and has alternately offered him settlement packages and threatened him with litigation. Witkowski showed DataBreaches.net a $1.8m settlement offer from March 2015 that he refused.

The 2015 Security Incident: What Really Happened?

Witkowski claims that CoPilot’s notification and statements contain a number of significant misrepresentations or flat-out lies, including how the incident occurred, and the extent to which the patient data were freely available to the public.

Witkowski claims that in May, 2015, he heard that a CoPilot database was exposed on the internet without any login required. He did nothing at that time to investigate what he had been told, he says, but in October, while doing competitive research for a firm he opened to compete with CoPilot, he visited the site and found that the database was (still) exposed. Anyone just visiting the site, he claims, would see the phpMyAdmin panel, as the home page automatically redirected to it, he claims. A screenshot, taken on October 26, 2015, shows part of the exposed patients database.

Protected health info was exposed online without any login required, Witkowski claims. Screenshot provided by Witkowski, redacted by DataBreaches.net.

There were more than 350,000 records in the exposed database, including patients’ names, addresses, telephone numbers, date of birth, insurance information, and for some patients, Social Security numbers. DataBreaches.net is not suggesting, however, that the 220,000 figure reported by CoPilot is inaccurate, as many databases have duplicate records or test records.

The screenshot also reveals a security problem with the site’s SSL certificate.

DataBreaches.net was not provided with any evidence or witness statement that the data had been exposed beginning in May, 2015, and frankly, it is hard to imagine that the phpMyAdmin panel was exposed like that and no physician/client noticed it or had reported it. Perhaps the forensic report, which CoPilot has not publicly released, could clarify exactly when the database was exposed or accessible without the encryption and security CoPilot claimed it had, as the screenshot provides no evidence that there was any encryption at rest: all of the data were in clear text.

In any event, Witkowski informs DataBreaches.net that he downloaded the data, and began notifying some people of the problem. He did not notify CoPilot/CareMed directly, but according to him, one of the parties he alerted contacted Depuy Mitek. Witkowski tells DataBreaches.net that a Depuy Mitek employee, Amy Gladfelter, promptly called CoPilot’s IT Director, Tynan Markey, to alert CoPilot to the problem on October 26, 2015.

If his statement is true – if CoPilot was actually notified on October 26, 2015 – why did their notification letter claim that they first discovered the breach on December 23, 2015?

DataBreaches.net sent Depuy Mitek emails last week asking them to confirm or deny that Ms. Gladfelter notified CoPilot of the exposed database on October 26, 2015, but they did not reply. DataBreaches.net also sent CoPilot email inquiries last week asking them to respond to Witkowski’s claims that the data had been freely exposed on the internet beginning no later than May, 2015 and that they were first notified on October 26, 2015 by Gladfelter. They, too, did not reply.

But the difference in the length of the data exposure and the date of discovery are not the only parts of the notification that Witkowski has challenged. CoPilot’s notification to patients also claimed that “… the data was not accessible for downloading by the general public from the website.” And that, Witkowski tells DataBreaches.net, is a lie. According to Witkowski, anyone who went to the monovischcp.com site would have immediately seen the database and been able to download it.

Witkowski’s claim received some confirmation from one of the people he claims he notified on October 26, 2015. That individual, a friend of Witkowski’s, informed DataBreaches.net that when s/he typed in the URL Witkowski had provided, a file that “looked like an Excel file” with a lot of patient data appeared on the screen immediately.

When asked how many people he knew of who had viewed the patient data, Witkowski replied, “Currently, I’ve been made aware of at least 3 other people that viewed and accessed the information. I do have indications that more have as well.”

In its emailed inquiry, DataBreaches.net asked CoPilot why they claimed the data would not have been downloadable by the general public. They did not reply to that question, either.

So was Witkowski’s downloading of the data “unauthorzied,” as CoPilot claimed? Well, yes, in the sense that he had no explicit authorization to download it. Then again, there was no pop-up or any login required or notice that would prevent him – or anyone else, he says – from downloading it.

CoPilot’s notification indicates that they referred the matter to law enforcement. Nowhere, however, do they claim that law enforcement ever asked them to delay notification of the incident. So why did it take CoPilot more than one year to begin notifying patients, states, and HHS?

On December 23, 2015, Witkowski filed a complaint with HHS about the incident. At the time, he requested anonymity.

2016: CoPilot Variously Sues, Threatens, and Offers to Settle

In January 2016, CoPilot sought, and obtained, leave to file under seal a Does 1-4 suit in the Eastern District of New York (CoPilot Provider Support Services, Inc. v. Does 1-4). The case was voluntarily dismissed in November, 2016 without any complaint seeming to ever have been filed. It would have been interesting to see what the allegations actually were.

If CoPilot delayed filing any complaint because they hoped that the FBI would recommend prosecution of Witkowski as a criminal, they were likely disappointed. The FBI did investigate, and Witkowski tells DataBreaches.net that he cooperated with them fully.  He showed DataBreaches.net a copy of text messages from September, 2016, in which Special Agent Peter Casson notified Witkowski that they were ready to return his Surface to him. Special Agent Casson also reportedly told Witkowski that they were closing their investigation and had found no evidence of any criminal intrusion.

DataBreaches.net contacted the FBI, who confirmed Witkowski’s claim. FBI spokesperson Kelly Langmesser told DataBreaches.net that the FBI has “closed the investigation into the alleged data breach of CoPilot and we are not bringing forth charges against any person.”

So by September 2016, there was no longer any FBI investigation and yet CoPilot still didn’t notify patients or state attorneys general. Why?

Witkowski believes that part of the explanation for their delay may be that throughout the year, they were trying to get him to sign a settlement agreement that might absolve them of responsibility for the breach and obviate the need for any notification.

In fact, as recently as January 25, 2017, they offered him a settlement that would give him $150,000 for acknowledging responsibility for the breach, withdrawing the complaint about the incident that he had filed with OCR on December 23, 2015, and not disclosing any further details about the incident or the company.To that end, they drew up a letter they wanted his lawyer to sign on his behalf:

CoPilot tried to get Witkowski to withdraw his complaint to OCR, as this draft letter as part of a settlement offer shows. 

Witkowski did not accept the offer. Nor is he concerned about threats of legal action, recently writing to their lawyers, in part:

Now, if anyone would like further clarity, feel free to call me at [redacted]. Otherwise, tell your chicken-shit clients that they get what’s coming to them and if I find out they are fucking with patient safety or privacy again, I’ll make sure they pay the appropriate price again.

But does HHS/OCR have authority to enforce any action on CoPilot? As it turns out, that’s another wrinkle in this case. Read more about what CoPilot claims and what some lawyers think in this companion article.

DataBreaches.net will continue to follow this case. If CoPilot or Depuy Mitek do respond to the inquiries sent by this site, this post may be updated.

Feb 192017

As regular readers know by now, DataBreaches.net has been compiling reported instances of W-2 phishing scams. As part of that investigation, I decided to take a quick look today at some dark net marketplaces to see if any data were up for sale. Brian Krebs had reported on this issue in January after finding a dedicated marketplace. I decided to check some others.

Within minutes, I found listings for 2016 W-2 data, although it is not clear from the listings where the data are from or how they were obtained. Here are some of the listings:

2016 W-2 data up for sale


2016 W-2 data up for sale

2016 W-2 data up for sale

DataBreaches.net attempted to find out whether the data in the first two listings might be from any of the known W-2 incidents. One vendor responded that most of the ones for sale are from Florida, while the rest are from Hawaii, North Carolina, South Carolina, and California. DataBreaches.net has reported on phishing incidents in schools in most of those states already, and is trying to obtain additional details from the vendor. The second vendor stated that all of his listings are from just one state, and I’m trying to find out which one. I’ve asked both vendors whether they’ll tell me if any are schools. 

The third listing linked to a sample with an unredacted W-2 form. The employer was not a firm that has reported having any breach this year, and an attempt to contact the employer was unsuccessful as the phone number obtained in a Google search has been disconnected.

Similarly, DataBreaches.net found another listing that is not being posted on this site just yet  because the sample image came from a college in Florida that has not disclosed any W-2 incident this year. DataBreaches.net called the college and left a detailed message with their campus security about the concern and offered to send them the information on the marketplace listing and the partial employee information that was visible in the listing. Although some of the information in the sample W-2 was redacted, DataBreaches.net was able to track down the employee whose W-2 this would be. The employee confirmed that the data were his data but because he admitted having a copy of his W-2 on his personal device, it’s still not clear whether there was a compromise at the college or a compromise of just the individual employee.

This post will be updated if more information becomes available.

Update 1: The vendor who indicated that all W-2’s were from one state indicated that the state was Florida, and that the source was companies (not schools).

Update 2, Feb. 20: The employee of the Florida college that I’m not naming at this time contacted me to say that he had checked and there was no copy of the W-2 on his personal devices. This morning, I spoke with the CIO of the college who had called me in response to my message yesterday, and they will be investigating. This post will be updated once they complete their investigation and let me know whether it appears that they have had a breach or not.