FortiSandbox is a malware behavior-analysis platform that combines pre-filtering, antivirus/cloud checks, static analysis, dynamic execution in virtual machines, reputation/rating services, YARA and threat-intelligence context, and integrations with FortiGate, FortiMail, FortiWeb, FortiProxy, FortiClient and other Fortinet products. Current FortiSandbox 5.2 documentation organizes the analysis pipeline around scan profiles, VM associations, job priority/archive, allowlists and blocklists, customized ratings, YARA rules, threat-intelligence services, and Security Fabric integrations.
Within Fortinet Security Operations, the right workflow is not “send everything to a VM.” It is to pre-classify files and URLs, spend expensive dynamic-analysis capacity where it adds evidence, produce a defensible verdict, and return that verdict quickly enough to protect the mail/web/endpoint control that submitted the object.
Threat Detection and Incident Workflows provides the wider model for turning a sandbox verdict into investigation and response.
Scan profiles define the analysis pipeline
Current FortiSandbox scan profiles control which file types enter the job queue, which VM images are associated with them, and which enhanced or cloud-assisted scan options apply.
Create profiles around risk and source rather than one universal configuration. Email attachments, web downloads, executable submissions, Office files, PDFs, archives, and URLs can have different VM and timeout requirements.
Document which integrations use each profile so changing one analysis rule does not unexpectedly affect mail, firewall, and endpoint workflows at once.
Pre-filtering should save VM capacity without hiding risk
Static engines, antivirus, allow/block lists, reputation, and other pre-filters can classify many objects before a dynamic VM runs.
This reduces queue time and lets VM resources focus on unknown or suspicious objects.
Keep pre-filters current and review allowlists carefully; a broad allow rule can bypass exactly the analysis an attacker is trying to avoid.
VM association should reflect the file’s real execution environment
FortiSandbox associates file types with installed VM images and applications.
A malicious Office document should be observed in an environment capable of opening the relevant Office version; a script or PDF needs a suitable runtime/viewer.
Maintain VM images, patches, application versions, and clone counts so the sandbox resembles user environments without becoming so outdated that malware behaves differently from production.
Static findings can still be forced into dynamic analysis
Current FortiSandbox advanced profile settings can force files already rated by antivirus or static analysis into associated VMs to collect additional indicators.
This is useful during investigations, validation, or high-risk flows where behavior detail matters beyond the verdict.
Use selectively because forcing every known-malicious object through VMs consumes capacity without necessarily improving prevention.
Adaptive and parallel VM scanning improve throughput
Current 5.2 scan-profile options include adaptive scan behavior and parallel VM scanning on supported appliance deployments.
Adaptive scanning can rebalance VM clones toward busy images; parallel scanning can run several required VM analyses simultaneously when capacity exists.
Monitor queue depth and VM utilization before enabling aggressive concurrency so throughput improvements do not overwhelm storage, reporting, or downstream integrations.
Pipeline mode trades isolation mechanics for performance
Pipeline mode can reuse a VM instance for sequential jobs when the prior scan did not change the guest state in a way that requires restoration.
This reduces VM startup/shutdown overhead.
Use it according to current support guidance and verify that isolation/restore behavior remains appropriate for the file classes being processed.
Dynamic scan timeouts should follow file and URL behavior
Short timeouts reduce queue latency but can miss delayed or sandbox-aware behavior.
Long timeouts improve observation but reduce throughput.
Tune executable, non-executable, and URL scan timing from measured malware behavior and business SLA; do not set one long timeout for every benign document simply because longer sounds safer.
Cloud-assisted reputation should be understood in restricted environments
Current FortiSandbox offers Community Cloud Query and Cloud Rating Service options that can improve detection and rating with external intelligence.
Air-gapped or highly regulated environments may disable some cloud services.
Record which verdict components rely on cloud connectivity so analysts do not compare results from isolated and internet-connected sandboxes as though the evidence sources are identical.
Job priority should protect high-value workflows
A flood of low-priority bulk submissions can delay analysis of a suspicious executive email or incident-response sample.
Use job priority and integration design so high-risk mail, SOC manual submissions, and active incident artifacts are processed promptly.
Monitor queue age by source/profile; average queue time can hide a high-priority workflow stuck behind one expensive file type.
Verdict should feed blocking, quarantine, and investigation differently
FortiGate, FortiMail, FortiWeb, FortiProxy, FortiClient and other integrations can consume sandbox results for enforcement.
Define what happens for malicious, suspicious, low-risk, clean, timeout, unsupported, or analysis-error outcomes.
Web and Email Inspection is relevant because the action should match the confidence and user/business consequence of being wrong.
FortiSandbox succeeds when analysis depth is allocated to the files that need it
The mature workflow pre-filters aggressively but safely, maintains realistic VMs, uses adaptive/parallel capacity, tunes timeouts, prioritizes incident-critical jobs, and feeds verdicts into explicit enforcement and SOC paths.
Sandboxing creates value when unknown content moves from “suspicious file” to observable behavior and actionable evidence without becoming the slowest component in every security transaction.
Integration policy should distinguish synchronous blocking from asynchronous analysis. Email gateways and web proxies may hold content while a verdict is pending, while endpoint or file-share workflows may allow activity and receive a later result. Define what each source does on timeout, service outage, or queue saturation so availability decisions are explicit rather than inherited from one default profile.
Allowlist and blocklist entries should be treated as security policy with expiry. A vendor installer or internal tool may be allowlisted after repeated false positives, but future versions or file paths can change. Record hash/publisher/source, owner, reason, and review date, and prefer the narrowest indicator that fixes the legitimate workflow without exempting an entire directory or domain.
Customized ratings can align sandbox verdicts with organizational policy. A file classified as suspicious may require quarantine in finance but analyst review in a developer sandbox. Keep rating overrides documented and scoped to known patterns; do not force benign/malicious verdicts merely to reduce alert volume when the underlying behavior remains unexplained.
YARA rules can add organization-specific detection for known malware families, tooling, or document structures. Test rules against a clean corpus and known samples because an overly broad YARA signature can increase every submission’s workload and generate false positives across several integrated Fortinet products. Version these rules like other detection content.
Job archive and report retention should match incident needs. A malicious sample may become important weeks later when responders discover related endpoints or campaigns. Preserve hashes, verdict, behavior indicators, screenshots/PCAP or report artifacts according to privacy and storage policy so the SOC can revisit the evidence even after the live queue has moved on.
Security Fabric integration should prevent circular submission loops. If FortiMail sends a file to FortiSandbox and the verdict is forwarded through another system that resubmits the same object, duplicate jobs waste capacity. Use job hashes/cache behavior and well-defined integration ownership so the same sample is analyzed once unless an explicit rescan is required.
Sandbox-resistant malware should influence workflow design. Some samples delay execution, check hardware/user activity, or require specific applications or network responses. Use several VM images where justified, realistic applications, extended timeout for high-risk samples, and manual analyst reruns for cases where static indicators conflict with a clean dynamic result.
Zero-day workflows should feed network and endpoint containment quickly. When FortiSandbox identifies a new malicious sample, distribute hashes/URLs/domains through supported Fortinet Fabric packages or other security platforms, search historical telemetry for prior sightings, quarantine affected mail/files, and isolate compromised endpoints where evidence supports it.
Capacity planning should use submission source and file type. Office/PDF/email URLs can have different VM duration than executables or archives. Track jobs per integration, percent reaching dynamic VM, average scan time, queue depth, and timeout rate so licensing/VM clone count changes are driven by actual bottlenecks rather than anecdotal slow analyses.
Sample privacy should be considered before cloud-assisted analysis. Email attachments, documents, and URLs can contain confidential information. Understand which metadata or artifacts leave the appliance for cloud reputation/rating services, and use enclosed/air-gapped modes where policy requires local-only analysis.
Manual SOC submissions should have a separate high-priority workflow with analyst context. Record incident ID, suspected source, hash, why the sample is being rescanned, and which enhanced settings are enabled. This prevents manual investigations from becoming anonymous jobs that cannot be correlated back to the case.
Verdict disagreement should trigger review. If AV says malicious while dynamic analysis appears clean—or vice versa—inspect behavior, static indicators, cloud rating, VM suitability, and sandbox-evasion possibilities. Do not automatically trust the ‘cleanest’ result simply because it reduces operational work.
Sandbox reports should preserve the behavioral indicators analysts can hunt for elsewhere: child processes, mutexes, files, registry keys, domains, IPs, URLs, commands, persistence methods, and dropped payload hashes. The best verdict is one that immediately enables enterprise-wide retrospective search and containment.
FortiSandbox upgrades should include regression samples. Maintain a small set of benign, known-malicious, evasive, Office/PDF, URL, and archive examples and compare verdict, VM behavior, processing time, and integration response after major releases. This catches analysis changes before production traffic reveals them.
