We all know that incident response is critical to a good cybersecurity program at community banks and credit unions. The term "Cyber Resiliency" comes to mind, and by that term, we mean having the ability to withstand and recover from cyber incidents.
The NIST Cybersecurity Framework dedicates 2 of its' 5 main pillars to the Respond and Recover aspects of cybersecurity, which is an indicator of just how important it is to be able to react in a time of crisis. And with the latest breach news occurring daily (I know, it's tough to keep up), it almost seems inevitable.
That being said, doesn't it seem like a good idea to have a plan in place to handle such situations? And know that it works?
While many of our clients have a plan in place (our suggested improvements will have to wait for another blog post), we do find that many don't have the proper testing of various scenarios to see how the team will react.
This type of testing, referred to as table top testing, provides the following benefits:
- Your team gets to walk through mock scenarios and talk through an action plan
- You get to discover the big gaps in your plan or even just minor details that could be ironed out
- You can discuss with vendors and service providers on what role they will play
- Examiners and auditors want to see that you are doing this and should be asking for it
So how do you do a table top test?
Some hire outside firms, others conduct the test internally. If you have an experienced CISO (or Virtual CISO), they should be able to lead this discussion and objectives. If you do choose to conduct the tests internally, we have a few tips to share that can help improve the process.
Keep in mind, it is helpful if you've been through a test like this before with an experienced cybersecurity professional.
5 tips for performing an incident table top test:
- Review the plan with everyone. Although this is a test, it's not that kind of test. This isn't a "gotcha" moment. Think of it as training and practice (at least until you've matured the process).
- Pick 3-4 scenarios that differ in threat type. Make sure you mix up the scenarios to keep everyone involved. Everyone will get bored if you do 3 scenarios of different malware strains.
- Mix up the likelihood and impact of the scenarios. This means that you should have an incident test that is unlikely, but of extreme impact, and an incident that is of low impact, but highly likely to occur. This will get the team thinking in different ways.
- Keep the scenarios realistic. Make sure that the incident could actually happen at your organization. Your team will be much more engaged if they can picture themselves in the situation.
- Get as much of your incident response team involved as possible. Insurance, Legal, Forensics, Frontline staff, Marketing, Executives, IT, Security, etc. This doesn't mean you have to have everyone in a room at the same time. Yes, you should have your main incident response team in the main testing meeting. But your third-party providers can be contacted afterward to get their take on certain scenarios. You could call your insurance provider and say, "Ok, let's pretend that fill-in-the-blank-incident occurs, what would we do, what are next steps, etc.?" This doesn't require everyone's schedule to be burdened but achieves similar results. (Just make sure you document those calls and include in the testing report as well)