The “Security Breach” and your Incident Response Program

The “Security Breach” and your Incident Response Program

Last week Wells Fargo said that some of their customers in South Carolina and Florida received portions of other customers’ bank statements in the mail as the result of a printer error.  Essentially a printer malfunction caused some printed statements to contain a portion of another customer’s statement to be appended to the bottom.  A Wells Fargo spokesman said that “we’re treating this matter as an information security breach.”  This got me thinking about what constitutes a “breach”, vs. what is an “event”, and what the regulators expect you should do about it in either case.

I usually associate a breach with an act perpetrated by an intelligent agent*, and in fact defines breach as “An act from outside an organization that bypasses or contravenes security policies, practices, or procedures.”  Based on this definition the Wells Fargo incident was not technically a breach because it originated from within the organization.  On the other hand, Wikipedia defines data breach as “…the intentional or unintentional release of secure information to an untrusted environment.”  This seemingly would include both internal and external events, as well as intelligent as well as inanimate agents…cause and source don’t matter.

So what does the FFIEC have to say?  They don’t specifically use the “breach” terminology when referring to an information security event, but in the Information Security Handbook they define a security event this way:  “An event that compromises the confidentiality, integrity, availability, or accountability of an information system.”  So cause and source aren’t material to the definition of event, and by this definition the printer malfunction did constitute a security event.

Whether you refer to it as a “breach”, and “event” or an “incident”, your incident response plan must guide your response.  According to the FFIEC, your incident response program should contain, at a minimum, procedures for:

  •  Assessing the nature and scope of an incident and identifying what customer information systems and types of customer information have been accessed or misused;
  • Notifying its primary federal regulator as soon as possible when the institution becomes aware of an incident involving unauthorized access to or use of sensitive customer information;
  • Consistent with the agencies’ Suspicious Activity Report (SAR) regulations, filing a timely SAR, and in situations involving federal criminal violations requiring immediate attention, such as when a reportable violation is ongoing, promptly notifying appropriate law enforcement authorities;
  • Taking appropriate steps to contain and control the incident to prevent further unauthorized access to or use of customer information; and
  • Notifying customers when warranted in a manner designed to ensure that a customer can reasonably be expected to receive it.

Whenever I see events like this in the news, I see an opportunity for financial institutions to use it as training.  Conduct a table-top drill using the details of the actual event as your scenario.  Dust off your incident response plan, and follow it to the letter.  The objectives of the test should include such items as:

  • What defines an event?  Under what specific circumstances is the plan activated?
  • Who is notified and when?  Should an SAR be filed?  If customers are required to be notified, how will they be notified?  What will you say?
  • What was the root cause of the incident?  What controls failed and why?  Make sure you document and preserve as many of the details of the event as possible to facilitate the post-event investigation process.

Finally, update your program to address any gaps between what your plan says, and what you would actually do.  Incorporate any additional controls indicated by the post-event analysis back into your information security program.  And re-test as soon as possible to validate all changes.



*Although I suppose you could say that printers and copiers have become more “intelligent” in the sense that almost all of them contain some sort of microprocessor, and even storage, I think of an intelligent agent to mean human-based.

Print Friendly, PDF & Email
Tom Hinkel
As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.

Write a Comment