Floods. Hurricanes. Tornadoes. Fire. Power outages. The zombie apocalypse (well, maybe not that one). You don't have to be in banking to know these threats exist in our world. Although they may not have an exhaustive, board approved Business Continuity Plan ready to go in an emergency, the average person has some awareness that disasters occur and an instinct on what to do:
"The hurricane is projected to make landfall – shutter the windows and head to aunt Martha's."
"There's been a fire – call 911, get out of the building, stop, drop, and roll."
Elementary, right? What about this one:
"The CEO just clicked on a link and now all of our files seem to be locked down – wait…what?!"
Is your bank prepared to respond to a situation like this? Do you have a plan?
Security Incidents
Before we get too far, let's look at how NIST defines a security incident:
"A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices." (1)
Examples of security incidents include:
- An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash
- Users are tricked into opening a "quarterly report" sent via email that is actually malware; running the tool has infected their computers and established connections with an external host.
- An attacker obtains sensitive data and threatens that the details will be released publicly if the organization does not pay a designated sum of money.
- A user provides or exposes sensitive information to others through peer-to-peer or file sharing services.
Criminal Minds
Before putting together an incident response plan, you'll want to consider different avenues (called attack vectors) someone could use to carry out an attack. Here are some common, though not exhaustive, vectors:
- External/Removable Media: An attack executed from removable media or a peripheral device—for example, malicious code spreading onto a system from an infected USB flash drive.
- Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services such as a DDoS attack.
- Web: An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware.
- Email: An attack executed via an email message or attachment, commonly referred to as phishing.
- Impersonation: An attack involving replacement of something benign with something malicious like a man in the middle attack or rogue wireless access point.
- Improper Usage: Any incident resulting from violation of an organization's acceptable usage policies by an authorized user such as a user who installs file sharing software, leading to data loss.
- Loss or Theft of Equipment: The loss or theft of a computing device or media.
- Other: An attack that does not fit into any of the other categories.
The Plan
Now that you are aware of the threats out there and possible vectors an attacker might take, it's time to document and formalize your incident response plan. Every bank will go about this process in different ways, but at minimum, should include the following:
- Identify what, if any, customer information or customer information systems have been accessed or misused;
- Notify primary Federal regulator if there is unauthorized access to or use of sensitive customer information.
- Notify law enforcement authorities and file a SAR when appropriate;
- Take appropriate steps to contain and control the incident;
- Notify customers when warranted.
Assemble The Team!
No matter the size of the bank or organization, you'll want to gather an adequate and qualified team, usually dubbed a "computer incident response team" (CIRT), that can be activated in an incident response situation. The team's primary objective will be to serve as leaders and coordinate instruction, the involvement of proper persons to handle the issue, and generally carry out the incident response plan.
Test Your Plan
Last, and arguably most important, perform incident response testing. How do you know your plan is effective if it's never been tested? This is the practical, hands on portion that can be done several different ways from table top scenario exercises all the way to full blown simulations. The FDIC's Cyber Challenge vignettes (https://www.fdic.gov/regulations/resources/director/technical/cyber/cyber.html) are a helpful resource and starting place for testing ideas. The bank should schedule and perform at least one incident response test annually and report the results to the board.
Respond to Incidents and Carry On
Now that you are aware, have a team, and a tested plan, you will be much more prepared to handle any incidents that come your way.
Nothing to see here, carry on!