In 2014, the ITRC (Identity Theft Resource Center) tracked 783 data security breaches with 85,611,528 confirmed records exposed. This year appears even more dismal. The ITRC Data Breach Reports 3 for July 7, 2015 captured 411 data incidents with 117,678,050 confirmed records at risk. Since data breaches are a common occurrence in today’s information security threat landscape, it’s going to become de rigueur for companies to pump up security preparedness within their incident response plan.
“The plan cannot simply be static and gather dust; it requires upkeep. The incident response plan should change as requirements and environments change.” — Edwin Covert, Norse Dark Matters
Eric Vanderburg and I, two information security influencers and Dell Insight Partners, discuss which protocols companies should consider when a breach occurs.
Robb: Attempts to contact a breached company (if the breach is unknown to them) often has no direct point of contact for reporting it. For example: Many times the Darkweb will discover vulnerabilities, exploit/extract the data, and share or sell the stolen data before anyone outside of the Darkweb is aware that a breach has occurred. Aside from having a good incident response plan, I believe that there should also be a point of contact for reporting the breach directly to the company and it should be easy to find and openly accessible from the company website.
Vanderburg: You bring up a good point and it is quite relevant considering that more than 69% of breaches are discovered by outsiders.2 I wonder how often a breach is discovered but not reported due to there being no easily discernible way to contact the organization. When organizations are discovering breaches within weeks or months of the breach 3 rather than days, it is imperative that they make use of such a system to allow for breaches to be quickly reported. Of course, I don’t want to imply that organizations should not rely on others to notify them of their own breaches and not perform their own due diligence in breach detection.
So, with that said, the questions I see are who or which group should be the contact within an organization, how that person or entity can be contacted, and how reported breaches should be handled and investigated.
Robb: I think that before we look at who should be delegated as the breach contact within a company, we need to address the incident response plan. How many companies are actually proactively educating IT staff and their employees about breach response workflows? Is the incident response plan just hanging out and gathering dust or is the company conducting regular discussions, scenarios, and incident response drills? I believe that once we establish a solid foundation for a comprehensive incident response plan — the incident response plan should include a communications function within the plan indicating points of contact within the organization, as well as the contacts that will be handling external responses.
Vanderburg: The aforementioned elements should be integrated into the incident response plan and should be part of incident planning discussions. For example, the roles and responsibilities section would contain an incident reporting person and the validation section would describe how a reported incident is validated and whether the it will be classified as an incident resulting in the enaction of further elements of the plan. As you mentioned, training should include identifying the contact person. I have led awareness training sessions and often I will ask the group, “who do you contact to report an incident?” I sometimes get a variety of amusing responses but after that I point out the person or group they should contact and then we walk through indicators of an incident and each person’s responsibility in protecting against data breaches.
Robb: Should the company have their incident response plan “in house” or retain the services of a breach resolution partner?
Vanderburg: The incident response plan is an organizational document much like other policies and procedures so it should ultimately go through review from senior management and reside within the organization. However, it can be quite helpful to bring in experts in developing the plan so that best practices are implemented. Also, an organization may not have the necessary response resources available to them in-house so it is best to identify a 3rd party that is willing and able to perform those activities and to document this in the plan. In such cases, the incident response plan or subsections of it would also reside with the 3rd party incident responder.
Robb: After visiting 10 random company websites from the Alexa top 100, there was no direct point of contact for reporting a data breach at any of these companies. Where should this be implemented in the incident response plan?
There is little doubt that a well-considered, up-to-date, and frequently tested incident response plan is a critical part and parcel of any company’s incident security program. It is also recommended that companies revisit their website navigation design and implement a data breach “point of contact” in the primary navigation area.
Dell SecureWorks: Incident Response Plan: 3 Most Important Elements
How To Build a Data Breach Response Plan: 5 Great Resources
1 IDT911.”ITRC Data Breach Reports.” ITRC 2015. Web. 7, July 2015 http://www.idtheftcenter.org/images/breach/DataBreachReports_2015.pdf
2Heberlein, T (2015, May 29) What Percent of Breaches By Outsiders Are Not Detected By Organizations? [Web log post]. Retrieved July 8, 2015, from http://www.toddheberlein.com/blog/2015/5/29/what-percent-of-breaches-by-outsiders-are-not-detected-by-organizations
3Drinkwater, D (2014, April 14) Data Breach Discovery Takes Weeks or Months [Web log post]. Retrieved July 8, 2015, from http://www.scmagazineuk.com/data-breach-discovery-takes-weeks-or-months/article/343638/
This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.