IT Incident Response Plan

IT Incident Response Plan

This 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 Incident Response Plan identifies and describes the roles and responsibilities of the Incident Response Team. The Incident Response Team is responsible for putting the plan into action.

Incident Response Team Members:

Night shift System Admin: Sys admin # 1

phone

Day shift System Admin: Sys admin # 2

Phone

Night shit Developer: Developer # 1

Phone

Day shit Developer: Developer # 2

Phone

Applications Manager: Application Manager

Phone

General Manager: General Manager

Phone

CEO: Company CEO

Phone

Types of Incidents

There are many types of computer incidents that may require Incident Response Team activation. Examples include but not limited to:

Unusual traffic activity
Any type of breach
Denial of service/Distributed denial of service
Excessive port scans
Firewall breach
Virus outbreak

Definitions 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 VR Assets LLC.

Authorized acquisition of personal information by an employee for business purposes is not a breach, provided that the personal information is not a subject to further unauthorized disclosure.

Employee Responsibilities

All VR Assets LLC employees must report any suspected or confirmed breach of data to the IT Department immediately upon discovery. This includes notification of incidents that occurred at any third-party service providers’ or other business partners’ facilities with whom VR Assets LLC conducts business.

The employee reporting the suspected breach will assist in acquiring information and providing additional assistance as deemed necessary by the System Admin or other Incident Response Team members throughout the investigation.

Classification of a Potential Incident

All reports of a potential incident shall be classified as a high/medium/low risk to facilitate the actions to take.

Criticality: High

Definition: Incidents that have a monumental impact on the firm’s business or service to clients. Example: Unauthorized system access, ransomware, virus infestation, etc.

Criticality: Medium

Definition: Incidents that has a significant or has the potential to have a monumental impact on the firm’s business or service to its clients.

Example: Password cracking attempt, unusually high traffic, DDOS attacks, etc.

Criticality: Low

Definitions: Incidents that has the potential to have a significant or monumental impact on the firm’s business or service to its clients.

Example: Firewall scanning, phishing attempts, antivirus software notification.

Response

Once a potential incident has been reported, Incident Response Team Member/s should be notified. Incident Response Team Members will be responsible for performing the initial investigation to determine if an incident has occurred. The following checklist identifies steps that can be used 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
Network Monitoring Programs reports
Detection of unauthorized services installed on systems
Evidence of password file changes
Review system and network configurations
Detection for unusual files
Examination of hosts

Note: In responding to a reported incident, it may be good idea to shut down any or all systems to stop an attack in real time and to preserve any potential evidence. In responding to a reported high criticality incident, the affected system shall be isolated from internet connection for the duration of investigation.

Recovery

Recovery includes ensuring the attacker’s point of penetration and any associated vulnerabilities have been eliminated and all system operations have been restored.

Note: In a case of high criticality incident it is advised to purge the affected system and recover/ rebuild from latest back up after the investigation had finished and point of entry had been identified.

Periodic Testing & Remediation

It is the responsibility of the IT Department to test and review the Incident Response Plan quarterly. 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. VR Assets LLC may initiate a mockup incident to test incident response reaction at any time.

Incident Response Action Plan

This document discusses the steps taken during an incident response action.

1) Anyone who discovers the incident will contact the Incident Response Team Member (IRTM). The IRTM will log:

Name of an employee and source of incident alert.
Time of first report.

Nature of the incident.

Systems involved.
Location of service involved.
How the incident was detected.

The above noted information to be saved till deemed unusable by the CEO

2) The IRTM who received the call will evaluate the hypothetical criticality of the treat. System Admins must always be reached by both email and phone in cases of perceived High or Medium criticality incident. Following information shall be recorded at this time:

Is the equipment affected business critical?
What is the perceived severity of the potential impact?

Name of systems being targeted and IP address.

IP address or any other information about the origins of the incident.

3) Contacted IRTM will discuss the situation with at least one more IRTM and determine a response strategy. Following is a check list for the response strategy determination:

Is the incident real or perceived?
Is the incident still in progress?

What data is affected?

What is the impact on the business and data if the attack succeeds? High, Medium or Low
What systems are targeted and their locations?
Is the incident inside the trusted network?

Can the incident be quickly contained?
Will the response alert the attacker and do we care?

What type of incident is this?

4) An incident log will be created. The incident will be assigned a criticality level following these categories:

High - Incidents that have a monumental impact on the Company business or service to clients.
Medium - Incidents that has a significant or has the potential to have a monumental impact on the Company business or service to its clients.
Low - Incidents that has the potential to have a significant or monumental impact on the Company business or service to its clients.

5) IRTM will review system logs, look for gaps in logs, review firewall logs, etc., to determine how the incident was caused. Only System Admin should be examining IT systems. All potential evidence should be preserved and secured.

6) IRTM will implement changes to prevent the occurrence from happening again and/or spreading to other systems.

7) The IT Department will restore the affected system(s) to the pre-incident state and assess potential damages.

In cases of High criticality incidents, System Admin shall determine feasibility of affected system restoration. If there is a suspicion the system may not be fully sanitized from the suspected threat then the system is to be rebuilt from a safe, offline back up.

8) Post-incident, review of response and update policies may be commenced. Preventive steps must be established so the incident doesn’t happen again. An incident report shall be written and sent to the CEO. The report should list all affected system and steps taken to remedy. All logs pertaining to the incident are to be supplied with an incident report.