SOC Operations Guide

Application modes

Recommended rollout: Reporting → review routes and “would block” signals → Detection-only → Protection.

Route learning — what it does not replace

• Learns HTTP Method + URL only — not parameters, headers, or JSON structure.
• A known route can still be blocked if payload matches an attack rule (e.g. SQLi on API).
• OpenAPI validation is separate — manual upload, opt-in per app, when API Security is enabled.

False positives on static assets

SQL/CRS rules may match query strings on .js, .css, .map files. The product:

• Labels likely false positives in protection logs and Geo Traffic Wall
• Excludes them from attack count metrics
• Applies scoped engine skip on GET/HEAD static paths only
• Does not disable SQLi globally — API endpoints stay fully inspected

SOC Queue

• Priority score 0–100 with human-readable reasons
• Deduplication by app + IP + attack rule
• Read-only — does not change incident state or auto-remediate
• Use it to decide where to start, not as the enforcement engine

Investigation workflow

1. Start from SOC Queue or attack report — note virtual directory column
2. Open incident → read decision explanation (rules, risk, TI, geo, campaign)
3. Check if alert is labeled likely false positive (static asset SQL)
4. Tune: IP/UA exceptions, module detect-only, custom rule, virtual patch
5. Threat intel feeds are advisory until a decision policy blocks