Product guide

Threats

Bring alerts, DLP incidents, behavior signals, and endpoint activity into one investigation workflow.

What Threat Investigation Is#

Threat investigation collects the security signals the platform already produces and puts them in one review queue. Its purpose is to remove the tab-switching that makes investigation slow.

The platform does not invent a verdict. It gives you the signal, the affected asset, and the surrounding history, and it records your decision so the next reviewer sees it.

Moftgate findings and investigation screen — Findings and their distribution by classification rule.

Signal Sources#

Four sources feed the investigation queue. Each one has its own detail page and its own documentation:

Source	What it contributes
DLP incidents	Sensitive-content matches raised by DLP policies across the protected channels.
Monitor alerts	Threshold and availability alerts raised by monitoring policies.
Behavior analytics	Anomalous endpoint user and process behaviour that does not match the baseline.
Forensic timeline	Chronological event history around an endpoint or a user.

One queue, many sources

The value of this module is correlation. Reading the same endpoint across four signal types is what turns an alert into an explanation.

Triage#

Sort by severity first, then by time. A critical signal that is two days old matters more than an informational one from a minute ago.
Check whether the affected endpoint is still reporting. A disconnected endpoint changes what you can verify.
Look for repetition. The same signal on the same asset several times is a configuration problem, not a one-off event.
Assign before you investigate deeply, so two people do not work the same incident.

Investigation Workflow#

1
Validate the signal
Check the alert source, the endpoint, the user, and the time window. Confirm the signal is about the system you think it is about.
2
Expand the context
Read the activity, behavior, and forensic timeline together. A single alert rarely tells the whole story.
3
Decide and assign
Set an owner and a status. Assigning the incident is what prevents it from being reviewed twice by two people.
4
Record the outcome
Close the incident with a note that explains the decision. If a policy or automation caused the alert, adjust it rather than closing silently.

Check the context before closing

Always review the endpoint, user, and policy context before closing an incident. Closing without a note loses the reasoning for the next person.

Frequently Asked Questions#

Do DLP incidents appear here?

Yes. Threat investigation is designed to review DLP incidents alongside the other security signals, so one incident can be read in context.

Should I close an incident I do not understand?

No. Leave it open, add a note describing what is unclear, and assign it to the person who owns the affected system.

What is the difference between behavior analytics and the forensic timeline?

Behavior analytics tells you that something unusual happened and scores it. The forensic timeline reconstructs the exact sequence of events so you can explain it.