EMEA contributor Gary Newbold Regional Director Northern Europe, Extreme Networks
Shadow IT is a multifaceted challenge, requiring high-level policy decisions. Then IT’s surest ally is a network that implements those policies, says Manny Gutierrez, systems engineer from Extreme Networks
BYOD is currently a hot topic, but it is only one major part of the broader Shadow IT challenge. For Shadow IT – where business users implement a solution outside the official corporate architecture without consulting the IT department – can include everything from the use of free online services to departmental decisions to adopt SaaS solutions, let alone the actual importing of users’ own hardware devices.
With so many forms of Shadow IT comes a proportionate range of challenges. These include compatibility between devices and software – even if the same software is used, not every user is as diligent at upgrading to the latest version. Then there are legal issues: who is to blame if unregistered software is detected in the organization? Then, of course, the sheer technical and security challenges of managing a network when you cannot control the applications and devices it connects.
There is no single silver bullet to solve a problem as complex as Shadow IT. It requires not only carefully considered policies to be established and consistently applied across the organization, it also needs constant vigilance to keep those policies up to date with a fast evolving ecosystem of devices, applications and user behavior.
How is the IT department expected to manage and enforce all this, while still carrying out its bread and butter role of maintaining the network and delivering reliable and effective IT services? Lean too heavily towards the nay-saying policing role, and IT’s dictates will be seen by users as oppressive measures to be worked around rather than respected. After all, the prime driver for Shadow IT is the desire to do one’s job effectively and to use whatever tools can help – so an IT Department that forbids this is no-one’s friend.
Policy-based networking offers a very useful solution to this dilemma, as it builds policies into the network operating system where they can be centrally managed and maintained up to date. The user is simply offered connectivity that consistently reflects company policy.
Instead of applying policies in the settings of a static OS or security desktop applications that don’t extend to myriad devices, the physical wired and wireless network can now be relied upon. This removes the burden from a specific piece of software and establishes policy enforcement at the network level, where it acts as a central gatekeeper and is not impacted by changing software or mobile devices – in fact it welcomes them and lays down the rules that IT requires.
The need for Policy Based Networking
The mobility of devices and personnel means that some of the trickiest Shadow IT challenges arise when outsiders enter the premises. If they are regular contract workers, then suitable policies can be established, but many less formal interactions can also occur.
Consider a meeting in a conference room when some invited guest wants to respond to a question and asks for their laptop or tablet to be connected to the Internet to access a file. Is this available wirelessly, via a guest SSID? Or is it a question of plugging into a wall socket?
With a typical selection of Ethernet sockets, which one offers a quarantined Internet link without compromising the corporate network? After all, the innocent-seeming guest might just be an investigative journalist, industrial spy or simply someone who loves exploring forbidden territory.
Typically, those wall sockets will connect to different ports on a switch that has been partitioned to provide different levels of access, with spare ports lying idle in case of future needs. Unless someone has labeled the plugs, there is no knowledge as to what access it will provide without a call to IT and a wait for a technician to arrive. Even if they are labeled, it does not prevent people from connecting where they should not.
In a Policy Based Network, however, there is no need to partition the switch and waste resources: every port can offer similar connectivity across the organization. Access to network resources is permitted based on the users identity A guest who connects physically or wirelessly to the network is identified as such by their lack of authentication or by logging in using guest credentials or using their Linkedin, Facebook or other third party authentication service. Connectivity is then restricted strictly to the Internet, with no access to corporate data.
In the example above, the guest gets Internet access securely and without delay – so what about the other people in the meeting, those who do have the right to access areas of the corporate network? When they connect and authenticate to the network , wirelessly or wired they will be given exactly the access that they are allowed based on their identity . In both case the network access policies lie in the network itself.
Note that these policies can take into account and adjust access according to a range of factors: the person logging on, the device they are using, their location in or outside the building and the applications they want to use. Of course a Finance Director should be able to access all financial data, but if the request comes on a cell-phone from outside the building, it could well be malicious. Mobility demands much more granular network access policies taking such factors into account, and legacy networks cannot meet this need.
Once the end user device OS ceases to be the policy keeper, new attributes and variables can used to regain control. The policy-aware network can respond to any number of factors, from user log in credentials, to the MAC addresses of individual devices, to IP addresses and other characteristics.
A Policy Based Network in practice
What typically happens when a user in an organization turns on their computer? Assuming the switch has been correctly configured for that IP address, it connects the user device to the network in order to access the backend server that asks for authentication via a log-on screen. Once authenticated, the user will be given further access as allowed.
In a Policy Based Network the switch ports do not necessarily need to be partitioned into subnetworks,. When a device is plugged in or powered up limited access to the network is granted in order to get an IP address, resolve host and URL addresses and possibly access the Internet.This provides an immediate front-end security advantage – nothing accesses the network until some appropriate form of authentication has been provided.
Note that is not only more flexible in that all connection points are now the same, but also the access provided will be appropriate to the device being connected. So a recognized VoIP phone – wherever it is connected – will be configured and allowed QoS appropriate for transmitting speech; or, if it is a security camera, it will be allowed bandwidth appropriate to video transmission.
What happens in the case of a WiFi connection? Typically the WiFi network is an add-on with its own independent authentication and access parameters to take account of mobility factors and a roaming population. In a Policy Based Network, however, the wireless access points play the same role as the switch described above: no access to the network is given until appropriate authentication has taken place, and then the access will be shaped according to the organization’s policies.
In either case, if the connecting party is a guest with no formal rights then, according to company policy, they may simply find they have gained access to the Internet but not to any part of the company network.
The same thing applies to the employee who happens to bring their iPhone to the office. If company policy allows BYOD, they can enjoy seamless Internet connection for their phone without any need to log on. But again, policy might cap the bandwidth such devices in order to save the network from being degraded by the downloading of games and hi-definition movies – or maybe certain websites will be blocked from access.
Conclusion – is this the answer?
So, is a Policy Based Network the end of all Shadow IT problems?
Of course not. Shadow IT is a complex and fast evolving challenge and the first priority is to develop policies to deal with it that are appropriate to the way your organization works. As with IT security, an appropriate policy is one that not only provides the right level of stability and manageability, but also allows people to do what they need to do for optimal business.
Given company policies approaching that ideal, then it makes a lot of sense to build those policies into the network in the manner described – especially as it retains full flexibility to update those policies centrally across the whole organization.
This is achieved not by a forklift upgrade of the whole network, nor by adding a lot of extra boxes, but simply by using switches that take intelligence to the network edge, sharing a common operating system designed specifically to support Policy Based Networking. This does a great deal to simplify the challenges of mobility and BYOD; it can to some extent help to police rogue application usage – maybe linking switches with an Intruder Prevention System as well as the authentication server – but it can only achieve as much as corporate policies and ingenuity will allow.
The IT Department is now relieved of the need to play the heavy handed policing role, because the network itself not only determines the level of access but also serves legitimate users well by providing simpler, more flexible connection.
While not the ultimate solution, Policy Based Networking makes light of these shadows. It really is the best way forward.