Minimal SSIDs

[KevinR99]

Hi

I'm looking for some advice on what is currently in place at your sites regarding keeping the SSID count to a minimum.  We have Cat9800's and ISE but various types of SSID to cater for many different needs and end device capabilities.  What types of SSID authentication do you deploy and how do you use ISE to keep the SSID count to a minimum while still keeping security for corporate devices as high as possible.

Currently we have a main SSID using certs and EAP-TLS.  We have a several PSK SSIDs for different vendor equipment and we have a couple of SSIDs anchored to a DMZ controller where they are just passed out to an ISP.

The plan would be to retain the EAP-TLS SSID only for corporate devices where their certs can be managed.  A guest SSID with one or more (if possible) types of portal.  How we would identify devices and direct them to different portals is a question that may not have a solution.  We then ideally want the PSK SSIDs to collapse int one but still allow different PSK's per vendor.  I think the cat9800's can do multiple PSK's on the same SSID and maybe we could do even more with ISE but it's identifying the device and how that would relate to a per device type PSK that I'm wondering about.

Really, the question is what is out there with regards to this type of issue in order to keep the SSID count down?

As always, thanks for your time and input.  Kev.

[Leo Laohoo]

---

@KevinR99 wrote:

We have a several PSK SSIDs for different vendor equipment

---

Health care is notorious for this.  We told vendors that this practice is not tolerated and they need to show proof that their equipment must use a "special" SSID.  

We have an SSID with iPSK and we get ISE to manage a myriad of vendor accounts.  

It can be done but the most important thing is vendor needs to be dragged in, kicking-n-screaming.

[KevinR99]

Thanks Leo.  You read between my lines there.  This is a healthcare environment too.

So many different devices and reluctance to change anything on them.

Regards, Kev.

[Leo Laohoo]

---

@KevinR99 wrote:

This is a healthcare environment too.

---

I will let you in a secret:  The reason why we were successful in getting the number of our SSIDs down, from 11 to 6, was because the CTO/CIO was very supportive to what we asked/pleaded for.  

We waved his mandate to every vendor's nose and force them, kicking-n-screaming, to the table.  For obvious reasons, they came up with some of the most well used reasons why they should not reconfigure their products to OUR specific SSIDs.  The most commonly used is:  We have sold gazillions of these pieces-of-sh1t to trillions of companies in this side of the galaxy.  Why should we listen to you?  

We had, for example, an RTLS tag vendor who claims that their product can do 802.11a/b/n and high data rates (12 Mbps and above).  So we got them into a "isolation chamber" (a room with thick concrete walls with partition).  The product could not even associate to our SSID.  Within a few minutes we found out that the tags require 1 Mbps to associate to an SSID before "ramping" to the high data rates.  We submitted our discoverey and politely asked them if they can update the firmware and they responded with "What for?  The product works well with other hospitals.  Why are you special?"  The scheduled week-long demo ended right then and there.  

About 40 months later, the same vendor returned.  Same RTLS tag.  Same model.  Different "attitude" and, most importantly, different firmware in the RTLS tag.  

[KevinR99]

Leo

This is great info.  So it's not just here you get medical device suppliers playing hard ball and demanding things.  Or the healthcare provider reluctant to engage with the device supplier because of the cost and they get bullied by the suppliers.  The device is working and they are reluctant to make a change.

So, instead they demand extra SSIDs with weak security and then create the problem they are supposedly trying to avoid.  Device performance and vulnerability.

Extra SSIDs should be the very rare exception and require a full justification as to why it's needed and why they can't support a different method.

Thanks for the input all, Kev.

[KevinR99]

Purely as a test I tried to create 2 different profiles on a Cat9800 but both with the same SSID name.  I expected this to be rejected but it was accepted.  See attachment.

On one Profile I did iPSK and on the other PEAP.  However, I couldn't reliably join the single SSID that my end device saw.

What I noticed was when each profile was enabled individually they had different BSSIDs.  So is this essentially me advertising 2 SSIDs, with the inherent overheads of that, but with the same name?

When I had both profiles enabled sometimes I got asked for a PSK and sometimes for a username/password so it would seem.

The test was really to see if I could advertise one SSID and get ISE to sort out the different types of clients.  I suppose it allowed me to create 2 profiles with the same SSID name because you would be able to advertise each one on different AP's out of reach of each other and essentially have different security methods.  However, on the same AP this is no use.

[Leo Laohoo]

---

@KevinR99 wrote:

So it's not just here you get medical device suppliers playing hard ball and demanding things.  Or the healthcare provider reluctant to engage with the device supplier because of the cost and they get bullied by the suppliers.  The device is working and they are reluctant to make a change.

---

Vendors always play "hardball" because they have "inside knowledge" that they will get the contract regardless what you want/say/do.

(Petya and Wannacry happened not too long ago.  The poor security practice and reluctance to provide an update by the medical equipment manufacturers were the main reason why these two viruses had significantly impact.  These manufacturers were very lucky the authors of these viruses did not trigger them in America otherwise had any one of the two were set loose in America, the medical equipment manufacturers would be facing a hefty lawsuit for decades to come.)

[Flavio Miranda]

Hi

 I used to manage an infrastructure where we kept 4 SSID accross the sites and some places 3. We had a Corp with TLS, a Guest with portal on ISE and Mobile with TLS as well. For some places specifically we had to add one more for DEVs.

  But it is up to each environment. Something I almost had the chance to test is fabric wifi when I´d use two kinds of SSID: TLS and portal.

Based on the SGT reveived by the device either it would be sent to ISE to validate the certificate or redirect to the portal. From the onboard perspective all device would be the same thing and only after the SGT, the authentication would take place.

  I deployed the fabric wifi with 9800 WLC but for many reason we had to keep all the SSID untouched.

[Arshad Safrulla]

What we do to keep the SSID counts low

1. Advertise SSID per AP. Select the AP where that SSID is reqd and advertise there only. For example Guest SSID can be disabled on critical areas.

2. Use dynamic VLAN assignment (radius, ipsk, mpsk etc.)

3. Consider any non-corporate owned devices as guest network and direct them to guest ssid if your security policy allows. If not amend the security policy highlighting the risk. You can do a risk assessment to exclude if you need any exemptions.