The message came in via email, self submit forms, Twitter and the internet: “Domino's Pizza has until Monday at 8PM CET to pay us. If they do not do so, we will post the entirety of the data in our possession on the Internet.”
Domino's Pizza wasn't the first company to fall victim to a group operating under the ‘Rex Mundi' brand. It joins a slew of businesses and financial institutions whose customer data has been held to ransom. However, the familiar characteristics of the case point to increasingly uncomfortable and likely questions for security professionals: ‘would you know what to do?'
The immediate questions faced by companies in Domino's position show the scale and complexity of incident response (IR). What is the threat? What should we tell customers, if anything? What do regulators need to know? How do we initiate technical remediation? Should - or can - we respond to ransom demands? Addressing these questions depends in turn on further, complex variables. What systems are compromised? Was card data involved? Which legal requirements apply? Ultimately, how confident is the organisation that the IR plan is correct for this unique situation?
Given these characteristics of scale and complexity, it's unsurprising that for most companies, IR remains a closed book - literally. Procedures often reside in lengthy documents or spreadsheets, often based on general ISO standards. It has likely been subjected to only limited rehearsals, probably avoiding the weekend. Almost certainly, it won't have entered the organisation's muscle memory – that is, become a process that team members can follow without really even thinking about it.
Response to an incident like this typically includes the following phases:
· Engage Phase (five tasks): pull together the team members from across the organisation that are appropriate to this specific situation – don't restrict this to IT, but include legal, HR, marketing, etc as appropriate.
· Detect/Analyse Phase (13 tasks): gather the necessary data to best understand the situation and gauge it's impact – don't wait for perfect information, rather assess and iterate over time.
· Respond Phase (10 tasks): execute the IR plan, refining as you go.
· Data Breach – Authority Notifications (one task): notify the appropriate authorities; in this case, this would include within France and Belgium.
· Data Breach – Individual Notifications (two tasks): notify the affected individuals; be sure that the timing and nature of this notification considers applicable regulatory requirements.
· Data Breach – General (six tasks): there are a range of other activities that should take place both within and outside IT, based on IR best practices and organisational standard operating procedure.
Incident response isn't just about forensics, next-gen malware detection, or meeting regulatory requirements. IR mustn't happen just because of a successful cyber breach, insider threat, or lost laptop. A good Incident response team manages all of these, and most important of all, gets the business back running quickly, safely, and in compliance with its own and external procedures. Arguably given today's threat and regulatory environment, incident response management is a vital part of the modern security function (if not overall IT function). The practical lesson of Domino's and other case studies is that companies should simulate and practice their IR so that they develop IR muscle memory. When called on due to an incident they will need to react in a short space of time. They can neither afford unnecessary overhead tasks and resources, nor learning on the job. Yet despite complexity, the challenge of mapping out and executing an optimal response is both tractable and achievable. Organisations that rise to the challenge will weather incidents of this nature, getting back to business in a timely and orderly fashion.
Contributed by Ted Julian, co-founder and CMO Co3 Systems