![](\"https:\/\/images.idgesg.net\/images\/article\/2020\/04\/data_breach_security_break_privacy_violation_by_wildpixel_gettyimages-938734264_2400x1600-100838210-large.3x2.jpg?auto=webp&quality=85,70\"\/)
<\/p>\n
Credit to Author: Evan Schuman| Date: Fri, 01 Apr 2022 08:39:00 -0700<\/strong><\/p>\n One of the most difficult issues in enterprise cybersecurity \u2014 something\u00a0the US Securities and Exchange Commission is now openly struggling with<\/a>\u00a0\u2014 is when should an enterprise report a data breach?<\/p>\n The easy part is, \u201chow long after the enterprise knows of the breach should it disclose?\u201d Different compliance regimes come to different numbers, but they are relatively close, from GDPR\u2019s 72 hours to the SEC\u2019s initial four days<\/a>.<\/p>\n The tricky part is defining when any corporate entity actually \u201cknows\u201d something has happened. At what precise moment does Walmart or ExxonMobil know anything? (If the language said \u201cwhen the enterprise\u2019s CFO becomes convinced that a data breach has happened,\u201d this would be far more straight-forward.)<\/p>\n To figure out this awareness issue, we first need to break it down into two distinct elements:<\/p>\n Let\u2019s start with element one. With the exception of obvious attacks \u2014 such as a ransomware attack where a ransom along with proof of intrusion has been received \u2014 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.<\/p>\n If things still look bad, it is reported to the CISO or the CSO. That executive might say, \u201cYou\u2019ve sold me. I need to immediately report this to the CIO, the CFO and maybe the CEO.\u201d If so, that still hasn\u2019t reached disclosure stage. Those other execs need to weigh in.\u00a0<\/p>\n More likely, though, the CISO\/CSO will push back, saying something like, \u201cYou people don\u2019t 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.\u201d<\/p>\n Does the clock start yet? Again, probably not. An enterprise can\u2019t 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.\u00a0<\/p>\n 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 \u2014 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.\u00a0<\/p>\n 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.\u00a0<\/p>\n 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?\u00a0<\/p>\n Jim Taylor, the chief product officer at cybersecurity vendor SecurID, argues that the trigger should happen right there in the SOC. \u00a0\u201cHaving something ping your fence is not a trigger. Maybe it\u2019s the senior analyst, maybe it\u2019s the SOC manager,\u201d Taylor said. \u201cThere needs to be culpability, responsibility for these things.\u201d\u00a0<\/p>\n But having to make a decision too early can be problematic. Report a breach prematurely and you\u2019re in trouble. Report a breach too late and you\u2019re in trouble. \u201cYou\u2019re damned if you do and damned if you don\u2019t,\u201d Taylor said.<\/p>\n The truth is that this stuff is hard and it should<\/em> be hard. Every breach is different, every enterprise is different, and rigid definitional rules will likely create more problems than they solve.<\/p>\n \u201cThe nature of how the breach took place is a tremendous factor in when to disclose it,\u201d said Alex Lisle, the CTO of Krytowire, another cybersecurity firm. \u201cIf you\u2019re thinking about it enough to retain a forensics team, then you should think seriously about reporting it.\u201d<\/p>\n 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, \u201cDo you think I was wrong or are you hoping I was wrong?\u201d 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 <\/em>that they\u2019ve been attacked and are hoping such further investigation will disprove that? Or does the team truly not know?\u00a0<\/p>\n That\u2019s 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.<\/p>\n http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Credit to Author: Evan Schuman| Date: Fri, 01 Apr 2022 08:39:00 -0700<\/strong><\/p>\n One of the most difficult issues in enterprise cybersecurity \u2014 something\u00a0the US Securities and Exchange Commission is now openly struggling with<\/a>\u00a0\u2014 is when should an enterprise report a data breach?<\/p>\n The easy part is, \u201chow long after the enterprise knows of the breach should it disclose?\u201d Different compliance regimes come to different numbers, but they are relatively close, from GDPR\u2019s 72 hours to the SEC\u2019s initial four days<\/a>.<\/p>\n<\/p>\n