- Purpose
1.1 Quant Foundry recognise that we need both incident response plans and DR plans to cope with today’s cybersecurity threats. Given the state of cybersecurity, we have developed both an incident response plan and a disaster recovery plan.
1.2 Our incident response responds to and limit the effects of cybersecurity incidents. The types of events where an incident response plan comes into play include data breaches, denial-of-service attacks, firewall breaches, viruses, malware and insider threats.
1.3 Such incidents are often the first step in detecting a disaster. When an out-of-normal condition occurs, it must be acknowledged as fast as possible, assessed as to its nature and severity, and responded to in an appropriate way that limits the effects on the organisation and ends any threat.
1.4 When considering whether a situation is an incident or a disaster, a good rule is to assess the severity of the event and the likelihood of it leading to business interruption, disruption, loss or crisis.
1.5 Introduction of a virus into a network would initially be treated as an incident, as the assumption is that it can be addressed quickly with various software tools and security techniques. However, if the virus proves to be a significant denial-of-service attack, the incident can soon become a disaster
1.6 We aim to make our incident response plan (IRP) to comply with various regulatory and certification bodies, such as the PCI DSS.
1.7 The range of significant incidents (or exceptional events) that a business encounters reflects the scale and diversity of its activities. These may include activities relating to:
• Duress, extortion and robbery
• Fires, floods and events of nature like snow storms
• IT and payments systems incidents
1.8 This policy is necessary to ensure that communication with customers and other stakeholders is timely and consistent, to maintain the reputation of our business.
1.9 Priorities for managing such events are as follows: –
• safety and wellbeing of all persons involved
• Continuity of service to customers
• The ongoing confidence of clients and other stakeholders
2 Incident Response Plan
2.1 At the Quant Foundry, the Data Protection Officer, is responsible for developing our IRP. Actions and procedures needed to:
• recognise and respond to an incident
• assess the situation quickly and effectively
• notify the appropriate individuals and organisations
• organise the response
• escalate to the managing directors
• support the business recovery efforts
2.2 An IRP ensures the Quant Foundry to spot early signs that an incident or attack is about to happen or is happening. It also helps us follow proper protocol to contain a threat and recover from it when detected.
2.3 Quick response, coupled with well-rehearsed actions, can often save an organisation from invoking more complex and costly disaster recovery (DR) and business continuity (BC) plans. In addition to helping the company return to normal, an IRP can minimise adverse publicity.
2.4 The Data Protection Officer is required to review the following considerations for incident response planning.
• keep the plan well organised, step-by-step, with relevant information
• communicate regularly to the managing directors on the incident status
• provide the material facts as they are available, disseminate them quickly
• review and test
• take a flexible approach, threats evolve over time
2.5 The Data Protection Officer is responsible for keeping the plan current, prove it regularly and put it into action. The plan should also specify the tools, technologies and physical resources that must be in place to recover damaged systems and compromised, damaged or lost data.
2.6 The Data Protection Officer is responsible for preparing users and IT staff to handle potential incidents should they arise.
2.7 The Data Protection Officer is responsible for having the tools to identify whether an event is a security incident.
2.8 The Data Protection Officer is responsible for containing the episode and isolate the affected systems to prevent further damage.
2.9 The Data Protection Officer is responsible for finding the incident’s cause and remove affected systems from the production environment.
2.10 The Data Protection Officer is responsible for allowing affected systems back into the production environment and ensure no threat remains.
2.11 The Data Protection Officer is responsible for making sure lessons are learned; analyse how it happened so staff can improve future response efforts.
3 Test an incident response plan
3.1 Quant Foundry believe that we should not wait to find out if our IRP works during an actual incident. We plan to reassess our incident response plans annually or whenever we make changes to the company’s IT infrastructure or its business, regulatory or compliance structure.
3.2 Businesses that regularly face attacks may feel they have less need to test their incident response plans. However, defending against one or two types of attacks regularly doesn’t ensure an organisation is ready for that third or fourth type of attack.
3.3 Going forward we will ensure staff stays up to date and in practice on response processes and protocol. Testing should include a variety of threat scenarios, from ransomware and distributed denial-of-service attacks to inside data theft and system sabotage.
3.4 One frequently used approach to testing is discussion-based, tabletop exercises where a group talks through the procedures they would apply and issues that might come up with a specific cybersecurity event. A more in-depth approach involves hands-on operational exercises that put functional processes and procedures in the IRP through their paces. A combination of these two approaches is best.