Web and Email Inspection<\/a> is relevant because the action should match the confidence and user\/business consequence of being wrong.<\/p>\nFortiSandbox succeeds when analysis depth is allocated to the files that need it<\/h3>\n 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.<\/p>\n
Sandboxing creates value when unknown content moves from \u201csuspicious file\u201d to observable behavior and actionable evidence without becoming the slowest component in every security transaction.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Verdict disagreement should trigger review. If AV says malicious while dynamic analysis appears clean\u2014or vice versa\u2014inspect behavior, static indicators, cloud rating, VM suitability, and sandbox-evasion possibilities. Do not automatically trust the ‘cleanest’ result simply because it reduces operational work.<\/p>\n
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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19985","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t