Last month I had the opportunity to speak at ISACA’s Cybersecurity Nexis North America and was pleased to see that my session, titled “The ABCs of Incident Response Management,” was part of a learning track designed to specifically address how we prepare for and respond to inevitable incidents.
Despite the growing awareness of purpose-built automation and best practices, misconceptions in incident response management persist. I have a unique vantage point as CEO of RADAR, because I can see firsthand the reality of how organizations manage incidents, and the trends that surface in the process. A significant volume of incidents involving regulated data have been processed through RADAR since it was first developed, and that number grows every day. It is important to note the distinction here between a data incident and a data breach. Breaches are far less common than incidents when there is a strong culture of detection, risk mitigation and compliance.
By analyzing incident metadata and looking across key industries that deal in regulated data, the analysis reveals a few insights where the common industry conceptions may be challenged. The misconceptions are largely due to analysis of reported data breaches as opposed to data incidents.
Misconceptions in Incident Response #1: In today’s security settings, your electronic data is most at risk.
In reality, electronic incidents may expose more records per incident, but paper incidents – for example misdirected mail or fax – are much more commonplace. Given the prevalence of news about cyber attacks in the media, you may think that electronic incidents are the most common type, but in fact the majority of data incidents are paper related across the three major industries dealing with regulated data:
This common misconception that most incidents are electronic is further perpetuated in reports such as the 2015 BakerHostetler Data Security Incident Response Report (PDF), which indicated that one in five breaches involved paper records across multiple industries – but this is only taking into account the incidents handled by outside counsel, which excludes many day-to-day data disclosures such as misdirected mail or faxes that are handled internally. This is something to consider as more states – like Rhode Island this year – are expanding their data breach notification laws to specifically include paper incidents. Every day there are small incidents involving just a few records, and every incident, including paper, must undergo a compliant multi-factor risk assessment to establish your burden of proof – particularly when deciding not to notify because you were able to properly mitigate the risk as permitted by law.
Misconceptions in Incident Response #2: If I have an incident that involves regulated data exposure, it is a data breach.
Despite the breach presumption, not every regulated data incident is necessarily a data breach. There is a perception that an incident involving sensitive, regulated data is automatically a data breach and notifiable by default. In fact, our data indicates that the majority of incidents, when properly risk mitigated and run through a compliant multi-factor risk assessment, do not meet a breach threshold:
Consider this: in the Verizon 2016 Data Breach Investigations Report, the dataset of over 100,000 incidents included only 3,141 confirmed data breaches. When making a breach determination, a combination of factors are involved, related to jurisdictions, details of the incident, risk of harm, etc. For instance, the combination of regulated data elements exposed may not together be considered personally identifiable in certain jurisdictions. Perhaps mitigation efforts have allowed for the data to be recovered without unauthorized use or access. The fact that the majority of incidents aren’t notifiable by law does not mean that incidents do not need to be investigated, documented, and run through a risk assessment. Each organization must show proof of a compliant multi-factor risk assessment for each non-notifiable incident, and it is often only in the investigating and assessing process that mitigating factors which might preclude notifications are found.
Misconceptions in Incident Response #3: Incidents occur because your organization is under attack.
While a culture of compliance depends on preparation for security scenarios – including the possibility of attacks on your data – in reality, the majority of incidents occur due to human error, not malicious intent:
Given the types of high profile cyber threats that carry the most coverage in the news – ransomware, DDOS attacks, etc. – there is a tendency to think that data incidents only occur as a result of being “under attack.” In reality, process breakdowns and poor employee training – unintentional or inadvertent disclosure of regulated data – are far more common. Consider the case of a lost laptop, or an email with sensitive information accidentally forwarded within the company to someone who is not authorized to see that information. Inadvertent disclosure of regulated data may also be growing – in their 2016 report, the Identity Theft Resource Center attributes nearly 15% of reported breaches from 2015 to be due to employee error/negligence, more than double the percentage from their 2012 report.
Lessons for Improvement
Here are a few guidelines to help organizations combat common misconceptions in incident response and develop better processes to solidify incident response management efforts:
- To successfully manage incident response, organizations must clearly define and distinguish between an incident and a breach. Breach is a legal term and should not be loosely used to describe incidents.
- An organization must presume that incidents involving regulated data are notifiable. The burden of proof will always fall on the organization to conduct and demonstrate the performance of a thorough and consistent risk assessment of each incident for breach determination – regardless of incident type, number of records exposed, or intent.
- Once an organization determines the incident is a breach, they must know what each jurisdiction requires for compliance.
Related Reading: