Two weeks ago we provided tips on how to perform a table top test of an Incident Response Plan (Five Tips For Cyber Incident Table Top Testing). This week, we provide tips for institutions wanting to improve their current (or new) plan.
If prepared properly, an Incident Response Plan will minimize the damage caused by security incidents by providing a well thought out approach to different representative scenarios. This week, we will highlight five common struggles that we see institutions experience while creating their plans. Being prepared for these will help to make the planning process go more smoothly.
- Assessment: Is It an Incident? The plan should address how you recognize that you have an incident. This sounds simple, but security incidents often first manifest themselves as operational problems (“The network is slow”, “I cannot get to the server”), and security messages are often simply due to operational problems (“Why do users keep getting locked out?”). We recommend that while you are writing your plan you discuss and document what the signs of an attack might be for various scenarios, and where you will look to determine whether it is really an attack. This may include server event logs, SEIM systems, firewall logs, etc. It may also include a list of outside parties to contact for assistance in assessing a situation. Documenting these assessment tools and services ahead of time will help you to more quickly identify, declare, and move to contain an attack.
- Containment: Who Decides? When creating your plan, you should talk through what actions the response team is authorized to take to contain and remediate the incident, and also what the protocol is to get authorization to do more. Key decision makers may be unavailable during an incident, which can delay making hard but necessary decisions such as whether to shut down a home banking site, sever an Internet connection, or bring a core system down. Discuss the protocol for making these decisions in the event that key decision makers are not available.
- Restoration: Where is Good Data? One key to quickly restoring services after an incident is to understand where and how often key data is backed up and how to access it. By discussing this while creating your plan, you may find that you have opportunities you were not aware of. You may find that the replication solution you use for DR can be adjusted to aid in data preservation by changing how often it applies changes to the DR site. You may be able to change your backup solution to back up key files more often to minimize the amount of data loss. Once you know where the data you will need is located, discuss pre-building scripts or processes to help recover quicker.
- Preservation: How Much? Make sure that your plan requires you document all actions and communications throughout the course of the incident. If there is a chance that data was breached or altered, it is also important that you take all reasonable measures to preserve snapshots of the data that may have been in the scope of the attack, as well as full copies of all available server and network logs. Since these preservation efforts may impact the time it takes to make key systems available again, make sure you discuss as part of the planning process your tolerance for downtime versus the requirement to preserve data, and that this be documented.
- Reporting: Who Needs to be Notified? There is often confusion regarding whether various scenarios require reporting to different regulatory agencies. Some states have made this more complex by adding additional reporting requirements to local agencies. It is a good idea to talk through these reporting requirements as part of the planning and testing process and to discuss any questions that arise with the agencies.
Looking for more hands-on help with your Incident Response Plan or one-on-one feedback? Reach out any time to support@bedelsecurity.com to set up a call with one of our cybersecurity experts!