Re-Assessing the Devices on your Guest Wireless Network...

Has your "Guest" Network become the defacto landing place for pseudo-production devices?

I shared an insightful discussion with a customer recently who mentioned that although their "Guest" Wireless LAN was deployed specifically for true Guests, that it has become the fastest path to deploy devices that:

1. Cannot perform 802.1X authentication
2. Do not belong to the organization or are otherwise unmanaged
3. Require Internet (or worse Internal) Network access for specific applications.

This particular customer happened to be in the Healthcare vertical, but I think these problems impact Enterprise and Educational customers in the same manner.

Guest Networking generally doesn't have the same "filtering" or access controls we deploy on our "internal" networks and in this case, the initial "exception" was for an application used for messaging on personally owned smartphones. This case only required Internet access, and luckily the IT team did their diligence and ensured that application-level encryption protected the data.

We see this frequently with devices for A/V, building controls such as HVAC, door locks and others being layered upon the "Guest" network.

Although this is common practice, there are some flaws and concerns we should all consider.

1. Guest networks are generally OPEN and unencrypted.

   Unless you can validate that the applications your allowing on these devices employ network level or above encryption, you should at least place them on a PSK network to ensure per-device keying.

2. Opening inbound holes for specific applications from the "Guest" VLAN is a risk.

Allowing inbound traffic to your HVAC system, or messaging/mail or other systems from the Guest VLAN is a risk that could be mitigated.

Rather than place these "exception" devices on the Guest Network, place them on at least a PSK network.

If they are "fixed" mobile devices, you can leverage per-AP or AP-Group Overrides to create a location-specfic SSID for a specific purpose, MAC lock the device, and place upon a secured VLAN with only the ACL access it needs to perform it's function.

We recently accomplished this for a customer with WLAN/Network connected door locks, and ensured that the "devices" on the doorlock-psk network could only communicate with the single-server that services the locking system.