Event Denial: If I Don't Report It, Did It Really Happen?

Posted on by Christopher Burgess

"If a tree falls in the forest and no one is there to hear it, does it make a sound?" The technological equivalent of this query within cyber security exists, unfortunately: "If a compromise occurs and no one reports it, did it really happen?" The answer in both instances is, "of course." Yet the recent survey of 200 security professionals by Opinion Matters for Threat Track reveals that two-thirds of these professionals dealt with a security incident which was never acknowledged or reported by the company. In essence, an event denial occurs. Manufacturing and utility companies are far more likely not to report a material breach (79 percent of those who had a breach opted not to report it to customers, partners, or other stakeholders), while information technology and telecom (57 percent) and health care (56 percent) were slightly better and less likely to engage in denial or non-reporting than the average of 66 percent.

Why Report?


This begs the question, "why?" When security events are swept under the carpet, only two things can occur, both negative. The first is the event isn't documented, remediated, and addressed and thus is likely to recur. The education and remediation portion of the security continuum is not allowed to occur, and thus the loop of constant improvement doesn't happen. Event denial occurs—the event was never documented; thus, it never occurred. The second is when, not if, the decision to not report or address the incident comes to light, the confidence in and credibility of the company and its ability to be trusted to do the right thing is damaged, perhaps irreparably, with customers, partners, or other stakeholders.

There is a third, if you are in regulated industry. For example, with the health care vertical there is a regulatory requirement to report the breach if it involves the loss of protected health information (PHI). Not only is there a regulatory requirement to report the breach, there is a potential for a fine coming your way courtesy of the Department of Health and Human Services and the Health Care Insurance Portability Accountability Act (HIPAA) if it is not reported.

Perhaps No Reporting Required

But why would someone not report a security event? There are a number of reasons. The incident may have been a security event, but there was no material damage or data breached. For example, a client device goes missing, yet a review of system logs demonstrates the device had full-disk encryption, the encryption protocol on the client was in use, and the device was up-to-speed with required security updates. Situations like these constitute loss of gear and not loss of data. We read, far too often, about people having their laptops heisted from their vehicles or lost at the airport (or forgotten at the security check—1,200 devices a month go missing at the airport security check), the loss of equipment is the internal fiscal report, and the notification is handled internally.

Another example of when a security event may not need to be reported is if the security incident was successfully remediated prior to the exfiltration of information, successful connection to an external element or otherwise prevented from successfully completing the malware's attack. While the bar for this statement is admittedly high, and requires the ability to have one's thumb on the pulse of the organization, its data and remediation protocols, it is viable, and practicable.

In sum, the recommendation is to strive to educate the work force, customers, vendors, and other stakeholders to report any and all anomalies encountered. When that proverbial tree falls, once discovered, it is best to let all concerned know. It will go a long way toward building the trust and credibility within the relationship.

Christopher Burgess

, Prevendra Inc.

risk management anti-malware

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community