Follow

OmniNet - WAN Topology with Security In Mind

OmniNet protected site architecture

From a high level, lets quickly 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.  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 Cloud scanning and filtering services known as OmniNet.  Inversely, all inbound traffic must come through our services first and only then passed on to customer networks behind our services. 

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 applicable partners for action. This is why we stress all traffic should flow through OmniNet and any circumventions 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

Please review relevant installation guides for each of these hardware types.  This is only a high level summary.

(A) OmniBridges

(B) Cloud-Links

(C) BYOG

 

A) Standard OmniBridge deployment

<-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.

 

B) Standard Cloud-link deployment

<-Modem/ISP hardware(Wifi off)-><-Cloud-Link-><-Internal network->(all client devices)

Recommended setup should have the Cloud-link sitting on the network edge (connected directly to modem). Nothing else should be connected to modem.

 

C) Standard BYOG deployment

<-Modem/ISP hardware(Wifi off)-><-BYOG with OmniNet Tunnel enabled-><-Internal network->(all client devices)

Each BYOG model has recommend configuration steps and is out of scope of this article.  However, its worth noting each BYOG should be kept up to date with the latest firmware and should be properly managed by the partner to ensure optimal security.  Partner should subscribe to vulnerability bulletins for applicable vendors.  In this design, OmniNet is not able to update firmware, whereas it is with OmniBridges and Cloud-links we are. Also, since partners have the freedom to update this self managed BYOGs, partners should regularly review configuration to make sure non-recommended configuration changes have not been made after initial implementation.

Recommended setup should have the BYOG sitting on the network edge (connected directly to modem) and have BYOG tunnel running at all times. Nothing else should be connected directly to the modem.

 

Partner: "I have deviations from above topology, are other deployments okay?"

If your customer's network has other routing devices that on their network, they should not be...

A) In line - in front of a Cloud-link, 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 connect for some reason, now what?"

Place it behind MDS 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 may 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 modems, or other wireless networks that are not sitting behind MDS.

- Make sure your customers security is on and content filter is enabled to get you the best protection.

- Reminding you that a quick run of shieldtest.com makes sure the client is surfing through clean internet provided by OmniNet.

Have more questions? Submit a request
Powered by Zendesk