Incident response plan
Ballpark has a documented incident response plan that establishes the procedures to be undertaken in response to information security incidents.
The response shall consist of the following phases:
1. Detect: This refers to any process that allows the Security Team to identify a potential security risk. These include:
Identification by automated vulnerability scanners or pen testing procedures
Code and infrastructure review
Internal physical or procedural policies
Bug bounty and security researcher engagement policies
2. Analysis: Based on information provided in the initial detection phase the Security Team shall analyse any such issue by gathering as much information as possible about the issue. It shall report and track the issue through internal ticketing and documentation mechanisms. Following on from this analysis the severity of the issue shall be concluded and based upon the severity a containment and eradication procedure shall be undergone within an appropriate time frame flagged by a prioritisation system (covered further in the Security Policy).
3. Containment: In the containment phase of the response, dependent on the type of security risk, the team shall identify a way to block or negate the security risk and isolate it from potential access, breach or interruption of the service. Containment may require automated, infrastructure, operational or coded solutions. In addition physical location or access procedures may need to be conducted to isolate the issue. Examples of these strategies are:
Shutting down a system or isolating a network or function from the rest of the service
Alteration of access to the affected system, location, function
4. Eradication: Once the issue is contained a solution shall be enacted to remove the source of the issue. Example methods of eradication can involve:
Deployment of security patches or an update to a system library or antivirus/malware system
Alteration to software where a security issue may be identified. Typically a code or infrastructure update
Alteration of an internal access policy related to role staff or a system accessible to members of staff
5. Recovery: In the recovery phase of the operation any isolated system can be reinstated to the service assuming it has been sufficiently cleared of the issue as determined by the Security Team.
Documenting and Reporting
Within each phase of a security incident being assessed it shall be documented and reported in the following manner.
High: In the event of a high risk security incident all stakeholders within the business shall be notified immediately via a summary once the Analysis phase is completed. This summary shall be documented within the incident response system and messaged to Senior members of staff, heads of departments and members of staff responsible for communicating the issue to customers and/or dealing with solving the incident. Customers will be notified of the incident if it immediately impacts their business in real-time. If not once all phases of the lifecycle have completed and an evaluation and incident report produced it will be reported with full transparency to our customers with details of affected systems, data or issues relating to their accounts.
Medium: In the event of a medium impact security event, customers are unlikely to be notified as it shall be deemed unlikely that sensitive data or information related to their account has been compromised. In this incident Heads of departments and their associated staff for Security, Support and Customer Experience will be called upon to coordinate their members of staff appropriately. In each case the internal teams will be responsible for messaging and communicating information relevant to diagnosis or status updates. This messaging shall be conducted within the systems Marvel uses internally as well as documented within the incident response tools and if required communicated to a customer via email. This approach also applies in the event of a High security incident response.
Low: In the event of a low impact event the Security Team will identify and treat the problem within a time frame of one to two weeks. In this process they will still conduct the analysis and containment phase of the lifecycle as immediately as possible, documenting and reporting said incident to the support and operations team. Following on from treatment of the procedure the incident will be documented fully upon completion.
Incident Service Level Agreement (SLA)
High: Mitigation and patch to be deployed within 4 hours of detection and analysis of the incident
Mitigation and patch to be deployed within 5 days of detection and analysis of the incident
Low: Mitigation and patch to be deployed within 1 month of detection and analysis of the incident
Security Policy Revision History
Author: Kelsey Traher, COO
Date of change: May 2022
Summary of changes: Reviewed for accuracy; minor changes
Author: David Quinlan
Date of change: May 2020
Summary of changes: Minor cosmetic updates, no content changes
Author: David Quinlan
Date of change: Apr 2020
Summary of changes: Entire policy reformatted and clarified
Author: SANS Policy Team
Date of change: Nov 2019
Summary of changes: Added and updated SLA times for incidents
Author: SANS Policy Team
Date of change: Apr 2019
Summary of changes: Updated incident response policy to reflect recent evaluation of process
Author: SANS Policy Team
Date of change: Sep 2015
Summary of changes: Defined and created Security Policy document