OmniNet protected site architecture
From a high level, let's review how OmniNet architecture works and why it is implemented this way. All partners are recommended to adhere to the design recommendation of sending all egress and ingress traffic through our filtering services without a separate NAT. This creates a full picture of network activities within a clients network.
Each means of terminating to OmniNet services is designed to send out all outbound traffic to our scanning and filtering services known as OmniShield at the data center. Inversely, all inbound traffic must come through our services first and only then passed on to customer networks.
Recommendations matter
If recommended installations are implemented properly, then any traffic on the client network should be flowing through OmniNet and therefore being scanned against all known malicious traffic, to which we would be actively alerted, thereafter contact would be made to partners for action. This is why we stress all traffic should flow through OmniNet and any circumvention should be cautiously avoided.
This topology helps defend against currently known threats as well as other malicious threats yet to be identified. Staying behind OmniNet keeps you protected behind our automatically updating defenses against newly discovered threats.
Recommended deployment topology
<-Modem/ISP hardware(Wifi off)-> <-OmniBridge-> <-Internal network/Wifi AP->(all client devices)
Recommended setup should have the OmniBridge sitting on the network edge (connected directly to modem).
Nothing else should be connected to modem.
Partner: "I have deviations from above topology, are other deployments okay?"
If your customer's network has other routing devices on their network, they should not be...
A) In line - in front of a OBR, as in between the ISP and the Cloud-link. In line is not recommended.
B) Side-by-side scenario - Cloud-link would provide no protection to anything connected side-by-side (Device not connected behind the Cloud-link, but still connected to ISP modem/hardware
Partner: "Well the topology is either deviation A or B, and I receive information of a possible vulnerability with that vendors hardware..now what?"
Any configuration that deviates from recommended scenarios should be reviewed and corrected. If there happens to be an installation with one or more devices in front of the Cloud-link/OmniBridge or connected to the customers network, immediately review why this was implemented as such, and work with appropriate vendor towards recommended remediation for affected vulnerability or if deemed unnecessary, remove the device completely.
Partner: "Well, I need to keep this device connected for some reason, now what?"
Place it behind OmniNet protection immediately. If it is not compatible behind OmniNet, you should find a workaround as leaving vulnerable devices unprotected (not behind OmniNet) can leave your customers network exposed and void your OmniNet Cyber Breach Guarantee eligibility.
In either case, reach out to the vendors support and request a patch or mitigation for the vulnerability. Patch as soon as is possible. It is extremely important that you work with the manufacturer to ensure that your device is up to date with the latest patched versions. If not, you should apply the updated patches immediately.
Make sure you are defended!!!
This presents a good time to remind partners that you should make certain that client devices are connected behind OmniNet and not accidentally or intentionally circumventing OmniNet protection.
-Make sure clients are not connecting to WiFi networks on ISP devices, or other wireless networks that are not sitting behind OmniNet.
- Block VPNs and Proxies with the custom web filter, or Moderate selection
- Make sure your customers security is on and content filter is enabled.
- Perform a quick run of shieldtest.com makes sure the client is surfing through clean internet provided by OmniNet.