With many organizations now having a dedicated security monitoring team, or outsourcing this to a Managed Security Services provider, do we still need Incident Response (IR) plans? The answer is yes. Ultimately, the buck still stops with the organization and not with the service provider. An effective IR plan is the number one way of ensuring an incident is handled quickly and effectively.
To use an old military term “Prior preparation prevents poor performance”. If a plan is made ahead of time, you can react quickly to mistakes made in the heat of the moment. The Ponemon Institute’s 2020 study showed the average cost of a data breach for companies with an IR team with tabletop testing exercises or simulations was $3.29 million, compared to $5.39 million for those without IR or IR test plans.
Understanding what to do when an incident occurs and who to talk to is critical to ensuring there is an effective response. So how best to go about setting up an IR plan?
Conduct a Gap Assessment - A Gap Assessment ensures all the appropriate questions have been asked and the information to identify systems, services, business owners etc. has been reviewed. Where there is an existing IR plan in place, this assessment is used to establish if the plan is fit for purpose, where there are gaps and to benchmark the results. This is something we manage for our clients through our Cybersecurity Advisory service.
Designing the IR plan - The design of the plan is based on the evidence gained from the Gap Assessment and Analysis. Fundamentally, the IR plan should be built in line with the business’ requirements, much like a Disaster Recovery Plan. As such, it should have similar executive ownership. The business requirements drive the mission statement and objectives for the IR plan.
Writing the IR plan - At this stage we need to determine what the IR plan should consist of and how to develop it. First, the plan should be written in line with business objectives, with an overarching methodology for IR. The two main ones currently available are:
Executing your IR plan
While these two frameworks are broken down slightly differently, they deal with incidents in the same procedural fashion. The vast majority of the IR plan will be defined within the preparations phase, however here are a few points to bear in mind throughout the whole process:
Team priorities
As a first step, it’s important to break down the team responsible for day-to-day incident handling processes. This includes the management and external stakeholders who the Security Operations Centre/IR team will work with during an incident. Roles and responsibilities should be outlined from the beginning of the investigation so all members involved are aware of the plan and what is expected of them.
From the outset, the team should be clear on the key terms associated with the IR plan, including understanding what constitutes a low, medium, high, or critical incident. Priorities should be broken down into specific areas: users, criticality, device type, attack type and systems affected. This way, scoring can be conducted against each area to provide a total score which helps determine the severity of the incident.
Effective escalation
Swim lanes define all the expected activities to be undertaken by each team during an incident. The workflow should be aligned to a general IR plan and bespoke elements can be added in the form of runbooks for specific threats.
Ultimately, the workflow details the escalation paths and the resulting breakout to external procedures. There is a myriad of reasons for escalation which need to be defined by set criteria, such as triage time exceeded or the requirement for additional skills or external assistance. By detailing these reasons clearly, staff working on the incident know who to call upon when necessary.
A communication plan supporting the escalation phase is key as it ensures individuals know how to proceed during the incident. If the organization’s network has been compromised, a separate communication channel should be invoked – not via email. Other elements of the plan should align with the Traffic Light Protocol so that only authorized staff are briefed on the incident – making sure sensitive information is not leaked.
The aftermath
How evidence is stored impacts potential legal cases resulting from the investigation, meaning everything should be processed as if it were to go to a court of law. Any SIEMs utilized should therefore be designed and implemented with this in mind. Additional information captured must follow the correct chain of evidence as defined for the organization.
Those involved should also be aware of documentation fundamental to the IR plan, including the organizational chart, critical assets, the data and services list and network diagrams. Ultimately, the IR plan should detail all actions conducted upon the resolution of any incident: analysis, lessons learned and reporting. Further details on this area can be found in my earlier blog The Calm after the Storm.
Finally, and crucially, test your plan. Why go to all this work if your team are not aware of how to respond in an emergency? We test fire evacuation plans and IR should not be any different. Ideally, these tests would be hosted by external organizations who, alongside creating test scenarios, review the plan to ensure all team members are responding appropriately. This external team can then identify any gaps and provide additional assistance and training where required.
While there are many free resources to help, creating an IR plan is a very specialist area. It’s worthwhile investing time to research the organizations that can support you in building and ensuring your plan is effective and aligned to business needs. If you don’t currently have an IR plan in place, don’t delay – your future self will appreciate it.