Recently, the Payment Cards Industry Security Standards Council (PCI SSC) published a three-page guide titled "Responding to a Data Breach" that articulates its position on the correct response to a security incident at a merchant location where the attack exposed cardholder data. This guidance comes at an opportune time as security incidents continue to make headlines, cost organizations significant sums of money and demonstrate the parlous state of most organizations’ ability to detect and respond to security incidents. 

Proper incident response continues to prove challenging and elusive, even for organizations that undergo PCI Data Security Standard (PCI DSS) validation activities every year. The guide starts off describing the costs of data breaches, particularly for large organizations, based on some statistics from the Ponemon Institute. It covers three major points: preparing an incident response plan, engaging a PCI Forensic Investigator (PFI) and working with the PFI for best results. It also points to a few key areas in incident response like notifying business partners and managing third-party contracts, as well as actually planning out and rigorously testing incident response plans. The guidance also highlights some of the difficulties in developing proper response procedures, specifically the challenges in mapping out complete, thorough procedures that actually hold up under the stress of an actual incident.

In many cases, an organization’s incident response planning failed to account for their third parties, and, when faced with an incident needing the investigative services of a PFI, found, for example, their hosting provider or other managed service provider unwilling to allow the investigator access to the necessary systems or willing only to provide evidence in a forensically unsound manner. This limits the investigation before it starts and, when questions of liability arise, can significantly impact the outcomes.

In some other cases, the affected entity lacks the necessary business continuity capabilities to remove the suspect systems from their environment and preserve the evidence, usually from either a lack of knowledge, the absence of replacement systems to allow for normal business activity to continue while the investigation proceeds, or both. In these cases, the affected organization often continues to use the affected systems, which both widens the potential extent of the compromise and significantly degrades the quality of evidence available to the investigator.

While merchants and service providers that undergo PCI DSS assessments must have an incident response plan, and most have at least something on paper, many of these documents either lack enough specificity or enough accuracy to address an actual incident as it unfolds. This is because assembling a proper incident-response policy is hard. Mapping out the possible event flows for potential incidents and the decision trees that would go into each takes time and dedication and a clear visibility across the entire business, which will likely involve the expertise of a number of different people and groups (yes, this means incident response, like security and compliance overall, is bigger than IT). But this is how an organization lays the groundwork for successful incident response; finding the potential pitfalls and how to address them. Assuming that first contact with an incident will happen in IT or with someone familiar with information security may make sense for some small and technology focused organizations, but may prove unlikely for organizations with a retail or customer service operation. Further, many incident response plans do not account for complications that may arise, such as communications difficulties (a denial-of-service attack may limit the availability of email for correspondence) or the ability to obtain a key decision from a particular individual. By making those decisions in the planning stage an organization will be prepared when it occurs. A few common examples include the following:

• Who has the authority to remove a system from production?
• Who serves as the backup contact if the primary isn’t available?
• Who notifies law enforcement?
• Who handles communications with customers, partners, card brands, banks?

Defining a fully featured incident response plan and adequately testing and maintaining it is a significant ongoing task, but an essential one for organizations that handle payment cards or other personal data.

Lastly, the guidance document talks about working with a PFI in the event of an incident and understanding what that investigation will cover and what the affected organization needs to do to cooperate with the investigator for a swift and effective resolution. What the guidance document does not address expressly—but causes problems for many PFIs—is when the affected organization, often at the behest of their legal counsel, employs another investigator to perform some preliminary investigative work (potentially as a defense against litigation or other liability). Unfortunately, this can compromise the integrity of the evidence and hamper the PFI’s work. Because so many attacks, particularly against smaller organizations, come from the same criminal groups or use the same or very similar malware, the card brands and financial institutions can use the evidence from a successful investigation to look for similar attacks, and in some cases, warn similar organizations before they become the next victims of a nearly identical attack. As such, preserving the evidence remains a crucial element to determining these indicators of compromise and looking for similar attacks and preventing future ones, and non-PFI investigators can just as easily hamper that as they can provide aid to their customers.

Ultimately, attacks against vulnerable payment systems will continue, and attackers will innovate when necessary and scale their attacks to the greatest extent possible. A robust defense against this includes both preventative and responsive measures, including a carefully prepared incident response plan that accounts for any given entity’s unique combination of systems, people and organization. The PCI SSC’s document attempts to provide some guidance for these organizations, but it’s up to each individual company to take that guidance into account and prepare appropriate incident response procedures.

photo credit: Torn & Cut One Dollar Note Floating Away in Small $ Pieces via photopin (license)