Americas

  • United States

Asia

Contributing Columnist

When should the data breach clock start?

opinion
Apr 01, 20225 mins
Security

Time is of the essence when a data breach occurs. The tricky part is figuring out exactly when a company first knows about a breach, and how long it has before making it public.

A binary eye peers through a broken network  >  data breach / security break / privacy violation
Credit: WildPixel / Getty Images

One of the most difficult issues in enterprise cybersecurity — something the US Securities and Exchange Commission is now openly struggling with — is when should an enterprise report a data breach?

The easy part is, “how long after the enterprise knows of the breach should it disclose?” Different compliance regimes come to different numbers, but they are relatively close, from GDPR’s 72 hours to the SEC’s initial four days.

The tricky part is defining when any corporate entity actually “knows” something has happened. At what precise moment does Walmart or ExxonMobil know anything? (If the language said “when the enterprise’s CFO becomes convinced that a data breach has happened,” this would be far more straight-forward.)

To figure out this awareness issue, we first need to break it down into two distinct elements:

  1. What constitutes reasonable evidence of a data breach?
  2. Who should make a data breach decision for an enterprise? The head of the Security Operations Center (SOC)? The CISO? The CIO? The CEO? A subset of the board? The entire board? Maybe just the chair of the board? 

Let’s start with element one. With the exception of obvious attacks — such as a ransomware attack where a ransom along with proof of intrusion has been received — most attacks present themselves gradually. Someone in the SOC detects an anomaly or something else suspicious. Is that enough to report? Almost certainly not. Then someone more senior in the SOC gets involved.

If things still look bad, it is reported to the CISO or the CSO. That executive might say, “You’ve sold me. I need to immediately report this to the CIO, the CFO and maybe the CEO.” If so, that still hasn’t reached disclosure stage. Those other execs need to weigh in. 

More likely, though, the CISO/CSO will push back, saying something like, “You people don’t have this nailed down yet. It still be any one of a hundred different things. Look at some backups, make comparisons, check the darkweb for any confirmation. Keep investigating.”

Does the clock start yet? Again, probably not. An enterprise can’t report every single cybersecurity investigation. The level of proof needed to merit a public disclosure is high. After all, pity the poor executive who reports a breach that later turns out to be nothing. 

Another factor: Most cyberthieves and cyberterrorists are excellent at both hiding their tracks and leaving misleading clues. Monkeying with the logs is common, meaning that IT security can only trust the logs so far — at least initially. Remember how often the first forensics report differs materially from the second forensics report. It simply takes time, even for experienced forensics investigators, to separate truth from something misleading left by the attackers. 

As for the second, who decides who the ultimate decider for a databreach should be? An argument can be made for the top cybersecurity expert (presumably the CISO/CSO) or the people most responsible for the enterprise (CEO or board), but for some enterprises, the Chief Risk Officer might be a good candidate. 

Does every enterprise choose for itself? Should the regulators decide? Or should regulators let every enterprise decide on its own who the point person will be and report that title to the regulators? 

Jim Taylor, the chief product officer at cybersecurity vendor SecurID, argues that the trigger should happen right there in the SOC.  “Having something ping your fence is not a trigger. Maybe it’s the senior analyst, maybe it’s the SOC manager,” Taylor said. “There needs to be culpability, responsibility for these things.” 

But having to make a decision too early can be problematic. Report a breach prematurely and you’re in trouble. Report a breach too late and you’re in trouble. “You’re damned if you do and damned if you don’t,” Taylor said.

The truth is that this stuff is hard and it should be hard. Every breach is different, every enterprise is different, and rigid definitional rules will likely create more problems than they solve.

“The nature of how the breach took place is a tremendous factor in when to disclose it,” said Alex Lisle, the CTO of Kryptowire, another cybersecurity firm. “If you’re thinking about it enough to retain a forensics team, then you should think seriously about reporting it.”

There was a great line in the old ‘Scrubs’ TV show, where a doctor in charge of a testing lab asks someone who wants a test redone, “Do you think I was wrong or are you hoping I was wrong?” That line can often come into play as various people are trying to determine if the enterprise truly had been attacked. Does the team kind of/sort of know that they’ve been attacked and are hoping such further investigation will disprove that? Or does the team truly not know? 

That’s where an appointed head of breach determination needs to step in, based on experience and, honestly, a strong gut feeling. Some parts of cybersecurity are pure science. Making a very early decision about whether data has actually been touched is often not.

Contributing Columnist

Evan Schuman has covered IT issues for a lot longer than he'll ever admit. The founding editor of retail technology site StorefrontBacktalk, he's been a columnist for CBSNews.com, RetailWeek, Computerworld and eWeek and his byline has appeared in titles ranging from BusinessWeek, VentureBeat and Fortune to The New York Times, USA Today, Reuters, The Philadelphia Inquirer, The Baltimore Sun, The Detroit News and The Atlanta Journal-Constitution. Evan can be reached at eschuman@thecontentfirm.com and he can be followed at twitter.com/eschuman. Look for his blog twice a week.

The opinions expressed in this blog are those of Evan Schuman and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.