What is an Incident Response Plan?
An Incident Response Plan is a document that helps guide an organization through an information security event and is meant to ensure the security of the organization and that it can survive the event and come out of it with minimal impact to the data and operations of the business.
How Long is an Incident Response Plan?
Incident Response Plans can vary greatly in length depending upon all of the different scenarios that the document may be called on to address. Some that deal only with a cyber-security breach incident may not be that long, but those that are meant to address multiple scenarios (cyber-attack, virus or malware outbreak, ransomware attack, etc.) can be quite long and are typically broken down into segments that deal with each of the different scenarios. In the latter case, the document may well be 100 pages or more in length.
What Divisions Usually Develop Incident Response Plans?
Typically, it is the IT, MIS or INFOSEC functions within a company that develop the critical Incident Response Plan. However, with that being said, for an Incident Response Plan to be comprehensive, it needs feedback from multiple divisions in the company to ensure that it is holistic in nature and addresses all of the scenarios that may impact a firm. As an example, in a financial institution, you would want to ask the branch operations division to ensure you take into account the offline procedures that would be used in the event that a key system is involved in the cyber-event and they cannot use it to process transactions or data for customers.
Who is in Charge of the Security Incident Response Plan?
It is going to be the Chief Information Officer or the Chief Information Security officer that is in charge of the document. However, in small organizations, it may even be the CEO that is in charge of the document. One thing to keep in mind is that it needs to be an individual and not a management team that is responsible for the document as this is typically a recipe for disaster as there are often too many competing ideas about how the document and resources are constructed, what should go in it, and who should be responsible for keeping the document up-to-date as things within the business change and new systems are brought in and old ones are decommissioned.
Who Should the Document be Shared With?
Certain aspects of the document should be shared with the entire organization (what to do in the event of a virus outbreak on your computer, etc.). While other components such as how press inquiries should be handled should remain reserved for only those individuals within the company with the responsibility of dealing with the press (usually the VP of Marketing, Communications Director, or the CEO).
What Organizations Must Have a Security Incident Response Plan?
From a security practice standpoint, all organizations should have an Incident Response Plan, however, there are some organizations such as financial institutions or healthcare organizations that are mandated to have one by regulation or decree.
How Often Should the Cyber Security Incident Response Plan be Updated?
Normally, an Incident Response Plan should be updated at least annually. However, most networks and infrastructure are dynamic in nature, so in truth, the individuals should take the time and resources to update the document on an ongoing basis.
What Should be Within the Plan?
Even though a Security Incident Response Plan may cover a multitude of scenarios, there are some basic steps that the plan should include to ensure that it will address at least the basics. Basic items include things like documenting who is in charge of the plan, what constitutes a cybersecurity incident, who is responsible for reporting status changes to company management, what to do in the event of certain types of cybersecurity incidents (virus outbreak, ransomware attack, etc.), and when the security incident response document was last tested.
Always remember that there should be a checklist associated with any recovery scenario outlined within the Plan to ensure that no steps are overlooked. An event can often be chaotic, but when a checklist is present there is a good chance that the company can make it through the event and not miss any critical steps.
How Often Should the Plan be Tested?
Speaking of testing the plan, it should be tested on at least an annual basis to ensure that the content of the Plan is still relevant and addresses items that would have a detrimental impact to the company.
Tests can be done in one of two fashions:
- “Table Top” Exercises
- This is a paper exercise where a hypothetical situation is given to the test team and they use the Plan components and see how well it addresses the given scenario.
- “Live-Fire” Exercises
- This is where a specific system or systems is taken down to see how the organization would respond based upon what is outlined in the Plan. While tabletop exercises are valuable, live-fire exercises give the company a real sense of how well the organization would respond in the event of a real cyber-attack.
What is most important about testing is that the tests are documented and that the documentation is stored for comparison to the next test to see if the organization, and the Plan, are improving or getting worse over time at dealing with the scenario being presented.
Who Should be on the Test Team?
Testing should NEVER be an IT or INFOSEC event where no other divisions are involved. Remember, if an event does occur, it is likely that it will impact all or many divisions that are not in the IT or INFOSEC realm. It may impact Accounting, Operations, or any other division within the company. Remember, an Incident Response Plan needs to take into account more than just IT or INFOSEC activities. If that is all that is covered there is a good chance that the event will become worse rather than better, even if there is a plan in place.
Key takeaways
In closing, while they may be painful to develop, an Incident Response Plan is something that needs to be developed, deployed, and maintained, regardless of the size of the organization in question. Failure to develop and implement a plan places the organization in a precarious spot should a cyber-event occur.