Recently I was discussing a RAS solution with a customer who’s end users have a number of complaints about his current configuration. Over the course of the discussion we gradually arrived at the conclusion that the right solution would be to provision layer three VPNs to all corporate assets, rather than to force all users to a web-based portal page.
Everything seemed like it was falling into place until my customer asked, “Can we ensure that the end users must login to the VPN when they login to the machine, and that they cannot disable it?” I immediately asked him why he was interested in such a feature. Essentially, he wanted to ensure that his corporate devices were always protected under the umbrella of his security devices including his firewalls and his intrusion prevention systems.
While I understand the concerns regarding letting corporate assets out in the wilds of the internet, I immediately told him that he’d have a mutiny on his hands if he tried to enforce such a draconian policy. This kind of policy (even if it were possible – which thankfully it is not with our products) simply would not work for his users. Things would be worse than they are now.
As I write these words, I’m sitting on the tarmac in Phoenix Arizona. There is no wifi connection on the tarmac and I’d have no way to get connected to nail up a VPN. If a security policy like the one my customer described were enforced on my machine, I would be out of luck. It would mean no work until I can find a hotspot or an ethernet jack.
The request reveals a naive understanding of the use case for remote access VPN. For better or worse, the business world of 2011 is a highly connected, 24×7, global, and mobile culture. This means that it is imperative to have systems that are functional in a variety of environments. Business would grind to a halt if users couldn’t use their devices without being connected to the corporate mothership. The purpose of remote access is to enable users to access corporate resources while away from the office rather than as a controlling mechanism to ensure that users don’t expose their corporate devices to the internet.
In addition this request reveals a mindset of control. This mindset is all too common in the information security field where thought is dominated by controlling what users can and more importantly cannot do with their computers. The hope is that by controlling what users can and cannot do with their devices we might have a more secure network.
This mindset stands between the goals of corporate security team and the success of the business. All too often, security becomes the road block and holds back the enterprise often unnecessarily. I’m not advocating a completely lax security policy, but I am advocating a shift in the mindset of the security team.
This shift will require new skills of the IT Security department including the ability to listen to the business, the ability to think critically about the challenges presented, and the ability to be creative and meet the needs of the business while managing risk.
Security budgets are often among the first to be cut in the enterprise for a variety of reasons. One reason is because security departments have historically been the “Department of No”. The default response to innovative technology has been to deny access to it, usually without truly assessing the risk. This slows the business down, slowing growth and diminishing success.
If security teams wish to see their budgets grow rather than shrink it will be critical for them to embrace a mindset of enablement rather than a mindset of restrictive control. Only then will their efforts be seen as valuable and contributing to the success of the company.