Scenario Solution · WEB-ITDR
Business access
and identity protection
A successful login does not make the access trustworthy. Web ITDR sits at the entry point of your applications, puts every request back into its account, device and session context, judges whether it fits how that identity normally behaves, and acts within the limits of how it is deployed.
The Problem
Real accounts, ordinary entry points
At the application layer, most logins and requests look perfectly legitimate: the account is real, the password is correct, the request carries no attack signature. Authentication covers one part and request-level protection covers another. The part in between — who this really is, from which device and session, and how it differs from before — belongs to no system.
Where It Applies
Three kinds of web entry point, one identity convention
The scope is access that happens over the web or an API. All three connect the same way but raise different questions — decide which category you are bringing in first, then decide how to connect it.
- SSO portals and IAM / IDaaS front doors
- In-house authentication services, OAuth2 / OIDC endpoints
- Directory service login pages exposed on the web
- Internal systems: office, finance, mail, CRM, ERP
- Customer-facing web applications and mobile back ends
- Internal and public business APIs
- Jump servers, virtualisation and cloud consoles
- Container orchestration and operations platforms
- Database consoles and security appliance interfaces
The third category means the part of that access which happens through a web management interface. Credential activity on the endpoint itself, remote execution across hosts and lateral movement are out of scope here; they belong to E-ITDR, in credential abuse and lateral movement defense. Note also that the visible fields depend on how the product is connected: a passive mirror mainly observes, while only a reverse proxy can enforce an access policy.
How It Works
What happens between the request and the record
The chain below is the full path under reverse proxy deployment. A passive mirror performs the same identification and judgement; only the response step needs an external system to complete it.
| Field group in one access event | What this group answers |
|---|---|
| Account | The application account and the organisation it belongs to — whose name this access is under |
| Device and client | Device identifier, client type and request characteristics — what it came from |
| Session | When the session started, where it came from and what followed — what happened after entry |
| Grounds | The rule or characteristic that fired, plus other access it correlates with — why this was called anomalous |
| Outcome | The action taken under proxy protection, and its record — what was done and how it ended |
A structural illustration, not a product screenshot. The fields actually visible vary with deployment and version; under a passive mirror the last row records the alert and the recommended action, while the block itself has to be carried out by the identity system or the network side.
Division of Responsibility
Alongside your IAM, WAF and SIEM, each doing its own part
This solution adds one layer — deciding who the acting subject is and holding the identity-level evidence. It does not replace what you already run. The table states who does what, including what this solution does not do.
| Step | Web ITDR | Handled by existing systems |
|---|---|---|
| Accounts and entitlements | Does not manage account lifecycle or grant permissions | IAM / SSO: accounts, roles, entitlements, MFA policy |
| Authentication | Observes the process and its result, identifies abnormal logins | IAM / SSO: performing the authentication itself |
| Request-level attack protection | Detects identity-related web attack behaviour | WAF: generic exploit and rule-based protection |
| Deciding the acting subject | Separates human from automated access; ties account, device and session together | Usually no system owns this — it is the layer added here |
| Executing a response | Allow, challenge or block on the proxy path | Password reset, MFA step-up and account suspension run in the identity system; network blocks run on the network side |
| Alert aggregation and ticketing | Emits identity-level alerts and evidence | SIEM / SOC: cross-system aggregation and unified triage |
| Endpoint-side behaviour | Not covered | EDR and E-ITDR: endpoint processes, credential activity, lateral movement |
The right-hand column states who normally carries each part. It is not an assessment of those systems and not a product comparison. The real division is confirmed against the architecture you already have, and one platform may well cover several rows.
Rollout
Confirm the environment first, then choose the side to connect from
The sequence is: agree on environment and scenarios, connect a small scope and validate, then expand on the result. Both modes can be used in stages within one environment — observe passively first, then switch the applications you intend to act on to proxy mode.
- List the applications, entry points and APIs in scope
- Confirm network path, TLS termination and field visibility
- Agree on the first set of validation scenarios
- Reverse proxy: can enforce access policy
- Passive mirror: stays out of the request path, observes and alerts
- Different applications may use different modes
- Start with one or two applications
- Check that identity fields are complete and alerts explainable
- Confirm policy actions and their effect on the business
- Extend to remaining applications and entry points
- Settle the policy and response action list
- Connect to SIEM and ticketing
| Aspect | Reverse proxy | Passive mirror |
|---|---|---|
| Position in the path | On the access path | Copies traffic, off the access path |
| Involvement in the business | Forwards requests | Does not touch the request path |
| Actions available | Allow, challenge, block and other access policy | Alerts mainly; blocking needs an external system |
| To confirm beforehand | Network path, certificates, session persistence, failure plan | Mirror points, traffic completeness, visibility of encrypted traffic |
| Typical use | Authentication entry points and business that must be acted on in place | Production systems with strict availability needs, or an observation phase |
The two modes see different fields, so when the connection changes, the scope of what the detection conclusions cover changes with it. The actual design is settled against the network and business conditions on site; there is no single default that fits every application.
Validation
Take one anomalous access and follow it to the end
What matters in validation is not how many alerts appear, but whether one alert can answer four questions: why it fired, on what grounds, what was done and how it ended. Only when all four have answers is the alert something an operations team can work with.
Agree on the test scenarios, the time window, the evidence standard and the operating conditions before the pilot starts. No performance figures are reported until the testing is complete. What the demonstration environment shows is a product demonstration scenario, used to explain how evidence supports a verdict; it is not any customer's actual incident record.
Expert Consultation
Take one of your entry points and check deployment and visible fields
Tell us which applications you need to protect, how they authenticate and what the network allows, and we will come back with a deployment option, the fields it would actually see and what it can act on:
Deployment assessment
Reverse proxy versus passive mirror
Field-level review
Which identity and request fields are visible
Response conditions
What this solution executes and what your existing systems do
Scan with Feishu to consult