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:
Day shift System Admin:
Night shift Developer:
Day shift Developer:
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
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.
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.
Definition: Incidents that have a monumental impact on the firm’s business or service to clients. Example: Unauthorized system access, ransomware, virus infestation, etc.
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.
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.
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 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.
Location of service involved.
How the incident was detected.
The above noted information to be saved till deemed unusable by the CEO
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.
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?
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.
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.
© Copyright © 2022 Compeve Corporation.