How FortiSense detects risk

How it works

FortiSense looks for early warning signals in how processes behave and how systems are used not just whether a file matches a known signature.

Many security tools either block known malware or collect huge volumes of telemetry that require specialist analysis. FortiSense takes a different approach: it focuses on high-signal indicators of risk, explains why something looks suspicious, and lets you decide what action to take.

No black boxes. No forensic overload.

Behaviour + resource signalsProcess chainsExecution contextHash / known-bad matchesOffline continuity
Detection

Detection focused on signal, not noise

FortiSense is designed around a simple principle:

Most real incidents leave warning signs before they become obvious malware.

Instead of trying to log everything, FortiSense watches for patterns that commonly appear when something isn’t behaving as expected especially on systems that normally stay quiet.

Alerts are

easier to understand

Policies are

easier to tune

Signals are

easier to trust

Signals

The signals FortiSense monitors

FortiSense combines several types of signals to build context around what’s happening on an endpoint.

Behaviour & resource signals

Signal
What this means

FortiSense watches how processes behave over time, not just what they’re called.

Examples
  • Sudden CPU or memory spikes from unexpected processes
  • Processes behaving differently from their normal baseline
  • Unusual outbound network activity
Why it matters

Abuse, misuse, and early-stage attacks often cause resource or network changes before anything clearly malicious appears.

Parent–child process chains

Signal
What this means

FortiSense records which process launched another process.

Examples
  • A document viewer launching a scripting engine
  • A background service spawning an interactive shell
  • A system process starting user-space tooling
Why it matters

Some process relationships are normal. Others are not. Seeing what launched what provides immediate context that simple alerts lack.

Execution paths & context

Signal
What this means

FortiSense looks at where executables are running from, not just their names.

Examples
  • Executables running from user-writable directories
  • Tools executing from temporary or unusual locations
  • Legitimate binaries used outside their expected context
Why it matters

Attackers often rely on trusted tools running from unexpected places. Context helps separate normal admin work from risky execution.

Known-bad process names & file hashes

Signal
What this means

FortiSense compares executables against a database of known malicious hashes and identifiers.

Examples
  • Known malicious hashes matched on an endpoint
  • Known-bad process identifiers observed in a snapshot
  • Hash matches combined with behaviour context
Why it matters

Signature-based matching is still valuable, especially when combined with behavioural context rather than used alone.

Important clarification

Not just signatures

Hash and identifier matching is one signal among many not the only detection method.

Alerts

How signals turn into alerts

FortiSense does not alert on a single weak signal.

Instead, alerts are raised when:

  • confidence thresholds are crossed
  • multiple risk indicators align
  • or a known high-risk condition is detected
Each alert includesEvidence
  • the process involved
  • how it was launched
  • what behaviour triggered concern
  • what evidence was observed

This makes alerts actionable, not just informative.

Explainability

Explainable by design

When FortiSense raises an alert, it explains why.

Instead of

“Threat detected”

You see
  • what happened
  • what triggered concern
  • what evidence was observed

This allows you to:

  • quickly decide whether to quarantine
  • safely ignore false positives
  • refine policies without guesswork
  • explain decisions to colleagues or stakeholders

Explainability is what makes FortiSense usable without a dedicated security team.

Continuity

Protection doesn’t stop when connectivity drops

Real environments aren’t always online.

FortiSense is designed to continue operating when endpoints are:

  • offline
  • intermittently connected
  • restricted by network policies
When offline, the agentLocal-first
  • continues monitoring behaviour
  • uses cached intelligence for high-confidence decisions
  • stores telemetry locally

When connectivity resumes, telemetry is uploaded and alerts are processed normally.

This ensures visibility and protection even during outages especially on critical systems.

Scope

What this approach intentionally avoids

FortiSense does not try to:

  • record every system call
  • provide full forensic timelines
  • replace enterprise SOC tooling
  • make opaque “AI-only” decisions

Those capabilities exist elsewhere but they come with complexity and cost that many teams don’t need.

FortiSense focuses on early visibility, clarity, and control.

Fit

Who this detection model works best for

This approach works best if you:

  • want early warning signals, not post-incident forensics
  • manage desktops and servers with limited security staff
  • prefer explainable alerts over automated black boxes
  • need lightweight protection with minimal overhead

If you need compliance reporting, SOC workflows, or full incident reconstruction, FortiSense is best used alongside not instead of enterprise EDR.

Next step

Ready to see FortiSense in action?

Deploy the agent, generate real signals, and see how explainable detection works in your own environment.

Free to evaluate. No long-term commitments.

Summary

Detection
FortiSense focuses on
  • high-signal indicators
  • context across signals
  • explainable, actionable alerts
It avoids

forensic overload and “log everything” telemetry.

Quick links

Product

Want a fit check? Tell us your environment and we’ll suggest which signals matter most for your endpoints.