By Sean Clark, Director of Security Services
Reprinted from Western Banking March 2006
It looked like it was going to be a routine acquisition — if such a thing exists. First National Bank was set to acquire State Bank.* The due diligence was complete, the directors, officers and staff of both institutions were set and ready to go. And then the unthinkable happened.
Late on a weekend night just days before the acquisition was finalized, State Bank’s IT manager checked his bank’s Web site from home to make sure all systems were go. What he found was distinctly not routine.
It was immediately clear what had happened. The acquiree bank’s Web site, which hosted internal and Internet banking information, had been defaced by an organized group. The defacement was bad enough, but the bigger concern was that customer information may have been compromised in the attack.
The following steps will help any community financial institution react to an incident during a merger or acquisition — and to work to prevent security incidents in the future:
The acquiring bank wanted first to determine the extent of the breach, the extent of the data compromised and the method of compromise. It was the protection of customer information that was most critical. The server housed both the bank’s informational- only Web site and non-public data, including an inactive installation of the acquiree bank’s Internet banking application.
Although this incident provided a tense weekend at the bank, ultimately no customer data has ever been misused as a result and no customers are even aware that the incident happened. However, as of April 1, 2005, FDIC’s FIL-27-2005 requires that financial institutions notify the primary regulator and customers of any incident that has led to or may lead to unauthorized access of sensitive customer information, even if no misuse is readily apparent. (See www. fdic.gov/news/news/financial/2005/ fil2705.html.) If this incident occurred today, the institution would be obligated to disclose what happened to both regulators and customers.
Clear incident response policies and procedures greatly reduce the uncertainty surrounding a security breach and allow an organization to respond and recover more effectively and quickly.
At a minimum, banks should implement a policy to preserve evidence of the compromise and to keep systems accessible to investigation. Select both an internal incident response team and an external incident- response provider, since outsourcing incident-response projects on a per-case basis is the most viable option for most banks. Banks should ensure that incident-response providers will provide expertise and quick response time for the institution.
Banks should clearly define the goals and priorities of the incident response policy. Many banks will define the primary goal after a data security incident as rapid restoration of service. Even if the bank has no interest or ability in taking legal action following an incident, banks should realize that a certain amount of investigation should occur for every incident (prior to restoring service, if necessary).
At minimum, a bank must understand the scope of the security breach and potential data compromise and will want to be able to prevent any future, related breaches from occurring. Installing a freshly patched machine to replace a compromised system may be expedient, but may not protect the system from further compromises if the method of compromise has not been determined. In addition, FDIC-27-2005 requires that banks file a timely suspicious activity report in situations that involve federal crimes, particularly when the incident is ongoing.
Even in a case where the FBI’s threshold for monetary loss due to fraud is not met, banks should still be aware that all security breaches lead to monetary loss on the part of the bank. The bank will be responsible for any outsourced incident-response team fees and expenses, as well as the less quantifiable but still significant expense of lost personnel time. Some corporate insurance policies will cover a portion of these expenses.
Because of the myriad concerns in M&A activity, security policies can often be overlooked. Both institutions must have viable security policies and procedures, and the policies must be compatible enough that the organizations can work together in case an incident does occur before the systems have merged as a viable offensive strategy. Conversely, creating a clearly defined incident-response policy is the best defense.
* Although both banks are actual institutions and clients of Brintech, all institution names used in this piece have been changed to protect the anonymity of the banks.