Air-Gapped File Policy: Why Known-Bad Files Sailed Through
A defense integrator runs an inline FTD pair in front of a lab file server. The FMC and both FTDs sit in a fully isolated enclave with no internet egress by design; DNS and NTP are available locally, but there is no route to any Cisco cloud service. The relevant access control rule allows the lab subnet to reach the file server, with an intrusion policy and a file policy attached. The file policy rule matches any file with the Malware Cloud Lookup and Block Malware action, and file storage is enabled. Analysts ran an approved test: a ZIP archive containing an EICAR-based sample and a known-bad executable were downloaded from the file server. Neither was blocked, Analysis > Files lists both files with disposition Unknown, and no malware events were generated. The customer refuses to open any internet egress and wants to know why a product bought for malware defense is not blocking files it has already identified as malicious.
1. Explain why nothing was blocked and why both files show as Unknown.
Read the worked answer
The rule's blocking decision is conditional on a reputation verdict. Malware Cloud Lookup and Block Malware submits the file's fingerprint to the cloud reputation service and only blocks when the returned disposition is Malware. In this enclave that lookup cannot complete, so every file resolves to Unknown, the 'malware' condition is never satisfied, and the file is permitted. That is working as designed, not a licensing or signature failure.
The intrusion policy is unrelated: IPS signatures inspect traffic, not files, and would not fire on an EICAR sample inside a ZIP unless a signature happened to match the archive content.
Two further reasons the archive could have escaped even with egress: the file policy may not have been reached at all if the download was inside TLS that is not decrypted, and archives are inspected only to configured depth and size limits, so the inner executable may never have been extracted for analysis.
The honest framing for the customer: an offline deployment cannot use a cloud reputation service, so file defence has to come from a source that works offline.
2. Which links in the inspection chain do you verify before recommending any product change?
Read the worked answer
Work from the traffic log outward; most 'file policy did not block' cases are upstream of the verdict.
- Access control rule action: file policy is only evaluated for rules that allow the connection. A Trust, Monitor or Block rule never hands files to the file policy.
- Attachment of the file policy: confirm the file policy is actually selected on that specific rule and that the rule, not a rule above it, matches the test flow. The connection event's rule ID tells you which rule handled it.
- Decryption: if the test used HTTPS or SMB over TLS, verify the SSL policy decrypts that flow. Undecrypted traffic yields no file events at all.
- File events, not just connection events: check whether files were detected, sent, or skipped, and why. Skipped-for-size and archive-depth reasons appear here.
- Transfer limits: confirm the test file and its extracted contents fall inside the configured maximum file size and archive depth limits, and test with a small uncompressed sample as a control.
If all of that is correct and disposition is still Unknown, the verdict source is the problem, which is the expected result in an air-gapped enclave.
3. Rank the realistic options for the customer given the no-egress constraint, and state what each one actually buys them.
Read the worked answer
- On-premises Secure Malware Analytics with dynamic analysis. Point the file policy at the internal appliance and add dynamic analysis to the rule. Files are detonated locally, verdicts are produced without internet, and Block Malware has something to act on. Best detection coverage; requires an appliance, capacity planning and a sandbox-aware configuration, and it only helps after the file is submitted, so tune so that suspicious files are submitted rather than everything.
- Local malware analysis on the sensor. On-box analysis that needs no cloud connectivity and can flag suspicious files the sensor can analyse on its own. Cheap and immediate, but weaker than detonation and limited by file type, size and available sensor CPU; treat it as an additional layer, not a replacement.
- File-type and format blocking. Rules that block or alert on executables, scripts and archives by type, with no reputation needed. This works fully offline and stops the common case, at the cost of false positives for legitimate software and no visibility into what the file actually does.
- Accept that reputation-based blocking is unavailable and compensate with egress controls, application allow-listing and IPS. Document it as a risk decision, not a technical gap.
Recommend 1 combined with 3, keep the existing cloud rule in place for any future enclave that gains egress, and re-test with the same samples.