Product Capability · E-ITDR
Response
and audit
Response actions are issued on the basis of investigation findings and role permissions, and every step carries a state you can check. High-risk actions are governed together by role permissions, multi-factor authentication, approval and review.
Available Actions
What can be issued, and what it touches
Actions are laid out by their effect on the business. Read-only evidence gathering can happen at any time; anything that cuts connections or affects availability should pass an approval first. The two do not belong in the same workflow.
| Action | Purpose | Effect on the business |
|---|---|---|
| Collect file, process, network and authentication evidence | Fill in the raw records an investigation needs | Read-only; endpoint state unchanged |
| Pull exfiltration status, IOCs and workload audit data | Assess blast radius and how far it spread | Read-only; endpoint state unchanged |
| Push policy, change collection level, refresh rules | Temporarily raise visibility or tighten detection | Changes collection intensity; may increase endpoint resource use |
| Delete, quarantine or track a file | Deal with a malicious file on disk, or keep watching it | Changes endpoint file state; confirm false-positive risk first |
| Stop a process | Interrupt suspicious activity in progress | May affect whatever that process was serving |
| Isolate a host or restrict its network | Cut off lateral spread | Cuts that host's network connections |
| Agent upgrade, restart and safe uninstall | Version maintenance and withdrawal | Detection is interrupted meanwhile |
“Effect on the business” describes the nature of each action; it is not a built-in risk grading. Which actions need approval, and from whom, is configured by your organisation in its own role permissions and approval workflow.
Command Lifecycle
A command goes through four stages
Each stage leaves a record you can check. Lose any one of them and afterwards nobody can say whether the thing actually ran.
- Raised according to role permissions and the approval result
- Operator, target asset and action parameters recorded
- High-risk actions are held here awaiting approval
- Accepted by the agent after identity binding and signature checks
- Delivery time recorded
- An unreachable endpoint shows that state plainly
- Running, succeeded, failed, timed out and cancelled are all visible
- “Issued” is never treated as “succeeded”
- Failures are not folded into the success count
- Check the result against the investigation's conclusion
- Re-test the scenario to judge whether the response held
- Every operation is on record for later tracing
Execution States
Failure and timeout are results too
In an incident the dangerous outcome is not a failed action — it is believing an action succeeded. So every terminal state is shown on its own and never merged.
Governance
Four controls decide who can touch what
The barrier to using response is not technical, it is authorisation. Only with these four stacked together does putting host isolation into a routine workflow become reasonable.
Commands pass identity binding and signature verification on the channel, and the platform verifies agent identity from the authentication context rather than trusting fields the client submits. Disabling accounts, firewall blocking and backup restoration belong to other systems in your organisation; this product does not carry them out on their behalf.
Audit Trail
The record has to survive later questions
Audit records serve the retrospective as much as the compliance check: a month later, someone must be able to rebuild both the judgement and the action.
| Record | Content | Question it answers |
|---|---|---|
| Operator and role | Who raised it, the role held at the time, and the approver | Who approved it and who issued it |
| Target asset | Stable asset identity plus the hostname and IP at the time | Which machine was touched |
| Action and parameters | The action type executed and its specific parameters | What was done |
| Time sequence | Times for issue, delivery, execution start and terminal state | When it happened |
| Execution result | Succeeded, failed, timed out or cancelled, with the failure reason | Whether it actually worked |
| Supporting basis | The alert or investigation finding behind the response | What justified the decision |
The field list is a structural description, not a product screenshot. Actual records and retention periods vary by product version and platform configuration; how an incident is reported externally is determined by your organisation under the applicable regulations.
What Comes Next
Related capabilities
The five capabilities share one body of evidence. Follow the investigation onward, or return to the overview.
Asset Identity & Telemetry Management
Capability 05
Agent identity decoupled from network attributes, changes kept as snapshots, collection gaps visible as first-class data.
View capabilityFile Activity & Exfiltration Investigation
Capability 03
Recorded file activity and network-layer transfer statistics on the same timeline as identity and process evidence.
View capabilityE-ITDR Product Overview
Product and deployment
Architecture, how the five capabilities divide the work, supported environments and boundaries.
Back to overviewExpert Consultation
Fit the response workflow into your own approval structure
Tell us about your current incident process and approval levels, and we will say which actions can sit in routine work and which need separate authorisation:
Action scope review
Which actions affect the business
Approval chain design
Roles, MFA and approval levels
Records and retrospectives
Audit fields and retention
Scan with Feishu to consult