SOC alert fatigue after EDR and NDR onboarding
Meridian Health's SOC has 12 analysts, FortiSIEM 7.1, FortiSOAR 7.3, FortiEDR on 6,000 endpoints, and FortiNDR at two data centers. The SIEM ingests 4,500 events per second and generates about 700 alerts per day; analysts close 60% as false positives. FortiEDR coverage is 70%, with the gap concentrated in clinical workstations running an old imaging agent. Three SOAR playbooks for phishing, malware, and impossible travel fail at the enrichment step because the threat-intelligence API returns HTTP 429 during morning peaks. FortiNDR detects suspicious SMB traffic but the alert reaches the SIEM without the endpoint hostname, so analysts manually correlate. The CISO wants mean time to detect under 15 minutes for ransomware precursors and a 30% reduction in alert volume within 60 days, without adding headcount.
1. Prioritize the fixes across SIEM, SOAR, EDR, and NDR. What would you do in the first two weeks, and why?
Read the worked answer
First two weeks: fix the two force multipliers - NDR-to-SIEM context and SOAR enrichment - before tuning alerts. Without hostname correlation, analysts cannot triage ransomware precursors quickly; without reliable enrichment, playbooks fail and alert backlog grows.
Priority order:
- Add hostname/user mapping to FortiNDR syslog (DHCP, DNS, AD, FortiNAC, or EDR API) and parse it in FortiSIEM.
- Fix SOAR API rate limits with throttling, caching, backoff, and a queue; split enrichment into parallel steps.
- Close EDR coverage on clinical workstations via GPO/MDM or a lightweight installer; track by OU.
- Tune the top five noisy SIEM rules using a two-week baseline, not blanket suppression.
Why not tune first: tuning 700 alerts without endpoint context risks hiding real lateral movement. Fix context, then suppress known-good patterns with documented exceptions. Measure daily alert volume, false-positive rate, EDR coverage, and playbook success.
2. Design the detection and response workflow for a ransomware precursor that starts with FortiNDR SMB detection and ends with endpoint isolation. Include the data needed at each step.
Read the worked answer
Workflow:
- FortiNDR detects SMB lateral movement (repeated ADMIN$ or IPC$ access) and sends an alert with sensor, source/dest IP, SMB share, user, and detection name.
- FortiSIEM correlates with DHCP/DNS/AD to resolve hostname and owner, and with FortiEDR telemetry for process, hash, and device ID.
- SOAR enriches the hash/IP with threat intelligence, checks whether the endpoint is isolated or high-risk, and opens a case.
- If the EDR verdict is malicious or the host is a ransomware precursor, SOAR calls FortiEDR to isolate the endpoint, blocks the hash/IP on FortiGate, and notifies the on-call analyst.
- Analyst validates, scopes other hosts, and documents.
Data needed: NDR flow/remote host, SMB share, user, EDR device ID, process tree, file hash, DHCP lease, AD group, and FortiGate policy logs. Without hostname, the workflow stalls; that is why mapping is step one.
3. How would you tune alerting without creating blind spots, and which metrics would prove the CISO's goals are met?
Read the worked answer
Tuning without blind spots: use risk-based alerting, allow-list only known-good admin scanners and clinical imaging traffic, tune thresholds per subnet, and convert low-fidelity rules to correlation rules with EDR/NDR context. Keep a monthly review of suppressed rules and run atomic tests (for example mimicking SMB lateral movement) to confirm detection.
Metrics: alert volume per rule, false-positive rate, MTTD for ransomware precursors, MTTR, percentage of alerts with hostname/user enrichment, SOAR playbook success rate, EDR coverage, and number of suppressed rules re-tested. A 30% volume reduction is only valid if MTTD stays under 15 minutes and detection tests still pass.