This document was updated on May 21, 2020.
Security Incident Response Plan (SIRP)
This Security Incident Response Plan (“SIRP”) between Macabacus, Inc. (Macabacus, “us” or “we”) and users of the Macabacus Services (“you”) governs the provision of the Software Service by Macabacus to you pursuant to the End User License Agreement. All capitalized terms not defined herein shall have the meanings given to them in the Agreement.
This Security Incident Response Plan is documented to provide a well-defined and 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 Macabacus 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 us 24 hours a day / 7 days a week.
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.
The Security Incident Response Team is responsible for investigating suspected intrusion attempts or other security incidents in a timely, cost-effective manner and reporting findings to the appropriate authorities as necessary. These investigations will be coordinated across support specialists and senior management.
2.2 Types of Incidents
There are many types of computer incidents that may require Secure Incident Response Team activation. Examples include, but are not limited to:
- 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 us. Good faith acquisition of personal information by an employee or agent of Macabacus for business purposes is not a breach, provided that the personal information is not used or subject to further unauthorized disclosure.
All reports of a potential incident shall be classified with a severity level of 1, 2, or 3 to identify the actions to take.
3.1 Severity 1
Definition: Functionality of the Software Service is impaired
Example: Unauthorized system access
Macabacus will respond to the issue and our senior engineers and will commence efforts to fix these problems no later than two (2) hours after you report such a problem or after we detect such a problem, whichever is earlier. Macabacus 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 such a problem.
3.2 Severity 2
Definition: Potential large impact on the use or functionality of the Software Service
Example: Password cracking attempt
Macabacus will respond to these problems within four (4) hours after you report such a problem or we detect such a problem, whichever is earlier, during regular business hours (or on the next business day, if the problem is reported outside of regular business hours).
3.3 Severity 3
Definition: Low impact on the use or functionality of the Software Service
Example: Firewall scanning
Macabacus will respond to these problems within six (6) hours after you report such a problem or after our detection of such a problem, whichever is earlier, during regular business hours (or on the next business day, if the problem is reported outside of regular business hours).
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 that facilitate classifying the incident, if one has in fact occurred:
- Collecting and reviewing of log files
- Reviewing installed and running privileged programs
- Detecting unauthorized services installed on systems
- Reviewing system and network configurations
- Detecting unusual files
4.1 Shut Down Note
In responding to a reported incident, we may be required to shut down any or all systems to help mitigate an attack and help with the preservation of any potential forensic evidence.
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 Macabacus ensuring the attacker’s point of penetration and any associated vulnerabilities have been eliminated and all system operations have been restored.
Macabacus’ 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 the threat, blocking access, and closing all attack vectors.
6.1 Updates & Repairs
Macabacus will augment security controls and perform repairs 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, we will develop updated security plans. Prior to the next phase of Lessons Learned, new processes and tools will be implemented as necessary to improve our overall security, including our internal network, internal hosts, applications, and data.
7. Lessons Learned
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, in order 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 and recovery strategies
- Governance and communication around incident management
The Security Incident Response Team will use investigative techniques, including reviewing of system 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.
7.2 Periodic Testing
It is our responsibility 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 Security Incident Response Plan will be done using walkthroughs and practical simulations of potential incident scenarios to identify process gaps and improvement areas.
Security Incident Response Team contact: Chief Technology Officer
Email: [email protected]