Tag: Suspicious activity report

28 Oct 2011

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 BusinessDictionary.com 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.

07 Jun 2011

SAR Filings – Computer Intrusion vs. Identity Theft

The Financial Crimes Enforcement Network (FinCEN) publishes a statistical summary and review of all suspicious activity report (SAR) filings a couple of times per year.  The latest one was just released in May covering the 10 year period from 1/1/2001 through 12/31/2010.  I thought it might be interesting to see how the category of Computer Intrusion (Part III, item 35 f) compared with Identity Theft (Part III, item 35 u) during that period of time:

As expected, reported incidents of identity theft increased sharply and remain relatively high today…no surprises there.  What did surprise me though is the low reported incidents of computer intrusion over the past 5 years.  (The initial blip in 2003 was due to the fact that when the Computer Intrusion category was added in 2000, it initially defined an intrusion as “gaining access or attempting to gain access to a computer system of a financial institution”.  That meant that each time the firewall blocked an attempt, it had to be reported.  Obviously this proved to be extremely labor intensive, and the verbiage was changed in 2003 to define intrusion as actually gaining access to the system.)

I suppose the lesson here* is that financial institutions are doing a far better job securing their networks then they are securing their customer data, which leads me to the conclusion that the vast majority of identity theft must be occurring outside the protected perimeter of the institutions’ networks.  Remember, you must protect your data at every stage of its existence; during processing, in transit, and in storage, and regardless of its physical or electronic nature.

By the way, the newest SAR form for depository institutions is here.  It was just updated in March, and institutions must use this to replace the older form (dated July 2003) by September 30th of this year.  I compared the two forms side by side to see what the differences were, but couldn’t find a single change besides the date, so I’m not sure why the new form is required, but it is.

*Of course another possibility is that computer intrusions are simply being under-reported, but since most financial institutions have been subjected to regular audits, penetration tests and examinations, I believe that the low incidence is probably accurate.

27 Oct 2010

ID Theft and SAR filings

In the past, authoritative reports on identity theft have used surveys conducted with the general public to collect ID theft related data.  However, in a recent FinCEN report, the data collected came directly from SAR’s filed from the financial institutions themselves, resulting in a much more accurate assessment of the scope of the identity theft problem.

About the SAR: The most recent version of the Suspicious Activity Report (SAR) is dated July 2003, and has required financial institutions to report in the separate category of identity theft since 2004.  (It’s found in Part III, 35 (u), with the narrative in Part V.)  Since the category was made available, the number of SAR filings reporting identity theft has gone from 15,445 in 2004, to 36,210 for 2009.

About ID Theft: The ID Theft/Red Flags Act is actually titled “Identity Theft Red Flags and Address Discrepancies under the Fair and Accurate Credit Transactions Act of 2003”, and was approved by the FFIEC and all regulatory bodies in October, 2007 with compliance mandatory by November 2008.  Since then enforcement has been delayed several times, most recently until December, 2010.  This does not extend the requirement for financial institutions to comply with the act, only regulatory enforcement.  All institutions should have (at the very least) and ID Theft policy, as well as established procedures.

About the report findings: There were a number of interesting findings in this report, but the most interesting to me was that the 2 most commonly identified Red Flags (as listed in Supplement A to Appendix A of the act) were #25 and #26;  or

  • 25. The financial institution or creditor is notified of unauthorized charges or transactions in connection with a customer’s covered account.
  • 26. The financial institution or creditor is notified by a customer, a victim of identity theft, a law enforcement authority, or any other person that it has opened a fraudulent account for a person engaged in identity theft.

These 2 Red Flags accounted for 75% and 23% respectively of all filings.  This is interesting because it appears that the vast majority of the ID theft notifications are coming from the customers themselves.  When combined with the finding that 43% of ID theft related activity is discovered within 4 weeks, perhaps the most effective loss preventive control for institutions to consider is one that delivers account information to the customer more quickly.