I’m starting to wonder if we’re going to see a new tactic for US based companies where they report an initial breach and then report the full extent of the breach later at a more opportune time.
We’ve already seen this whether intentionally or unintentionally with the breaches of Okta and 23andMe. Both reported a small amount of their use base was impacted. Then several weeks later came out and reported it as much larger. It would be an interesting tactic especially since the new SEC rules are now in place as of December 15, 2023, requiring companies to report a material cybersecurity incident within four business days.
Public Relations (PR) departments have always looked for ways to limit the impact of a breach hitting the news wire. They’ll often release bad news on holidays or around other major events. Caesars did while the MGM breach was hot in the news cycle. They released their own breach by the same threat actor. A couple months removed and most people only remember the MGM breach.
I’m in the security news bubble so it’s hard to say if this tactic is working. Okta is a company that’s in the security space so most people outside of security don’t care about it. 23andMe is a DNA testing service for health and ancestry discovery and it’s still early to determine the effectiveness of their PR mitigation.
Looking at it from the companies perspective, we have asked for more transparency from companies on breaches. That could be what we’re getting here. They’re providing additional information for disclosure purposes and education purposes. Being honest and conscientious is not always reward in the media. There are companies who will do the right thing but are others who will not.
I think it is a new tactic and I’ll be curious to see if more companies start trying the strategy of releasing an initial compromised and then coming back later to, “correct” it. Especially, in the case of 23andMe who has decided to update their Terms of Service to include litigation protection for themselves. It just looks bad.
This blog post first appeared on Exploring Information Security.