Cloud Based Wireless Services - Some Thoughts About Security...


In this article, I present some of my thoughts around security of cloud-managed wireless solutions (which I am a massive fan of!). Hopefully the views here will be construed as constructive ideas that may prompt vendors to perhaps look more closely at their current implementations to perhaps feed in to product improvements.

I've been taking a close look at a some cloud-managed wireless solutions recently and they appear to be a very exciting area, providing a very compelling proposition for many organisations.

Remote access to manage your network from anywhere that you have an Internet connection is an incredibly powerful (and empowering) feature. As a consultant working for a vendor-neutral re-seller  the possibilities around remote support and managed services for my customers provide a whole new avenue of exciting opportunities.

However, after the initial buzz and excitement of playing with these solutions, I started to think long and hard about their security. Many of the concerns I hear expressed with any cloud service are around security (for fairly obvious reasons). Once you hand over responsibility to a 3rd party for a service that forms a critical part of your business function, the whole issue of who you really trust with your business assets rears its head.

For wireless cloud solutions the chief areas of concern (for me), with regards to their security are:
  1. Traffic between the on-premise components of your wireless network and the cloud - How secure is this traffic as it flows between on-premise components and cloud servers? This can apply to:

    • Management traffic
    • Control traffic (if the solution requires it)
    • User traffic (if the solution requires it)
  2. Cloud component security - How well secured are these elements?:

    • Physical access
    • Site/Server resilience
    • Network security (SSL Certs, OS patching, firewalls etc.)

  3. Reporting and statistical data access - Although no user traffic generally flows through the cloud, who has access to the (potentially commercially sensitive) reporting and statistical data that the system creates? 
  4. End-user administrative access control - What access controls are in place for those who have administrative access to the management of the solution (both customer and vendor)?
(Note: I'm not including the obvious and ever-present security of wireless end-user traffic here - that issue is not unique to cloud-based offerings and is readily solved existing WiFi (802.11) authentication and encryption methods)

I think/hope that most vendors have the first three points in this list pretty well covered off - trusting that all of these items are taken care of is fundamental in the selection process of a cloud-based service. The general assumptions are that:
  • Traffic to/from the cloud to the on-site kit will be encrypted using some type of robust encryption technique
  • Vendors have robust security infrastructure and processes in place (e.g. daily pen-testing, firewalls etc.) around their cloud infrastructure
  • Access to customer generated statistical data is protected by vendor mechanisms and processes
To be honest, there is little that can be done to verify these areas for the average end-user. I'm sure that many end-users will rely on the fact that a cloud provider is probably only going to get one of theses areas wrong once before a major part of their business is seriously or perhaps fatally damaged.

(Note: these are my own personal assumptions - if you are a military or government-related organization, I accept that you may not be quite so trusting when it comes to cloud based services.)

So, assuming that the cloud provider has (securely) taken care of the elements over which they exercise total control, that leaves us with the fourth item from our list above: end-user and vendor administrative control of the cloud-based wireless service. 

Once the end-user (customer) has purchased their equipment and the accompanying subscription licenses, they are going to want to access their new cloud-based wireless network and excitedly show their colleagues this cool, new platform. To access their cloud service they'll fire up their browser and type in the user name and password that they have been provided by their cloud vendor. If they are a particularly diligent employee, they'll hopefully also change their login password to make sure they are observing good security practice and not using the default password that has been issued to them. Once their credentials are entered, they will then have access to manage all of the devices for their organization that are part of the cloud-based service. 

(I've only spoken about wireless devices so far, but it's worth noting that many wireless vendors are now moving in to edge switches and security appliances too, providing even more penetration in to an organization's infrastructure.)

But, just taking a step back, let's have a think about what's going on here. An organisation is allowing an individual access and control of their network infrastructure from anywhere in the world, based on a simple username/password combination.  OK, the credentials will be sent over SSL encrypted connections and the user will hopefully use a nice long complicated password, but there is still no way of proving that this individual, who has unfettered access to key business systems, is who they say they are....

Consider the following:
  • Laptops and mobile devices (perhaps containing password information) get stolen and lost
  • People, who should know better, write account details on post-it notes
  • Employees short-cut security by sharing credentials
  • People often use the same username/password credentials across a number of online sites and systems, some of which may become compromised
  • Social engineering attacks may be mounted against an organization. 
There are, unfortunately, many methods by which simple username/password credentials may fall in to the wrong hands.

In my opinion, a simple username/password combination is simply not enough when allowing ubiquitous access to network systems via a cloud service. Administrative access must be protected by some technique that also confirms that the user is who they purport to be.  This technique may include a user certificate or perhaps a two-factor authentication method, but this should method should be the default security access policy for a cloud service. 

Unfortunately, many users tend to use the default settings of many systems, either believing them to be sufficient from a security point of view, or through simple laziness. Unless a robust default is provided as a default, many will not take advantage of more secure options, even if they are provided.

Although a two factor authentication mechanism may seem a little onerous (if considering the logistical complexity of traditional fob-based hardware tokens), the wide-spread use of mobile devices by many employees would seem to naturally lend itself to some type of app-based authentication system to facilitate this fairly readily without too much additional investment by vendors.

There will doubtless still be end-users still refuse to buy-in to this level of secured access to administer their network, therefore an option to fall-back to the standard username/password combination must still be provided. But, this should only be allowed after being explicitly requested by an end-user organization and should perhaps accompanied by strong warnings around liability in the event of unauthorised network access.

If a customer should choose to disable the default two-factor authentication (or similar user-identity verification system), then comprehensive policy enforcement for end-user administrative access must still be provided. This should provide extensive features for maximum user security enforcement, including:
  • Password length & complexity policies (e.g. minimum numbers & types of character)
  • Password re-use polices (e.g. not allow previously used passwords of their variants)
  • Period password changes policies (e.g. enforce password change every month)
  • Source geographic regions and/or IP addresses ranges exclusion or inclusion (e.g. do not allow access from unexpected countries)
  • Configurable Session timeouts (e.g. force login every 30 minutes in case terminal left unattended)
  • Account lock-out to prevent brute force attacks (e.g. lock an account and generate an event after 5 failed login attempts)
Having looked at some existing cloud-based offerings, they comply with the points outlined above to varying degrees. But, given the seriousness of impact in a breach in this area, I think it is an area that all wireless cloud vendors need to take a very careful look at. None currently (to my knowledge) provide a default authentication system for administrative users that can identify a user beyond their basic username and password. I do not believe this is good enough. The strongest possible authentication should be the default, with any other methods being actively discouraged and requiring a customer to acknowlede that they understand the impact of reduced security for access to their service.

Attacks on online services will generally start on the weakest link in a system. From what I have seen so far, the weakest link in wireless cloud services is the authentication of administrative users to those services. I think that any vendors that do not impose stringent security mechanisms in this area are taking a significant risk and urgently need to address this. 

End-users often do not employ the most secure practices - in the case of cloud based services, vendors need to protect end-users from themselves and to safeguard their own reputation. Also, for those resellers and partners who wish to provide services around these offerings, they need to have the confidence that they have robust security in-place to protect their own interests too.

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment