UpdatedJune 12, 2026

Fully Managed EPP SOC Alert Processing Summary

Description

SonicSentry delivers a 24x7 Security Operations Center (SOC) that monitors, detects, investigates, and responds to security threats on behalf of our partners. Our monitoring spans endpoints and servers. This document describes our incident response methodology, severity-based runbooks, escalation procedures, and the service level commitments that govern our operations. It is intended to provide partners with a clear understanding of how we protect their environments and what they can expect from us when an incident occurs.

Incident Response Cycle

Our methodology follows a continuous five-phase cycle designed to both prevent incidents and recover from them effectively.

Phase	Description	Owner
01 - Prepare/Protect	Ensure all security controls, configurations, and tooling are in place, tested, and validated before any threat occurs.	Partner & SonicSentry Support
02 - Detect	Monitor telemetry across endpoints and servers. Automated correlation rules and manual threat hunting identifies anomalous or malicious activity across all sources.	SOC
03 - Mitigate	When a confirmed or high-confidence threat is identified, the SOC takes immediate containment action to limit damage and prevent further spread - without waiting for partner authorization in Critical situations.	SOC
04 - Investigate	Analyze & document the timeline, scope, and impact of the incident through analysis of available telemetry and endpoint data. This includes identifying any related activity or events within the environment that were not part of the initial alert.	SOC
05 - Remediate	Once the threat has been eradicated, the partner restores systems, configurations, and data to their known-good state with SOC guidance as needed.	Partner

Alert Processing

The SOC ingests and analyzes telemetry from across the partner environment. Monitored data sources include:
- Endpoints & Servers - Anti-Virus and AV/EDR agents process events locally and forward them to their respective management portals.
These events are then sent to the SIEM/SOAR owned by SonicWall Managed Security Services, Inc. as syslogs.
The SIEM/SOAR leverages automation to identify anomalistic or malicious activities and generate security incidents for the SOC Analyst to process/investigate.
- SOC Analysts will also perform manual investigations (threat hunting) in the SonicWall XDR platform to provide additional scrutiny on potentially malicious or anomalistic activity that cannot be automated. Findings from these investigations will start a manual security incident.

The following targets apply to all automated event processing and represent our standard of care for partner environments.

Metric	Target	Notes
Target Analysis Time	15 minutes	Automated event triage and classification
Target Response Time	30 minutes	Analyst action or partner notification initiated

These targets reflect the time from when an event is received by the SIEM/SOAR platform to when analyst action or partner notification is initiated. Complex, multi-system incidents may require additional investigation time beyond the initial response.

Application Block Processing

When the AV/EDR platform blocks an application, the SOC Analyst evaluates the event and assigns it to one of four categories. The category determines the SOC response, the level of partner involvement required, and how a notification is sent.

Approved Application Inventory

The approved application inventory is the SOC's primary reference for evaluating block events. It is collected by the Support team during client kickoff and must include:

All sanctioned business applications
Known MSP remote management and monitoring (RMM) tools
Any dual-use tools already in use with explicit partner approval and written risk acknowledgment on file
Line of business applications — PSA, ERP, accounting, and industry-specific software
Any pre-existing exceptions agreed during the Proof of Concept phase

If an application is not on the approved inventory list, the SOC does not assume it is legitimate. While legitimate files can sometimes be detected by the AV platform — commonly due to software updates, new application versions, or administrative tools — the SOC reviews the detection against the approved inventory and available telemetry before determining the appropriate response.

SOC leaves it blocked, notifies the partner, and awaits instruction — except where Category 4 behavioral indicators are present, in which case the event is treated as a security incident regardless of list status.

Block Event Categories

All block events are evaluated against the approved application inventory and the behavioral context of the event, then assigned to one of the following four categories:

Cat.	Examples	Examples	SOC Action	Partner Notification
1	Approved / Obvious Business App	Microsoft 365, QuickBooks, Adobe, known industry tools	SOC clears immediately. Add to approved list if not already present.	Email notification to MSP via ticket
2	Non-Business Application	Steam, gaming clients, personal utilities	Leave blocked. Notify MSP. No SOC recommendation on whether to allow.	Email notification to MSP via ticket
3	Dual-Use Tool	FileZilla, PuTTY, AnyDesk, WinSCP, nmap	Leave blocked. Notify MSP with dual-use risk context. Written acknowledgment required before unblock.	Email to MSP with risk context. Written acknowledgment required.
4	Suspicious in Context	Approved tool running from temp dir, abnormal time, unexpected user	Treat as incident regardless of list status. Escalate immediately.	Email + phone call per severity runbook

Category 1 — Approved or Obvious Business Application

Classification: Routine clearance Notification: None required

The blocked application is either already on the partner's approved inventory or is a widely recognized, unambiguous business application (e.g., Microsoft 365, Adobe Creative Cloud, QuickBooks, industry-specific line-of-business software).

Step	Action	Owner
1	Analyst receives block event alert from the AV/EDR platform.	SOC Analyst
2	Analyst cross-references the blocked application against the partner's approved application inventory.	SOC Analyst
3	Analyst confirms the application is on the approved list or is an unambiguous business application with no indicators of misuse.	SOC Analyst
4	Analyst clears the block and implements or confirms the appropriate exclusion in the AV/EDR platform.	SOC Analyst
5	If the application was not previously on the approved inventory, the analyst adds it to the client's approved application record so future instances are not flagged.	SOC Analyst
6	Analyst documents the action in the incident record and sends notification to the partner in a Minor alert.	SOC Analyst
7	If the partner agrees with the exclusion, no response is needed unless they would like it removed.	Partner

Category 1 is the fast-track lane. If the application is clearly legitimate and context is normal, the SOC clears it without partner involvement and ensures the approved list is kept current. This prevents repeated blocks for the same application.

Category 2 — Non-Business Application

Classification: Non-business application Notification: Email notification to partner via ticket

The blocked application has no identified business purpose and is not on the partner's approved inventory. Common examples include gaming clients, personal utilities, and consumer software.

Step	Action	Owner
1	Analyst receives block event alert from the AV/EDR platform.	SOC Analyst
2	Analyst cross-references the blocked application against the partner's approved application inventory. Application is not present.	SOC Analyst
3	Analyst determines the application has no identifiable business purpose.	SOC Analyst
4	Analyst leaves the application blocked. No exclusion is created.	SOC Analyst
5	Analyst opens a ticket and sends an email notification to the partner's designated SOC Alert contact. The notification includes: application name and version, affected endpoint and user account, timestamp, the reason blocked (not on approved list), category assignment, and the action required from the partner to unblock.	SOC Analyst
6	The SOC does not provide an opinion on whether the application should be allowed. That decision belongs to the partner and their end client.	SOC Analyst
7	Partner reviews the block notification and responds via the ticket — either by replying directly or using the allow/deny action in the notification. The partner's response is automatically logged to the ticket record including requester identity and timestamp.	Partner
8	SOC Analyst reviews the partner's response. If the partner approves the application, the analyst creates the exclusion in the AV/EDR platform and adds the application to the partner's approved inventory. If denied, the block remains in place. The ticket is updated and closed.	SOC Analyst

Category 3 — Dual-Use Tool

Classification: Dual-use tool — elevated documentation required: Email notification to partner with risk context

The blocked application has legitimate administrative uses but is also commonly used in attacks, data exfiltration, and unauthorized remote access. Examples include FileZilla, PuTTY, AnyDesk, WinSCP, nmap, and Process Hacker.

Step	Action	Owner
1	Analyst receives block event alert from the AV/EDR platform.	SOC Analyst
2	Analyst cross-references the blocked application against the partner's approved application inventory. Application is not present.	SOC Analyst
3	Analyst identifies the application as a dual-use tool with known attack use cases.	SOC Analyst
4	Analyst leaves the application blocked. No exclusion is created.	SOC Analyst
5	Analyst opens a ticket and sends an email notification to the partner's designated SOC Alert contact. In addition to standard block notification details, the notification explicitly identifies the dual-use nature of the tool, its legitimate use case, and the specific attack scenarios in which it is commonly abused.	SOC Analyst
6	A written risk acknowledgment from the partner is required before any unblock will be processed. The partner must confirm they are aware of the dual-use risk and accept responsibility for authorizing the application in their environment.	Partner
7	Partner responds via ticket with written authorization and risk acknowledgment. The response is automatically logged to the ticket record including requester identity and timestamp.	Partner
8	SOC Analyst reviews the partner's response and confirms the written risk acknowledgment is on file. If confirmed, the analyst creates the exclusion in the AV/EDR platform and adds the application to the approved inventory with the risk acknowledgment documented permanently against the client record. If the partner does not provide acknowledgment, the block remains in place.	SOC Analyst
9	If the partner does not provide acknowledgment, the block remains in place.	Partner

Risk acknowledgments for Category 3 tools are retained permanently in the client profile. If the same tool is later found operating in a suspicious context (Category 4), the existence of an acknowledgment does not override the behavioral escalation.

Category 4 — Suspicious in Context

Classification: Treat as security incident: Email and phone call per severity runbook

The blocked application or process exhibits behavioral characteristics inconsistent with normal operation regardless of whether it appears on the partner's approved application inventory. Indicators include execution from unusual paths (e.g., temp directories), activity outside normal business hours, execution under unexpected user accounts, abnormal parent-child process relationships, or lateral movement patterns.

Approved list status does not override behavioral context. A tool on the approved list running in suspicious circumstances is a Category 4 event. The SOC does not treat this as a policy change request.

Step	Action	Owner
1	Analyst receives block event alert from the AV/EDR platform.	SOC Analyst
2	Analyst cross-references the blocked application against the approved inventory and evaluates behavioral context — execution path, user account, timestamp, parent process, and correlated activity across the environment.	SOC Analyst
3	Analyst identifies behavioral indicators inconsistent with normal operation. The event is reclassified as a security incident regardless of the application's list status.	SOC Analyst
4	Analyst classifies the incident at the appropriate severity level (Minor, Major, or Critical) based on available evidence and engages the corresponding severity runbook immediately.	SOC Analyst
5	Analyst documents all findings, behavioral indicators, and the rationale for Category 4 classification in the incident record.	SOC Analyst
6	Analyst notifies the partner per the applicable severity runbook. Category 4 events with confirmed or high-confidence compromise are treated as Critical and follow the Critical Severity Runbook including mandatory phone notification.	SOC Analyst
7	There is no unblock or policy change path for Category 4 events. The event is handled as an incident through to resolution. Any subsequent policy changes required as a result of the investigation are processed separately after the incident is closed.	SOC Analyst

Alert Severities

Incidents are assigned one of three alert severities based on the analyst's assessment of available evidence, regardless of the source platform.

Alert severities are not static. They may be elevated or lowered at any point as additional evidence is gathered or as partner confirmations are received. Partners will always be notified when a severity level changes.

Severity	Description	Notification	Mitigation Actions	Severity Change
Minor	Abnormal activity across any monitored platform; informational	Email only	None	Can be elevated
Major	Suspicious activity across any monitored platform; no confirmed compromise	Email; phone call at analyst discretion	None	Can be elevated or lowered
Critical	High-confidence compromise (breach or active infection) across any monitored platform	Email + phone call required	Endpoint isolation	Can be lowered upon confirmation

Incident Response Runbooks

Minor Severity Runbook

Classification: Informational
Notification: Email only
Mitigation: None

Abnormal activity has been identified across one or more monitored platforms that does not meet the analyst's expectation of normal activity. The false-positive rate for Minor alerts is relatively high; however, the information is considered valuable for the partner to review and determine whether further investigation is warranted.

Step	Action	Owner
1	Analyst receives automated alert or identifies activity through threat hunting across any monitored platform (endpoint, server).	SOC Analyst
2	Analyst investigates available telemetry to assess authenticity, timeline, and context.	SOC Analyst
3	Analyst determines activity is abnormal but does not meet the threshold for suspicious or malicious classification. For known benign alerts, such as events triggered by an RMM tool, an exclusion may be implemented and the partner will be notified of the actions taken. For application block events, the analyst evaluates the block against the Application Block Processing categories (Section 2.1) and follows the applicable category runbook.	SOC Analyst
4	Analyst classifies incident as Minor and documents findings and any exclusions or policy changes in the incident record.	SOC Analyst
5	Analyst sends email notification to the partner's designated SOC Alert contact, including full investigation details and a recommendation to review.	SOC Analyst
6	No mitigation actions are taken. The partner is responsible for determining whether the activity is legitimate and whether the SOC's response aligns with their expectations, and should notify the SOC if changes are needed.	Partner
7	If the partner's review reveals indicators of compromise or escalating activity, the partner notifies the SOC to re-investigate. The analyst may elevate severity accordingly.	SOC / Partner

Major Severity Runbook

Classification: Suspicious Activity
Notification: Email; phone call at analyst discretion
Mitigation: None

The SOC has identified suspicious or potentially malicious activity with reasonable confidence across one or more monitored platforms. There is no direct evidence of a compromise at this time; however, the activity warrants partner awareness and further investigation. This classification is commonly associated with threats that were detected and blocked by security tooling.

Step	Action	Owner
1	Analyst receives automated alert or identifies activity through threat hunting across any monitored platform (endpoint, server).	SOC Analyst
2	Analyst investigates available telemetry across all relevant platforms to assess authenticity, timeline, and scope.	SOC Analyst
3	Analyst determines activity is suspicious but finds no direct evidence of a compromise (e.g., threat was blocked or quarantined).	SOC Analyst
4	Analyst classifies incident as Major and documents findings in the incident record.	SOC Analyst
5	Analyst sends email notification to the partner's designated SOC Alert contact with full investigation details and recommended next steps.	SOC Analyst
6	At the analyst's discretion, a phone call may be placed to the partner's emergency contact if the nature of the activity warrants immediate verbal notification (e.g., high-volume suspicious activity, near-miss compromise, unusual identity behavior).	SOC Analyst
7	No mitigation actions are taken. Initiating containment without confirmed compromise risks operational disruption disproportionate to the threat.	SOC Analyst
8	Partner investigates the flagged activity and provides feedback to the SOC. • If compromise is confirmed, the SOC elevates to Critical and engages the Critical runbook immediately. • If an exclusion is necessary, the partner documents the need and scope (level) for the exclusion (Account, Tenant, Group, Device). The SOC responds and makes the requested exclusion within the AV/EDR platform.	Partner / SOC

Critical Severity Runbook

Classification: Confirmed or High-Confidence Compromise
Notification: Email + phone call required
Mitigation: Endpoint/server isolation

The SOC has high confidence that a compromise (breach or active infection) has occurred or is actively occurring within the partner environment. This may originate from or involve any monitored platform. Immediate containment is required. The SOC will initiate mitigation actions without waiting for partner authorization — delay increases the risk of lateral movement, data exfiltration, and broader damage.

Step	Action	Owner
1	Analyst receives automated alert or identifies activity through threat hunting across any monitored platform.	SOC Analyst
2	Analyst conducts rapid triage of available telemetry across all relevant platforms to confirm scope, timeline, and indicators of compromise.	SOC Analyst
3	Analyst classifies incident as Critical and documents findings in the incident record.	SOC Analyst
4	Endpoint: If not already automated, analyst initiates network containment (isolation) on affected endpoint(s) or server(s) to prevent lateral movement and further spread. Connectivity is maintained for ongoing SOC investigation.	SOC Analyst
5	Domain Controller Exception: If the affected device is the sole Domain Controller and DNS resolver for the network, isolation will sever communication with all hosts on that network. The analyst will document this risk and consult the partner before isolating, if contact can be reached rapidly.	SOC Analyst
6	Analyst sends email notification to both the SOC Alert contact and Emergency Contact(s) on file, outlining investigation details and all response actions taken.	SOC Analyst
7	Analyst places a phone call to the partner's emergency contact number(s). Four call attempts will be made within the first hour. • If contact is not made in the first hour, the analyst will place one call attempt at the top of every subsequent hour until contact is established.	SOC Analyst
8	Once contact is made, the analyst briefs the partner on the incident details, containment actions taken, current status, and recommended next steps.	SOC Analyst
9	SOC continues to monitor contained systems and the broader environment across all platforms for additional indicators. Connectivity to isolated endpoints or servers can be restored by the SOC once the threat is assessed as contained and the partner is ready to proceed with remediation.	SOC Analyst
10	Partner leads remediation activities (re-imaging, credential resets, patching, firewall rule changes, configuration review, etc.). SOC provides investigative support as needed.	Partner / SOC
11	Severity may be lowered (e.g., to Major) if further investigation or partner confirmation rules out an actual compromise.	SOC Analyst

Mitigation Capabilities & Scope

The SOC's mitigation capabilities are scoped to the platforms and integrations supported within the SonicWall managed service. The SOC monitors all platforms listed below; response actions vary by platform.

Platform	Mitigation Actions Available	Notes
MDR for Endpoint	Network containment (isolation)	Connectivity is maintained for SOC investigation. SOC can restore connectivity when the partner is ready for remediation.

Understanding our Approach - The Fire Department Analogy

Analogies can assist to explain an unfamiliar concept or idea. To better help our partner community understand the methodology behind our alert classifications, we have summarized our alert processing into the following analogy:

Consider our SOC a Fire Department and our Analysts as Fire Fighters

Minor Classification
- We smell smoke in the area.
- Likely not a fire, however, we will use the information we have to let the homeowner know that something does not seem right.
Major Classification
- We smell smoke and hear the fire alarms in the house, but do not have direct evidence that a fire is burning.
- We do not want to start dousing the house with water as this could potentially cause more harm than good.
- We need the homeowner to investigate further of what might have caused the smoke as we are.
Critical Classification
- We smell the smoke, see the smoke, and see the fire.
- We will immediately attempt to put the fire out (mitigation).
  - We will not ask for permission to do so, as this could cause more harm and damage.
- We will make contact with the homeowner once we have taken all steps we could to mitigate the issue.