Saturday Ransomware Alert: Thirty Days of Logs, No One on Call
A retailer has three sites protected by FortiGates with FortiGuard subscriptions, FortiEDR on 450 endpoints, a FortiSandbox appliance, and a FortiAnalyzer keeping 30 days of logs with older logs archived to a NAS every week. There is no SOAR platform and no on-call rota; the SOC analyst starts at 08:00 on Monday. At 02:40 on Saturday, FortiEDR raises file-encryption behaviour on two finance laptops. FortiAnalyzer shows those hosts queried a newly registered domain and opened TLS to a rare foreign IP that the IPS signature for Kryptik command-and-control blocked. Nothing else was alerted. The CISO wants to know what to do first, whether FortiGuard IOC and outbreak alerts would have changed the outcome, and whether a 12-month log retention requirement is actually met.
1. Walk through the first hour of triage once the analyst arrives on Monday, including containment and scoping.
Read the worked answer
The clock started on Saturday, so the first hour is about establishing what already happened, not about preventing it.
Validate. Confirm the FortiEDR alert is real by reviewing the process tree, the encrypting binary's path and signature, and whether files were actually modified. Check whether the blocked command-and-control attempt means the payload never got instructions, which changes both impact and urgency.
Contain. Isolate both laptops through FortiEDR, which preserves management connectivity while cutting lateral movement. Block the domain, IP and file hashes at the FortiGate and in FortiEDR. Disable the two users' accounts and force credential resets, because the payload ran in their context.
Scope. Search FortiAnalyzer for the domain, IP and hash across all three sites and the full 30-day window, not just the two known hosts. Look for SMB, RDP and remote service creation events from those hosts, which indicate lateral movement. Pull FortiSandbox verdicts for any submitted samples. Check whether other endpoints contacted the same domain without generating a behavioural alert.
Decide recovery. Reimage rather than clean, restore from backups verified to predate Saturday, and confirm the backups themselves were not reachable from the encrypted hosts.
Communicate. Follow the incident response plan, notify data protection or privacy owners if finance data was exfiltrated, and record the timestamps. The after-hours gap is itself a finding: detection at 02:40 with action at 09:00 gave the attacker roughly 30 hours.
2. Would FortiGuard IOC service and outbreak alerts have changed the outcome here? Explain the mechanism and its limits.
Read the worked answer
Partly, and it is important to be precise rather than sell the CISO a false comfort.
The IOC service distributes curated indicators, such as malicious hashes, IPs, domains and URLs, from FortiGuard Labs to subscribed enforcement points, so newly observed malware infrastructure can be blocked before locally installed signatures catch up. Outbreak alerts give advance warning of significant campaigns, with emergency detection content and guidance, which lets a team pre-emptively block or hunt. Both would raise the chance that the newly registered domain was blocked on first contact and that the encrypting binary was recognised earlier, and the outbreak context would have helped the Monday analyst prioritise.
But look at what actually happened: the IPS signature for Kryptik command-and-control fired. Signature-based network defence worked. The failures were response-time and scoping, not detection content. IOCs are also perishable, since attackers rotate domains and addresses, so a block only helps if it is applied quickly; and IOC feeds contain only known-bad artefacts, so a novel payload can still execute on the endpoint.
So the honest answer: IOC and outbreak services would improve prevention and context and are worth having, but they do not replace 24/7 response capacity, automated containment, or endpoint prevention. They shorten one link in the chain, not the whole chain.
3. The compliance team requires 12 months of searchable logs, but FortiAnalyzer holds 30 days and the rest goes to NAS archives. Assess the gap and advise on FortiSOAR given the weekend detection gap.
Read the worked answer
Treat these as two separate decisions that are being bundled by frustration.
On retention: weekly archives satisfy a storage obligation but not a search obligation. If an auditor or investigator needs to query month nine, someone must restore archives and search them offline, which is slow and often incomplete. Size the requirement honestly first by measuring daily ingest across the three sites and multiplying by 365 with headroom, then choose between expanding FortiAnalyzer storage, adding a second unit, or forwarding logs to a platform suited to long retention and cross-source search. Whichever route is chosen, write and test a restore procedure, because an untested archive is a compliance claim rather than a control. FortiAnalyzer remains the right home for Fortinet device logs either way.
On FortiSOAR: the weekend gap is primarily a coverage problem, and automation does not create an on-call rota. What SOAR does well is collapse repetitive steps: on a FortiEDR encryption alert, a playbook can isolate the host, block the indicators at the FortiGate, open a ticket, page the on-call engineer and start the scoping query within minutes, which directly attacks the 30-hour exposure. That is a genuine argument for a pilot with two or three high-value playbooks, not a platform purchase on day one.
Recommendation: fix retention with a sized, tested design; pilot SOAR against the ransomware use case and measure containment time; and separately address after-hours coverage, because no playbook wakes anyone up.