> For the complete documentation index, see [llms.txt](https://docs.blusapphire.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blusapphire.io/m-soc/m-soc-or-architecture-and-workflow/incident-response-workflow.md). # Incident Response Workflow ## Incident Response Workflow ### Standard Operating Procedure (SOP) ## 1. Purpose This document outlines the incident response process for alerts received from the **Next-Gen SIEM**, detailing the responsibilities of **M-SOC, RE (Regulated Entity), and Exchange** at each stage of incident handling. ## 2. Scope This SOP applies to all security alerts/Incidents triggered in the **Next-Gen SIEM**, ensuring timely detection, notification, and remediation of security incidents. ## 3. Roles & Responsibilities * **M-SOC**: Responsible for triaging, confirming incidents, and tracking resolution. * **RE (Regulated Entity)**: Takes necessary actions, submits the Root Cause Analysis (RCA), and remediate/resolve the incident. * **Exchange**: Facilitates communications with external regulatory bodies (e.g., CERT-IN, NCIIPC, SEBI) as required. ## 4. Incident Handling Procedure {% stepper %} {% step %} ### Alert Reception * **M-SOC** receives an alert from **Next-Gen SIEM** and assesses its severity: * **Critical** * **High** * **Medium** * **Low** {% endstep %} {% step %} ### Incident Classification and Notification #### Critical Incident 1. **M-SOC** triage and confirms the alert as a **Critical Incident**. 2. **M-SOC** notifies the **RE SPOC (Single Point of Contact)**. 3. **M-SOC** sends a notification to **Exchange**. 4. **RE** informs **CERT-IN/NCIIPC/SEBI** (if required as per impact). 5. **M-SOC** tracks incident status. #### High Incident 1. **M-SOC** triage and confirms the alert as a **High Incident**. 2. **M-SOC** notifies the **RE SPOC**. 3. **M-SOC** sends a notification to **Exchange**. 4. **M-SOC** tracks incident status. #### Medium Incident 1. **M-SOC** triage and confirms the alert as a **Medium Incident**. 2. **M-SOC** notifies the **RE SPOC**. 3. **M-SOC** tracks incident status. #### Low Incident 1. **M-SOC** triage and confirms the alert as a **Low Incident**. 2. **M-SOC** notifies the **RE SPOC**. 3. **M-SOC** tracks incident status. {% endstep %} {% step %} ### Incident Resolution * **RE** takes action to mitigate and remediate the incident. * **RE** submits the **Root Cause Analysis (RCA)** to both **Exchange and M-SOC** (for Critical and High Incidents). * **For Medium & Low Incidents**, **RE** updates M-SOC on the resolution status. {% endstep %} {% step %} ### Validation and Closure * **M-SOC** validates the resolution provided by **RE**. * **M-SOC** closes the incident upon successful resolution verification. * **End of Process**. {% endstep %} {% endstepper %} **Incident Workflow** and **Defined SLA’s** are detailed in [Annexure A](https://app.gitbook.com/o/RP5QC3ULbyB3uRyWKTb8/s/-MMRHZBPHlLDUc8519fX/~/edit/~/changes/316/m-soc/m-soc-or-architecture-and-workflow/incident-response-workflow#annexure-a) ## 5. Compliance and Reporting * **M-SOC** must ensure that all incidents are tracked and documented. * **RE** must report critical incidents to regulatory authorities as required. * **RE** must provide an RCA for every incident to improve future security posture. ## 6. Escalation Matrix * If an incident is not addressed within the defined SLA, **MSOC** escalates it to the higher-level stakeholders within **RE and Exchange**. * For unresolved or repeated security incidents, **Exchange** and **MSOC** must collaborate on further mitigation strategies. {% hint style="info" %} **Note** – Response and mitigation must be performed by the **RE**. BluSapphire is responsible only for sharing recommendations. The BluSapphire team will provide guidance to the RE via Microsoft Teams if any assistance is required. BluSapphire **does not support or engage** in remote access to the RE's environment using remote administration tools such as AnyDesk, TeamViewer, etc. {% endhint %} ### Annexure A Incident Workflow:
#### Classification of cybersecurity incidents
ClassificationLevelDetails
Low1- System probes or scans detected on external systems
- Intelligence received concerning threats to which systems may be vulnerable
- Intelligence received regarding username
-password compromise- Isolated instances of known malware easily handled by antivirus software
Medium2- Target recon or scans detected
- Penetration or Denial of Service attacks attempted with no impact on operations
- Widespread instances of known malware easily handled by antivirus software
- Isolated instances of new malware not handled by antivirus software- Instances of phishing emails clicked by employees
- Instances of data corruption, modification, and deletion being reported
High3- Penetration or Denial of Service attacks attempted with limited impact on operations - Widespread instances of new malware not handled by antivirus software - Unauthorized access to servers and network devices- Unauthorized or unexpected configuration changes on network devices detected- Impersonation of SEBI officials in emails- Data exfiltration - High volume of phishing emails- Outbound phishing emails- Some risk of negative financial or PR impact
Critical4- Successful penetration or Denial of Service attacks with significant impact on operations- Ransomware attack - Exfiltration of market-sensitive data- Widespread data corruption impacting operations - Significant risk of negative financial or PR impact
#### Classification of incident SLA’s:
S.No.KPISLA Timelines
1Time to Detect> 4 Min
2Time to RespondCritical – 30 Mins
High – 60 Mins
Medium – 90 Mins
Low – 120 Mins
3Time to ResolutionCritical – 2 Hours
High – 4 Hours
Medium – 2 Business days
Low – 5 Business days