Scenario Solution · WEB-ITDR
Identity threat
triage and response
There are plenty of alerts; few of them can be called. This solution groups raw alerts by identity into events that can actually be worked, explains what triggered them, proposes graded response actions, and records what was executed as evidence you can review later.
The Problem
Plenty of alerts, few that can be called
What an operations team faces each day is not whether alerts exist, but whether this one is worth acting on, on what grounds, and how the action will be explained afterwards. Without answers to those three, more alerts do not become more protection.
Where It Applies
What this process attaches to
Triage and response are not a separate system; they attach to the coverage and the operating process you already have. Confirm the three things below and the grading and action list become writable.
- Alerts come from applications and entry points connected to Web ITDR
- The deployment decides visible fields and available actions
- Systems that are not connected are outside this process
- From one or two people part-time to a rostered watch
- Grading and action lists are agreed to match the team
- The first line acts on stated grounds, not on instinct
- Connects to SIEM, ticketing and approval systems
- Cross-system unified triage remains with the SIEM
- Some response actions are finally executed elsewhere
Under passive mirror deployment this process produces alerts, grounds and recommended actions, while the actual block has to be carried out by the identity system or the network side; only reverse proxy deployment can enforce policy on the access path itself. Deployment options are covered in business access and identity protection.
How It Works
From a raw alert to an action you can account for
Five stages: the first two address "too much to read", the middle two address "cannot be explained", and the last addresses "nothing to show afterwards". Three layers of triage serve three roles, each reading the layer it needs.
| Triage layer | Input and output | Written for |
|---|---|---|
| Event level | In: several grouped alerts from one source or one account. Out: what this episode is, which accounts and assets it touches, and which stage it is at | Managers and audit: what this episode is as a whole |
| Record level | In: one raw access record and its fields. Out: the key anomalous fields, the grounds, and the other access it correlates with | Analysts: whether the verdict holds up |
| Recommended action | In: the two conclusions above plus current business context. Out: graded actions, expected effect and a note on the risk of over-blocking | Duty operators: what to do and where the risk is |
Grouping collapses many alerts from one episode into a single event. The grouping supports judgement; it is not confirmed causation, and how far it collapses depends on alert quality and policy configuration — grouped too aggressively, separate episodes end up merged.
AI here plays an assisting role: every conclusion cites specific fields and correlations so a person can check it, and whether the conclusion stands and whether the action runs is decided by a person and left on the record. The system does not decide for anyone, and it does not log a recommendation as an action taken.
Division of Responsibility
Judgement can be assisted; decisions need a signature
The easiest mistake in triage is to treat a recommendation as a decision already made. The table separates the two, and marks the actions that must be executed by another system.
| Step | Web ITDR | Handled by a person or existing systems |
|---|---|---|
| Grouping and noise reduction | Groups by identity and time into events | Suppression policy takes effect once operations confirm it |
| Triage conclusion | States a verdict and cites the fields and correlations behind it | An analyst confirms whether the verdict holds |
| Recommended action | Gives graded actions, expected effect and risk notes | Whether to execute is decided by an authorised person |
| Actions on the proxy path | Allow, challenge or block, and record the result | Policies and thresholds are maintained by the operations team |
| Account and credential actions | Not executed on your behalf | IAM / directory: password reset, MFA step-up, account suspension |
| Network-side blocking | Not executed on your behalf | Firewall / network team |
| Tickets and approvals | Emits records that can be filed | The existing ticketing and approval systems |
| Cross-system unified triage | Emits identity-level alerts and evidence | SIEM / SOC: cross-system aggregation and unified triage |
Every row marked "not executed on your behalf" affects the business or an employee directly and belongs to the owner of that system, inside their own process. What this solution owes them is a clear account of the grounds, the scope of impact and the expected effect.
Rollout
Reduce the noise before writing the action list
Four steps, each producing the input for the next. Skip noise reduction and go straight to the action list, and the grading you write will follow the noise instead of the risk.
- Confirm where alerts come from and which fields are visible
- Align formats with the existing SIEM and ticketing
- Agree who watches alerts and when
- Observe for a period and establish what normal access looks like
- Tune grouping and suppression
- Remove repeats and known sanctioned behaviour
- Agree the grading criteria and the actions at each level
- Note the impact and over-blocking risk of every action
- State which actions need approval first
- Execute along the authorisation path and record the result
- Review misses and false calls on a regular cycle
- Write review conclusions back into policy and list
On order: finish noise reduction before setting the grading. Write the action list while the noise is still there and the grading follows the noise; once live, most actions land on events that never needed handling, and the first line stops using the list.
Validation
Take one real alert through all four steps
The most direct way to test whether this process holds is to take an alert that already happened and follow it from grouping through to filing, checking that each step can be accounted for.
Evidence depends on what was collected. How complete the timeline and the relationship view are depends on the connected scope and log visibility; anything not collected should appear as a gap rather than as an inferred line.
Agree the alert scope, the acceptance criteria and the review cycle before the pilot. No figures for noise reduction, triage accuracy or response time are reported until validation is complete. What the demonstration environment shows is a product demonstration scenario, not any customer's actual incident record.
Expert Consultation
Take one real alert and walk it through to the review
Tell us where your alerts come from, how large the operations team is and how tickets flow, and we will use one real or agreed alert to walk through grouping, triage, response and filing:
Grouping and noise reduction
How raw alerts become events
Grounds for the verdict
Which fields and links it cites
Response and filing
Action, authorisation, receipt, review
Scan with Feishu to consult