SBN

Cooking up Better Security Incident Communications

I am fond of meal kits. I enjoy the entire experience: the scrolling through delicious-looking meal descriptions, the excitement of receiving a package full of ingredients, the smells while learning how to make the recipe, and of course tasting that first bite of the new things you created with your own hands. I have not bought a meal kit in a while, so a couple weekends ago I decided to seek out the current top-rated services, and give one a try. Home Chef (www.homechef.com) peaked my interest because it made the top of several recommendation lists and promises a large variety of meal options.

To my dismay, I soon discovered that Home Chef recently fell victim to a Data Security Incident.  Strangely, this has only really made the news on May 20, 2020: (e.g. https://www.bleepingcomputer.com/news/security/home-chef-announces-data-breach-after-hacker-sells-8m-user-records/, https://www.cnet.com/news/home-chef-confirms-data-breach-after-customer-info-reportedly-sold-on-dark-web/), when it became more known that the attacker allegedly posted some 8 million records on the dark web.  Ironically, I know for a fact that Home Chef published their breach FAQ at least several days earlier, because I read it on the 16th. It was my intent to use Home Chef as an example for this blog. It bothers me that news writers would imply that a company such as Home Chef didn’t disclose the breach until after they asked about it, as this is not true. In fact, ZeroFox even wrote about the stolen records on May 7, nearly two weeks before other groups claimed credit for the discovery. Now, I don’t know if ZeroFox was the first to post the finding, but I do know that this two week discrepancy means some folks should be doing better fact checking before they publish their news articles (i.e. just about everyone who jumped on the bandwagon on May 20).

This being said, this article is not really about the breach, which is just one more in a long line of breaches.  What I want to bring up is the fact that Home Chef tried to respond to the public but did so in a very mediocre-at-best way. To be clear, I don’t believe Home Chef is to blame. They wrote over 10 FAQ articles to address questions about the incident. My concern is that even after the huge number of breaches we have experienced in recent years companies still seem to be guessing on how best to communicate the details. To be clear, plenty of incident response guidance and even templates for how to draft that initial notification email to affected customers already exists. But what I have not seen is a template or guidance for what information should be posted on a company’s public website.  So I made one: https://secureideas.com/knowledge/how-should-i-communicate-a-breach-faq.

This wouldn’t be a proper ranting blog post if I didn’t at least comment on Home Chef’s FAQ a little bit, so here you go (and please take this for  the constructive criticism / lessons learned it is intended to be):

  1. Dates. There are no dates at all in their FAQ. When did Home Chef become aware of the incident and, even better, when was the data compromised?  The FAQ page doesn’t even have a date the FAQ itself was updated. As a newcomer to your page, I can’t tell if this happened last week or last year. If I need to turn to Google for answers, then you are missing something important.
  2. Require password resets. Home Chef’s guidance to the question: “Should I Reset My Password?” is: Although passwords were encrypted, we recommend you change your Home Chef password in an abundance of caution following the four-step process. The essence of this statement seems good, and I am sure from a PR perspective it is considered the safe answer. But I see a couple of problems with it:
    • Based on the sample of the breach data, the passwords appear to be hashed using “bcrypt”. Technically, hashed is not the same as encrypted. In layman terms, you can get away with using the term Encrypted here, but knowing that the information security community will probably read this information, a little more precision is preferred. In this case, I would have felt more at ease knowing that Home Chef uses “bcrypt”, as it is a password hashing algorithm that I would recommend.
    • The advice implies that changing your password is recommended, but especially for people who are overcautious. Nowhere does Home Chef’s FAQ indicate how their password encryption is special; in a world where we normally tell customers that it is necessary to change their compromised password (even one that is encrypted), why would that now be considered just an abundantly cautious recommendation? 
  3. You have to dig for this FAQ. It is not on the homepage of the homechef.com website. Instead you have to visit the home page, look for the FAQs & Support section under Resources (in the footer), and then look for the articles on the FAQ.  I don’t believe it is being intentionally buried, but Home Chef is not really putting it out there either. If this was a small breach, I would be less concerned about it. But we are talking about 8 million records that include emails, password hashes, last 4 digits (of CC number) and more. The FAQ about the breach should be more obviously accessible on the web page.

All in all, I think Home Chef did an okay job of addressing the breach details. But they could have done better.  At a minimum, the lack of dates and stronger advice to change passwords should be addressed.  While it would be easy to point fingers at Home Chef’s team for these missing details, I find it unfair to do so when the InfoSec community has not provided guidance for situations like this.  As a community, we tend to focus most of our attention on addressing the technical details and we sometimes forget the importance of communication. We should be doing better at explaining to companies how to disclose a breach on their website.

Related Content: https://secureideas.com/knowledge/how-should-i-communicate-a-breach-faq


*** This is a Security Bloggers Network syndicated blog from Professionally Evil Insights authored by Jason Gillam. Read the original post at: https://blog.secureideas.com/2020/06/cooking-up-better-security-incident-communications.html