Incident response policy

1. Plan & overview

1.1 Definition

This document offers guidance for employees or incident responders who believe they have discovered or are responding to a security incident. In responding to any incident, we first determine the exposure of the information and determine the source of the security problem, if possible. We communicate back to the customer (and any other affected customers) via email or phone (if the email is not sufficient). We provide periodic updates as needed to ensure appropriate resolution of the incident. Our Chief Executive Officer reviews all security-related incidents, either suspected or proven, and we coordinate with affected customers using the most appropriate means, depending on the nature of the incident.

1.2 Objective

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.

1.3 Our approach to handling security incidents

Recruit CRM has a comprehensive set of security measures in place to ensure we protect customer information and offer the most reliable and secure services we can. However, we also recognize that security incidents can (and do) still happen, and so it's just as important to have effective methods for handling them should they arise.

'As a result, we have a clearly defined approach for responding to security incidents affecting our services or infrastructure. Our incident response approach includes comprehensive logging and monitoring of our products and infrastructure to ensure we quickly detect potential incidents, supported by carefully defined processes that ensure there is clarity in what we need to do at all stages of an incident.

1.4 Security Incident Response Team

The Security Incident Response Team is comprised of key technical and support team members at Workforce Cloud Tech, Inc. 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: contact@recruitcrm.io - 24hrs a day / 7 days a week

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.

Security Incident Response Team Members

Chief Executive Office
Head of Engineering
Head of Platform
Senior Developers/Testers

1.5 Security incident responsibilities

Just like any cloud service provider, we try our best to ensure our customers don't experience an outage or a security incident. However, we understand that a security incident is likely to happen. It's important to us that customers understand how they fit into our security incident response process and what responsibilities you have in the course of an incident.

Roles

Every incident we experience is managed by one of our highly-qualified and experienced Senior Engineers (or SE's). SE's typically make security-related decisions, oversee the response process and allocate tasks internally to facilitate our response process. The SE's are further supported by incident analysts who lead the investigation and analysis of incidents, as well as a range of other roles to assist with the response process. In many cases, if an incident has an impact across more than one locale, two SE's are assigned to an incident to ensure there is always someone accountable to keep our response process moving forward and containment or recovery activities don't get held-up or otherwise affected by time differences.

Responsibilities

Responsible - The party will do the work to achieve the task.
Accountable - The party ultimately answerable for the correct and thorough completion of the activity.
Consulted - The party whose opinions are sought and with whom there is two-way communication.
Informed - The party who is kept up-to-date on progress, and with whom there is just one-way communication.

2. Stages of incident response

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

Definition of a security breach

A security breach is defined as the 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.

1. Identification

In this stage, we perform checks and figure if the reported abnormality is an incident or not. If it is confirmed as an incident, we collect report logs, error logs and communicate it with the respective team for further investigation and measures are taken to fix the incident at the earliest.

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

1.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.

Workforce Cloud Tech, Inc. 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. Workforce Cloud Tech, Inc. will use reasonable and continuous efforts to fix these problems during normal business hours, and if an acceptable workaround is provided, will provide a permanent fix no later than thirty (30) days after you report of such problem.

1.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.

Workforce Cloud Tech, Inc. 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).

1.3 Severity 3

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

Workforce Cloud Tech 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).

1.4 Classification

SIRT team assigns severity and criticality to each incident. Based upon the event classification levels selected, the SIRT handles the most important incidents first. Event classification also helps to organize the types of incidents into subgroups, which allows metrics creation and long-term remediation opportunities to be identified. The matrix below outlines the priority score for each classification.

The matrix below outlines the priority score for each classification.

Severity Level	Score
Informational	0
Action Item	1
Adverse Event	2
Basic Incident	3
Moderate Incident	4
Major Incident	5

Criticality Level	Score
Unknown	1
Low	2
Medium	3
High	4
Critical	5

2. 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

2.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.

3. Declare

Once the SIRT Coordinator determines an incident, they declare an incident and invoke the SIRT Plan. The SIRT Coordinator then decides what roles will be a necessary part of the team, and assigns those roles

4. Eradication

The incident is always reported to the concerned team with enough documentation. After reviewing the documentation and code, the eradication process undergoes numerous testing which ensures the incident is no longer in the system and won't happen again in the system in the future.

5. Escalation

At any time during the incident response process If a member of the Security Incident Response Team (SIRT) is not reachable within 30 minutes of a contact attempt, the potential incident is escalated to the Senior SIRT Coordinator .If the Senior SIRT Coordinator is not reachable, then the SIRT team member escalates the potential incident to the next level of management or Chief Executive Officer until someone is reached. Also, the SIRT Coordinator determines whether outside parties need to be notified of the incident.

6. Recovery

Once security incident happens, it moves on the remediation and recovery phase of the incident lifecycle, which works towards ensuring that systems are cleansed of any malicious or other illicit content and ready to be used again within the organization. While the exact steps involved in remediation and recovery are dependent on the organization and the incident type, the following areas and actions are considered:

Patching and hardening system images
Reimaging systems
Implementing password changes
Improving monitoring and defences

7. Lessons

After every incident, we perform heavy documentation. The learning from these documentations is discussed in review meetings and certain standards are set to follow. The learning helps the organization to avoid repetitive incidents & secures the systems from past incidents.