Hours after Yahoo disclosed this latest data breach, people asked why it took the company so long to come clean about a compromise dating back to 2013. To the casual observer, three years is a long time, and it makes them suspicious that the company was deliberately keeping users in the dark.
In Yahoo’s case, suspicion is particularly high because it’s the second breach disclosure in three months – the previous breach dating back to 2014.
Yahoo is hardly a special case. Companies often disclose breaches that happened a couple years beforehand. Target is one of many examples.
But there are reasons it takes a long time to disclose a breach. More often than not, the lag is anything but sinister. Usually, it’s a matter of how long it takes to discover that a compromise may have happened. From there, it takes time for a company to investigate and piece together the big picture of what happened.
And sometimes, it’s because company execs waste time dithering.
Yahoo said in its official statement yesterday that law enforcement provided the company with information just last month – data files a third party claimed was Yahoo user data. Yahoo said it analyzed the data with the assistance of outside forensic experts and determined it was in fact Yahoo user data.
Three things that slow investigations
Wim Remes, CEO and principal consultant at NRJ Security, said there are three reasons organizations take longer than desired to detect and disclose a breach:
Visibility: Are organizations able to see what they need? In many cases the answer is no. “So many technologies that are deployed within organizations are data hoarders. Instead of facilitating the gathering and correlation of data, they make it incredibly hard to do so by focusing on fancy dashboards and basic data analytics,” Remes said. “Security solutions should be data providers instead, with simple APIs that allow organizations to pull the data they need, as they need it.”
Accountability: While companies do have data that could help them identify breaches and their impact, it is unreasonably hard to tie that data back to asset owners and/or stakeholders, Remes said. “Processes tie resources to activities so being unable to work with decision makers (or being unable to make decisions yourself) slows organizations down to a point where it takes months or even years to identify and react to breaches,” he added.
Agility: Security is but one function of a complex organization. Remes said it’s rare to see an enterprise where infosec has a seat at the table or the ear of stakeholders. “We often say that security is everybody’s responsibility, but in reality making money is,” he said. “Who are we kidding? If you keep focusing on building a team of security experts instead of creating experts with security knowledge, you won’t reach the point where you are able to react as an organization. You can not count on an isolated security team with minimal reach to keep you safe. It’s like expecting that a rubber band functions as a five-point seatbelt in an F1 car. It’s not going to happen.”
Legal differences between states
There’s no federal breach notification law, but almost every state has some breach notification statute. Although there are many similar provisions, states tend to differ on what triggers a response, said Michael Schearer, a Baltimore-based security practitioner specializing in legal matters. The states differ on:
- The number of breached records requiring notification;
- The types of information lost;
- How “personal information” is defined;
- How soon you must comply;
- To whom you need to send notification (to some state agency, and/or to the individuals); and
- The form of the notification.
“In practice, a breach that includes users from the entire country might require you to send seven or eight different kinds of letters depending upon the state and their particular requirements,” he said.
Furthermore, Schearer said, the notification obligation timeline usually starts from when you find out about the breach.
“So if the Yahoo breach was in 2013, but they just discovered it in November 2016, then their clock starts in November 2016,” he said. “Yahoo probably has a law firm that they work with for this sort of thing. They would then work with the law firm to draft notification letters to both the relevant state authorities – in all states where notifications were required – and probably draft a notification letter to send to users.”
The slowing effect of delusion
One security practitioner, who requested anonymity since he is not authorized by his employer to talk to the media, said that in many cases, there’s a lag because company leaders waste time splitting hairs over what does and doesn’t require disclosure.
“I’d bet a dollar to a dozen donut holes that most times it’s due to senior leaders (CEO, chief counsel, etc.) making a decision that a.) under the specific circumstances of the breach there’s no reporting requirement (deluded logic), b.) the risk of disclosing *now* can be diminished by actions to be taken (deluded plans), or c.) ‘I can’t hear you!’ (deluded direct reports).”
Those interviewed cautioned others in the security industry against trash-talking companies that fall victim. After all, the CISO who has fun at their expense could someday find themselves in the center of a data breach firestorm of their own.
“We can point at the Yahoo Security Team and easily blame them for another failure but the reality is that this can happen to any of us,” Remes said.
4 comments on “Yahoo breach: how on earth did it take them three years to notice?”
Is it also possible that our system(s) of internal controls are lacking? Most large organizations have yet to admit that many of the “fundamentals” are simply no longer working. There’s a big control design gap that needs to be understood. I agree that there’ are issues with data analytics which are barriers to detection and response, but there remain these huger design gaps which are barriers to prevention. we are stuck with ideas and internal processes based on a 15 year old view of our problems…
I think there’s also the issue of policy agility.
Oftentimes, security policy is set up in a company which then experiences growth and role shifts. So a password database that was set up back when everyone used MD5 hashes no longer has an active maintainer within the company, other than a group to troubleshoot issues with the actual DB management. A ticket is raised by the security department to audit database security across the company… and this ticket is broken up into sub-tickets, which are then tackled one-by-one. And then part of the company is bought/sold, and new databases are added to the mix… with the end result that the audit is eternal, and never gets to that critical database that has never had a _reported_ breach and doesn’t tend to light up the monitoring systems on a regular basis.
Not saying that this is how things *should* be, but it’s often how they are. Security controls don’t tend to have influential stakeholders until after a breach is discovered.
sorry – meant huge – not “huger” – although huger works too 🙂
I agree with the CEO’s doing “sad damage control” for months for nothing. You make the situation worse taking 1,000 years in meetings trying to “smooth over” things that most times can’t be smoothed over. If you got breached, you’re breached. Theres no other way to say it.