I am currently evaluating Orca Security's deployment options for a highly restrictive financial services environment that mandates complete network isolation from external endpoints. The documentation references an "offline collector" capability for air-gapped networks, but the provided details are high-level and lack the operational specifics necessary for a thorough architectural review. I am seeking detailed, experiential feedback from practitioners who have implemented this component.
My primary concerns revolve around the data synchronization mechanics and the subsequent performance profile of the platform in this configuration. Specifically:
* **Collector Update Mechanism:** The documentation suggests using a portable storage device to transfer updates. What is the exact format and procedure? Is it a simple file copy, or does it involve a proprietary packaging system? Are the updates cumulative or differential, and what is the typical payload size for, say, a monthly update cycle?
* **Data Egress Volume & Frequency:** In a standard deployment, the collector streams findings to the Orca cloud. In an air-gapped setup, data must be physically transported. What is the realistic volume of data generated per 100 assets over a 24-hour period? Does the collector perform any aggressive compression or deduplication before writing to the portable media? Understanding this is critical for estimating operational overhead.
* **UI/Platform Latency:** Once the offline data is ingested into the on-premises Orca appliance (if that is the model), are there noticeable differences in dashboard load times or query responsiveness compared to the SaaS offering? The centralized processing in the cloud likely has significant compute resources; I am skeptical that a self-contained appliance can match this without introducing latency.
* **Benchmarking the Scan Cycle:** Has anyone performed comparative scans of an identical asset set in both online and air-gapped modes? I am interested in any measurable delta in:
* Time-to-completion for a full scan.
* Resource consumption (CPU, memory, I/O) on the scanned hosts by the collector agent.
* Depth of vulnerability detection, particularly for signatures that might require external lookup (e.g., CVE databases that are typically updated in real-time).
A sample of the documented, but vague, configuration stanza for the collector is below. I am particularly interested in how the `offline_mode` and `update_source` parameters are pragmatically managed.
```yaml
collector:
mode: "airgap"
offline_mode: true
update_source: "/mnt/secure/usb-drive/updates/"
local_cache_ttl: 720h
reporting_path: "/mnt/secure/usb-drive/outbound/"
```
Concrete data on these points would be invaluable. Anecdotes about pitfalls during the initial data transfer or challenges in maintaining signature parity with the cloud service would also be highly relevant to my cost-benefit and risk analysis.