SOAR Deployment in Segregated Environment

· There is no direct connectivity between Internet and client’s internal network (where Resilient will be deployed)

· Additionally the internal network is also segregated – one team might be located in one zone and second team in different, physically segregated zone

· Direct connection between these zones (and Internet) is not possible and the eventual data flow must be strictly controlled – when moving data from one zone to another the data must be scanned, logged, captured, potentially approved, etc.

· As you have already implemented Resilient in similar environment it would be great to understand the concept and its influence on functionality (if any) so we can verify what is needed to make Resilient work in client environment

2. Requirements for on premises deployment. I understand this hasn’t been discussed yet so we should include this in the discussion:

· Information required from the client for sizing and deployment

· HW: Number of VM’s, CPU, RAM, Storage, etc. requirements for Resilient on premises deployment

· Components and their required communication (in segregated network environment)

· Testing/Staging environment requirements. The client has testing/staging environment that reasonably copies the production environment functionality – it would be great to have Resilient in this environment as well

· Timelines, etc.

3. Would it be possible to again get access to cloud instance of Resilient? I know this already happened as part of PoC, but now we want to include additional teams. Ideally multiple concurrent user access.

4. Is there any documentation and/or online trainings you could provide to us? I was looking at the publicly available documentation but there are not many documents with technical details…

There are three options that we can consider:

1. – Bring a threat feed into the secured network. Have Resilient query this feed, instead of using the external threat intel sources.
The threat feed would be deployed independently from Resilient – e.g. using QRadar STIX/TAXII, or a separate system such as Soltra Edge or Anomali STAXX. Then deploy a custom threat intelligence feed for Resilient that queries this data source. Functionality would be the same as the built-in threat feeds: query artifacts, show hits, rescan automatically. The scope of the threat intel would be limited to the data feed.

2. – Build an “API Proxy” to provide a way for threat lookup queries to be redirected through the airgap (with manual intervention if necessary).
The proxy would receive queries from Resilient threat intel lookup, then those queries (e.g. cached in a file) would be transferred to the external network, where an agent would receive them and perform the queries against the appropriate sources. Results would be collected and transferred through the airgap, then delivered to Resilient. The threat lookup API is quite suited to this since it has an “asynchronous” mode, where results are not expected immediately. So the results would have some latency (depending on the airgap transfer method and inspection processes) but this is quite a viable option.

2. – Build an “Action Module Proxy”. This is more general than for threat information lookup, it would allow custom actions (menu-item actions, and automatic actions) triggered by rules in Resilient, to be directed to execute outside the network. The Action Module API is asynchronous already (based on message queues), well suited to this sort of extension. A process on the secure network would receive the queries and store them (e.g. cached in a file) for transmission across the airgap. A process on the external network would receive the queue messages, process them, and return the results in a similar way. The results would then be used to update Resilient on the secure network. Some care would be needed to message minimization (the Action Module messages usually include some incident data that should not be transferred across the airgap). But this architecture is very flexible and powerful. Would allow queries e.g. to public DNS and other Internet services.