Skip to main content
Incident Response
Sanjeeva Samarawira avatar
Written by Sanjeeva Samarawira
Updated over 2 years ago

Policy Owner: Wired2Perform, LLC

Effective Date: 29th March 2021

  1. Purpose

This document establishes the plan for managing information security incidents and events, and offers guidance for employees or incident responders who believe they have discovered, or are responding to, a security incident.

2. Scope

This policy covers all information security or data privacy events or incidents.

3. Incident and Event Definitions

A security event is an observable occurrence relevant to the confidentiality, availability, integrity, or privacy of company controlled data, systems or networks.

A security incident is a security event which results in loss or damage to the confidentiality, availability, integrity, or privacy of company controlled data, systems or networks.


4. Incident Reporting & Documentation

Reporting

If a Wired2Perform, LLC employee, contractor, user, or customer becomes aware of an information security event or incident, possible incident, imminent incident, unauthorized access, policy violation, security weakness, or suspicious activity, then they shall immediately report the information using one of the following communication channels:

Reporters should act as a good witness and behave as if they are reporting a crime. Reports should include specific details about what has been observed or discovered along with screenshots.

Severity

Infrastructure team shall monitor incident and event tickets and shall assign a ticket severity based on the following categories.

S3/S4 - Low and Medium Severity

Issues meeting this severity are simply suspicions or odd behaviors. They are not verified and require further investigation. There is no clear indicator that systems have tangible risk and do not require emergency response. This includes lost/stolen laptop with disk encryption, suspicious emails, outages, strange activity on a laptop, etc.

S2 - High Severity

High severity issues relate to problems where an adversary or active exploitation hasn’t been proven yet, and may not have happened, but is likely to happen. This may include lost/stolen laptop without encryption, vulnerabilities with direct risk of exploitation, threats with risk or adversarial persistence on our systems (e.g.: backdoors, malware), malicious access of business data (e.g.: passwords, vulnerability data, payments information), or threats that put any individual at risk of physical harm.

S1 - Critical Severity

Critical issues relate to actively exploited risks and involve a malicious actor. Identification of active exploitation is required to meet this severity category.

Escalation and Internal Reporting

The incident escalation contacts can be found below in Appendix A.

S1 - Critical Severity: S1 issues require immediate notification to raghu@wired2perform and sanjeeva@wired2perform management.

S2 - High Severity: An email should be sent in the event of a S2 event or incident and the appropriate manager (see S1 above) must also be notified via email or slack with a reference to the ticket number.

S3/S4 - Medium and Low Severity: A JIRA ticket must be created and assigned to the appropriate department for response.

Documentation

All reported security events, incidents, and response activities shall be documented in JIRA system.

A root cause analysis may be performed on all verified S1 security incidents. A root cause analysis report shall be documented and referenced in the incident ticket. The root cause analysis shall be reviewed by Sanjeeva Samarawira (Product Manage) and Milinda Dias (Tech Lead) who shall determine if a post-mortem meeting will be called.


5. Incident Response Process

For critical issues, the response team will follow an iterative response process designed to investigate, contain exploitation, eradicate the threat, recover system and services, remediate vulnerabilities, and document a post-mortem with the lessons of an incident.

Summary

  • Event reported

  • Triage and analysis

  • Investigation

  • Containment & neutralization (short term work)

  • Recovery & vulnerability remediation

  • Hardening & Detection improvements (lessons learned, long term work)

Detailed

  • Tech Lead or Product Manager will manage the incident response effort

  • A central “War Room” will be designated, which may be a physical or virtual location (i.e Slack channel)

  • A recurring Incident Response Meeting will occur at regular intervals until the incident is resolved.

  • Legal and executive staff will be informed as needed

Incident Response Meeting Agenda

  • Update Incident Ticket and timelines

  • Document new Indicators of Compromise (IOCs)

  • Perform investigative Q&A

  • Apply emergency mitigations

  • Plan long term mitigations

  • Document Root Cause Analysis (RCA)

  • Additional items as needed

Special Considerations

Internal Issues

Issues where the malicious actor is an internal employee, contractor, vendor, or partner requires sensitive handling. The incident manager shall contact Raghu Misra (CEO & Co-Founder) directly and will not discuss with other employees. These are critical issues where follow-up must occur.

Compromised Communications

Incident responders must have Slack messaging arranged before listing themselves as incident members. If there are IT communication risks, an out of band solution will be chosen, and communicated to incident responders via cell phone.

Additional Requirements

  • Suspected and reported events and incidents shall be documented.

  • Suspected incidents shall be assessed and classified as either an event or an incident.

  • Incident response shall be performed according to this plan and any associated procedures.

  • All incidents shall be formally documented, and a documented root cause analysis shall be performed.

  • Suspected and confirmed unauthorized access events shall be reviewed by the Incident Response Team. Breach determinations shall only be made by the CEO and legal counsel in coordination with executive management.

  • Wired2Perform, LLC shall promptly and properly notify customers, partners, users, affected parties, and regulatory agencies of relevant incidents or breaches in accordance with Wired2Perform, LLC policies, contractual commitments, and regulatory requirements.

  • This Incident Response Plan shall be reviewed and tested at least annually.

6. Roles & Responsibilities

Every employee and user of any Wired2Perform, LLC information resources has responsibilities toward the protection of the information assets.

7. Exceptions

Requests for an exception to this Policy must be submitted to and authorized by Raghu Misra(CEO & Co-Founder) and Sanjeeva Samarawira (Product Manager) for approval. Exceptions shall be documented.


8. Violations & Enforcement

Any known violations of this policy should be reported to the CEO. Violations of this policy may result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.

Version

Date

Description

Author

Approved by

1.0

29-Mar-2021

This is The First Version

Sanjeeva

Sajeeva

Appendix A – Contact Information

Contacts for IT and Engineering Management as well as executive staff and can be found below

Raghu Misra (CEO & Co-Founder) - raghu@wired2perform.com - (+1904-422-2321)

Sanjeeva Samarawira (Product Manager) - sanjeeva@wired2perform.com (+94 0775831170)

Did this answer your question?