The picture above shows an American $100 note. On the note is a picture of Benjamin Franklin. Here in the UK, Franklin is not well known and he certainly has no connection with creating an incident response plan. Nonetheless he was a remarkable man.
One of the founding fathers of the USA, Franklin was a leading author of his time, a political theorist, politician, scientist, inventor and a diplomat. So important was his contribution to the founding of the USA and its public life thereafter, he continues to be honoured to this day over 200 years after his death. Not only is he the face of the $100 bill, his name is used by multiple US towns, warships, educational bodies and businesses.
But what has he got to do with incident response planning? Well, Franklin is famed for many quotes, including “if you fail to plan, you are planning to fail”
Despite being more than two centuries old, Franklin’s quote is an entirely fitting start point for this Blog. When (not if) you suffer a security incident, your objectives are to:
- Contain and mitigate the damage
- Prevent further damage
- Return as quickly as possible to normal business operations
An organisation that follows an effective, communicated and rehearsed incident response plan will recover more quickly and suffer less impact than an organisation without a plan. An good incident response defines roles, responsibilities, lists key specialist suppliers, empowers key decision makers and helps ensure employees recognise and report breaches and know what to do if a breach occurs.
If you fail to plan, you are planning to fail…
Without a well communicated and rehearsed plan, individuals with the best intentions can make a situation worse by damaging evidence, damaging systems or even spreading malicious code and setting off attacker booby traps. This means recovery time can take longer, financial losses will grow, and your compliance obligations and your reputation are put at increased risk.
Do you need an incident response plan?
In a word, yes. It’s not a question of if you’ll suffer a cyber attack or a security incident, it’s a question of when. As we all know, we’re living and working in a digital world meaning the number of breaches will continue to increase. Information assets are now among your most valuable assets (if not your most valuable) and the consequences of suffering a breach are more significant than ever.
As such, your incident response planning shouldn’t be an after thought – it must be one of your first thoughts. You wouldn’t drive you car without insurance, roadworthy tyres and wearing a seat belt. Likewise, responsible business leaders need to accept that security incidents will happen and they should have a well thought out and rehearsed plan in place.
Start with your incident response policy
Your starting point is your security incident management policy. Policies are sometimes overlooked but don’t miss this one. A good policy sets our management intention – what the company needs to do and why it’s important. This is especially true of your incident security management policy. It needs to set the ‘tone from the top’.
The policy should make it clear that its a business priority that every employee needs to know how to recognise a security incident and who to report it to. It should then set out the investigation process and timelines. You’re not in full incident response mode yet, but you need a rapid investigation. Set out who does that, when and who they report their feedback to.
You need to identify if a breach has actually occurred, how severe it is, what systems and information assets are affected, whether personal data has been compromised (with GDPR in mind) and whether the incident is still ongoing. You need this information to make your ‘invocation decision’. This is the point when you determine whether to invoke the full incident response plan or whether you can and should manage the incident through your standard IT incident management process. The policy should make clear who has the authority to make the invocation decision and when.
Your incident management policy should also address any steps you need to take to notify the ICO or data subjects if the incident affects personal data and there are risks to data subjects. We’d suggest cross referring to your personal data breach notification procedure within the policy.
A well drafted security incident management policy also serves another purpose – it gives your customers confidence. Organisations are increasingly carrying our due diligence on their supply chain and incident management policies and response procedures are commonly asked for.
Create your incident response plan
Your policy should include a detailed incident response plan (or procedure, if you prefer) which applies as soon as you make the decision to invoke it (the ‘invocation decision’). The plan should be a real, living document and not a generic ‘tick box’ template. Once invoked – the incident should be managed according to the plan and everyone should know their role and responsibilities.
The purpose of your plan is to preempt the most likely issues before they occur and to have your responses ready to go. The last thing you want is to try and pull things together after the event, when your communications may be down and people are therefore hard to contact. A well structured and detailed plan ensures speed of action and a uniform response with expected outcomes rather than a ‘hit and hope’ approach.
The plan should list names of the people in your incident response team and define their roles, responsibilities and authorities. Include a documented escalation plan to the highest levels of authority and define who is responsible for internal and external communications and who authorises them. Your reputation can be damaged quickly if the wrong person communicates with the media. Likewise, you’ll want to give employees confidence that everything is under control.
This is a business document, not a technical document. Having technical response plan or ‘play books’ is a good thing, but keep them separate and cross refer to them. The plan needs to be easy to read for non-technical members of the incident response team. Include a directory of all key contacts, including specialist agencies (such as the NCSC), law enforcement agencies and the IT and incident response specialists you have contracts in place with. List names, telephone numbers, emails and account reference numbers.
Define the incident response team
Your plan needs to define the team, listing each member by name along with their alternates if they are unavailable. This ensures there is a group of properly skilled people who are trained to follow your specific plan and who are singled out and called upon when a severe security incident takes place.
Train the team on issues they need to be aware of. Specifically, train them on the legal implications associated with decisions they may make during an incident. If the incident is a result of a criminal act then it is vitally important that forensic evidence is protected, such as by removing systems from the network and ring fencing them rather than powering them down for example. Likewise, it will be important to protect the chain of custody by documenting access to and decisions made in respect of evidence.
The incident response team (‘IRT’) is not a technical team. You will have technical specialists on the team and your IT function will likely have its own technically focused incident team but the overall IRT should be cross functional. It should include and representatives from your Executive Team along with IT, HR, Infosec, Communications/PR and Facilities/Physical Security. You might not have all of these functions or may use external expertise. If so, think about whether you need to include your external lawyers, PR specialists or outsourced infosec specialists in your IRT.
The IRT must be senior enough to have have authority to make decisions on the spot and to call on internal and external resource as required. You want to waste as little time as possible waiting for authorisation to act. All the same, top management may wish to reserve certain decisions for themselves (such as taking down a key system or approving press releases). This is where your escalation path needs to be clearly defined and documented, as stated above.
Nominate a designated note taker. This can be anyone on the team and is a critical role. You need to keep a log of all information available, decisions made and the consequences of actions. This helps protect evidence, demonstrates accountability in the event of a regulatory action and is critically important to continual improvement. After the incident is addressed, you will want to review your incident response planning, identify lessons learned and introduce improvements.
Your IRT can be a dedicated group of specialists or a virtual team of individuals with an existing ‘day job’ who become IRT members when the incident plan is invoked. In truth, very few organisations can dedicate a team of cross functional specialists who wait on stand by for a security incident. As such, a virtual team or a hybrid approach with, perhaps, one dedicated incident response leader supported by a virtual IRT is more realistic.
Practice and test the incident response plan
With the policy, documented plan and team all in place you need to practice and test your incident response capabilities as you would with any critical process. This helps ensure that it works as expected and helps the IRT rehearse the various scenarios they may face. Remember, the purpose of your plan is to to preempt the most likely issues before they occur and to have your responses ready to go. Rehearsing the most common scenarios helps achieve this and will build confidence in the IRT. Practising the plan regularly will also help ensure new IRT members are brought up to speed and will identify areas for improvement.
You have a number of options for testing the incident response plan. We’d recommend a combination of all of these:
- Paper Testing: This involves an independent review of your documentation including your policy, plan and details about your IRT by an outside specialist. This isn’t an audit, but rather and opportunity for a warts and all assessment of the maturity of you planning and identifying areas for improvement. We provide paper testing for incident response plans within our Security Consultancy services.
- Table Top Exercises: A table top exercise tests your IRT by getting them all around the same table and walking through various scenarios. A facilitator shares information about a potential incident and asks IRT members to confirm how they would respond. During each exercise, the facilitator ‘injects’ additional information which escalate the scenario and challenges the IRT team members. We can provide cyber incident table top exercises and report on observations and areas for improvement afterwards.
- Interactive Simulations: Sometimes called ‘war games’, these build on table top exercises but rather than walking through and discussing the steps to be taken, the aim is to simulate a ‘situation’ room type environment with all IRT members ‘in character’ and responding to information and escalations as they become available. Gamification elements can be added in to include an element of competition. the aim is to apply some of the additional stress that would be felt in the real world.
That’s a lot of information and a lot of work. We also know that it can be difficult to secure management buy in at times. If this is the case, or if you’re unsure how to implement all the steps listed above, our advice is not to let great be the enemy of good. Start with the policy and communicate it. Raise awareness of how to identify a potential incident and who to report it to and then build from there.
Need help or want to chat?
If you need help preparing your incident response plan or simply want to chat with us about ways in which you could approach it, then we’d love to hear from you and we promise no hard sell. You can contact us here.ENQUIRE NOW