Be Prepared to Respond to Cybersecurity Incidents – Here’s How

Sooner rather than later, you will be in the middle of a significant cybersecurity incident. As part of the security team, you must be prepared to lead the company’s response through this crisis. Thus, to build a program and team that can respond to incidents quickly, you must answer this question: Do we have well-trained people and tested processes to respond to a security incident?

Your team will handle security events daily. However, when something concerning rises to a level that is suspected or confirmed to be an actual incident, it is critical that every member of the response team understand their roles and responsibilities, lines of command, and when, how, with whom, to communicate and not to communicate with, and many other aspects that make up a Cybersecurity Incident Response Plan (CIRP).

It is essential to understand that every incident is different. Still, the best you can do for your organization and the response team is to have possible pre-established outcomes that can be adjusted depending on the situation that you are dealing with. Therefore, every organization should have two essential documents to guide how the firm would respond when an incident is found: the Incident Response Policy and the Incident Response Plan (or procedure). We also recommend building a third type of document, sometimes called a playbook, which is more focused on the kind of incident vector, such as a Ransomware Response or Phishing Response Playbook.

Incident Response Policy

Information Security Policies are an aggregate of directives, regulations, rules, and practices that prescribe how an organization manages, protects and distributes information; in other words, they are management expectations on governing information security. Thus, your Incident Response Policy outlines how the firm would manage an Information or Cybersecurity Incident’s lifecycle.

We recommend that an Incident Response Policy includes at least the following items (which may vary depending on the maturity and size of the organization):

1. At the top of the policy, we recommend that you specify how someone would report an incident (email, phone, management, etc.)
2. The policy should specify that an Incident Response Plan is developed, approved by executive management, and revised at least annually.
3. Roles and Responsibilities. In this section, you would specify the members of the response team and their high-level responsibilities. Depending on the organization’s size, maturity, and complexity, it is crucial to understand that there may be multiple sub-teams, such as executive management, IT/Security, and business operations. Examples include but are not limited to:
   1. Executive Management. One or more members of the Executive Leadership Team who oversees that incident at the highest level (i.e., CIO, Executive Committee, COO)
   1. General Counsel. Leads the firm through the legal aspects of an incident, which are many and critical.
   1. The Incident Response Lead. The head of security or IT (CIO, CISO) would generally fulfill this role. This person is the liaison between the executive team and the operational incident response team.
   1. Incident Response Coordinator. This new and emerging role functions as a project manager who coordinates all logistics and communications. They would document everything being done, schedule meetings, lead updates, etc.
   1. Incident Response Team. This is the team “on the ground,” handling all investigations, containment, and remediation activities. The team is usually comprised of security and IT experts and may require subject matter experts from other areas of operations.
   1. Communications Team. Someone must be appointed to coordinate all internal and external communications. Depending on the type of organization, this role could be fulfilled by the communications/PR department, the General Counsel, or another executive.
   1. Staff (everyone). It is essential to communicate that everyone plays a role in Incident Response and that everyone’s responsibility is what we call “see something, say something.” In other words, be alert and report any anomaly to the proper team.
   1. External Stakeholders. This list can be either in the policy, procedure, or both but is more often found in the procedure/plan. What’s important is that these stakeholders are identified, and communications guidelines must also be provided. The list could be long, but at the very least should identify your cyber insurance carrier, any incident response and/or public relations retainers, outside counsel, law enforcement, and critical vendors (like technology support vendors).
4. The policy must specify that your Incident Response Plan should be tested annually.
5. The policy should provide high-level guidelines and expectations on communications.
6. Incident Severity. We recommend providing high-level guidance on the severity of the incident and how the firm would respond depending on severity.

Incident Response Plan

The plan or procedure is a more detailed plan of action that the members of the Incident Response Team would take at different stages of the incident’s lifecycle. Here are some steps to include in your Incident Response Plan (IRP) to lead to faster decisions and tactical moves when handling an incident.

1. Establish a line of communication with executive leadership and set expectations on when and how to communicate.
   1. When actual incidents are developing, it is essential to let management know that you’re dealing with an incident and be honest and tell them what you know at the time of first contact.
   2. Follow up soon after that with additional information and continue to do so through the life cycle of the incident.
2. Identify your critical processes and whether you can continue to operate without technology systems for an extended period and for how long.
3. Make sure that your backups are operational and available. You may or may not need them, so protect them!
4. Tie your incident response plan to your disaster recovery plan. It would be best to do this early in the incident-handling process.
5. Contain the incident as quickly as possible. This is the most critical step early in the incident management process.
6. Perform a risk analysis of the incident to understand the impact that it may have on the organization and guide your decision-making process.
7. Understand when and who would involve your third-party supporting teams, such as your Cyber Insurance Carrier and Incident Response Retainer. Document this in your plan.
8. You may need to notify external stakeholders such as regulators, law enforcement, and customers. Understand when, who, how, and what to communicate.
9. You may want to know ahead of time how to handle losses. For example:
   1. Would we pay a ransom or not?
   2. Can we lose N number of days of critical data and continue to operate?
10. Ensure that playbooks for specific types of attacks are in place, for example, phishing attacks, ransomware, business email compromise, or data loss.
11. Consider having pre-approved communications templates used during and after an incident.
12. And please, do test your plans. Test your incident response plan, backup restore processes, and disaster recovery plan so you know who needs to do what when a crisis hits. This is important for the following reasons:
    1. Identify strengths and gaps from lessons learned.
    2. Plan for remediating gaps
    3. Adjust policies, processes, and procedures.
    4. Include what you learned in the company’s security awareness training if appropriate.
13. Perform an Incident Retrospective after the incident has been handled and is ready to be closed. This is important to learn what can be improved after going through this crisis and take the same actions described in item 12.

Something to keep in mind is that Incident Response Plans are usually lengthy documents. We advise creating shorter versions that you can use when “onboarding” new members and executives into the Incident Response Team. We will provide you with additional resources, including a one-pager Quick Reference Guide template that you can adjust as your “onboarding” material and a process flow of activities to perform during each phase of the plan.

It is crucial to have these conversations within your organization to build your response plan and test it before an incident happens. Once your processes are built, periodically test them, so your first responders build “muscle memory” and refine their workflow. At CA2 Security, we can help you build and/or improve your Incident Response Plan and test it, so your team is ready to respond and protect your organization.