Security Incident Response Plan (SIRP)

1. Summary

This Security Incident Response Plan (“SIRP”) between CustomerHub Pty Ltd. (“CustomerHub”, "us" or "we") and users of the CustomerHub Services ("you") governs the provision of the Software Service by CustomerHub to you pursuant to the Terms of Service (the "Terms"). All capitalized terms not defined herein shall have the meanings given to them in the Agreement.

2. Planning

This Security Incident Response Plan is documented to provide a well-defined, organized approach for handling any potential threat to computers and data, as well as taking appropriate action when the source of the intrusion or incident at a third party is traced back to the private network. This Security Incident Response Plan identifies and describes the roles and responsibilities of the Security Incident Response Team.

2.1 Security Incident Response Team (SIRT)

The Security Incident Response Team is comprised of key technical and support team members at CustomerHub who have had training in providing a quick, effective and orderly response to threats such as hacker attempts and break-ins, system service interruptions, breach of personal information, and other events with serious information security implications.

For immediate help with a security incident email support@customerhubapp.com.

The Security Incident Response Team’s mission is to prevent a serious loss of profits, client confidence or information assets by providing an immediate, effective and skillful response to any unexpected event involving computer information systems, networks or databases. The Security Incident Response Team is authorized to take appropriate steps deemed necessary to contain, mitigate or resolve a computer security incident.

2.2 Types of Incidents

There are many types of computer incidents that may require Secure Incident Response Team activation. Some examples include:
  • Breach of personal information
  • Denial of service/Distributed denial of service
  • Firewall breach/Virus outbreak

2.3 Definition of a Security Breach

A security breach is defined as unauthorized acquisition of data that compromises the security, confidentiality or integrity of personal information maintained by Customer. Good faith acquisition of personal information by an employee or agent of the Vendor for business purposes is not a breach, provided that the personal information is not used or subject to further unauthorized disclosure.

3. Identification

All reports of a potential incident shall be classified as a Severity 1/Severity 2/Severity 3 risk to facilitate the actions to take.

3.1 – Severity 1

Definition: Functionality of the Software Service is impaired or some users are unable to access or use some functionality. Example: Unauthorized system access.

CustomerHub will respond to and our senior engineers and will commence efforts to fix these problems no later than two (2) hours after you report of such problem or we detection of such problem, whichever is earlier. CustomerHub will use reasonable and continuous efforts to fix these problems during normal business hours, and if an acceptable work-around is provided, will provide a permanent fix no later than thirty (30) days after you report of such problem.

3.2 – Severity 2

Definition: Incidents that have the potential to have a monumental impact on the use or functionality of the Software Service. Example: Password cracking attempt.

CustomerHub will respond to these problems within four (4) hours after you report of such problem or we detection of such problem, whichever is earlier, during you regular business hours (or on the next business day, if the problem is reported outside of you regular business hours).

3.3 – Severity 3

Definition: Low impact to users of the Software Service. Example: Firewall scanning.

CustomerHub will respond to these problems within six (6) hours after you report of such problem or our detection of such problem, whichever is earlier, during regular business hours (or on the next business day, if the problem is reported outside of regular business hours).

4. Containment

Once a potential incident has been reported, The Security Incident Response Team will be responsible for performing the initial investigation to determine if an incident has occurred. The following checklist identifies the steps to facilitate in classifying the incident, if one in fact has occurred:
  • Collection and review of log files
  • Review of installed or running privileged programs
  • Inspection for system file tampering
  • Sniffer or Network Monitoring Programs reports
  • Detection of unauthorized services installed on systems
  • Review system and network configurations
  • Detection for unusual files
  • Examination other hosts

4.1 Shut Down Note

In responding to a reported incident, it may be good prudence to shut down any or all systems for the stopping of an attack in real time and/or the preservation of any potential forensic evidence.

5. Recovery

The main purpose of this Security Incident Response Plan is to ensure an efficient recovery through the eradication of security vulnerabilities and the restoration of repaired systems. Recovery includes CustomerHub ensuring the attacker’s point of penetration and any associated vulnerabilities have been eliminated and all system operations have been restored.

6. Remediation

CustomerHub’s first priority after recovery, especially with a Severity 1 incident, is remediation to achieve full threat eradication. The Security Incident Response Team will focus on immediately eliminating any attacker presence, blocking access, and closing all attack vectors.

6.1 Updates & Repairs

CustomerHub will update security controls, perform repairs, replacements, or augmentation to ensure the environment is secure while final remediation plans are developed.

6.2 Sustained Security

Using detailed incident reports and gap analyses that are developed during the initial response, CustomerHub will develop updated security plans. Prior to the next phase of Lessons Learned, the quickest new processes and tools will be implemented to improve the security of vendor perimeter, internal network, internal hosts, applications, and data.

7. Lessons Learned

The The Security Incident Response Team will complete an informal post-incident review after every security incident. This review will be performed no later than two (2) weeks from the end of the incident, to identify its full scope, how it was contained and eradicated, what was done to recover the attacked systems, areas where the response team was effective, and areas that require improvement. Lessons learned can inform any aspect of our security, including:
  • System configuration
  • Security monitoring and reporting
  • Investigation procedures
  • Containment/recovery strategies
  • Governance and communication around incident management
  • Reporting

7.1 Prevention

The Security Incident Response Team will use investigative techniques, including reviewing of system logs, looking for gaps in logs, reviewing intrusion detection or firewall logs and interviewing internal and external stakeholders to determine how the incident was caused. The Security Incident Response Team will recommend changes to prevent the occurrence from happening again or spreading to other systems.

7.2 Periodic Testing

It is the responsibility of CustomerHub to test and review the Security Incident Response Plan annually. When testing is done, each system should be scanned for the open vulnerability before remediation and then scanned again after the remediation to verify that the vulnerability has been eliminated. Annual testing of the Incident Response Plan will be done using walkthroughs and practical simulations of potential incident scenarios to identify process gaps and improvement areas.

8. Contact

Security Incident Response Team Contact:
Ezra M.
support@customerhubapp.com