While home and remote working is accepted as a regular practice, the speed at which society has embraced it creates numerous security challenges, even after the experience of COVID-19 and rapid adoption.
By Dave Cartwright, CISSP
Thanks to COVID-19, home working is far more normal than it was three years ago - and there’s no reason that home workers and the systems they use can’t be secure. However, introducing home working into your HR and IT regimes brings security challenges that you might not initially think of. In this feature I’ll look at some of the challenges I faced when everyone was suddenly sent home – and which you’ll need to consider if you’re embarking on a regime of making home working more normal now and in the future.
If the majority of your infrastructure is in the cloud, incidentally, you’re off to a flying start. Much of the challenge with home working is where you have on-premise systems that users’ devices connect to over the LAN but which aren’t easily (if at all) via the internet. The cloud isn’t a silver bullet that makes everything instantly accessible, but it does give you a head start as everything sits outside of the ring of the physical network and is already engineered for connections via the internet (albeit probably only from your offices’ pre-determined fixed IP ranges) so making it available to home users is a little easier, but not without its challenges. Nonetheless, the challenges are not insurmountable.
Defending Against Malware
First on the list of difficulty comes anti-malware software. If you have an enterprise-class malware protection package, you’ll have a central control/reporting server to which the users’ devices connect to get updates and report infections. If that’s on-premise, you’ll need to find a way to handle both functions. Sorting out the updates is easy in principle – just get the users’ PCs to connect to the AV vendor’s update server rather than your own – but it’s a sub-optimal solution because by doing so you just lost visibility and control for those devices from the central server. Generally, you can address the issue by implementing an internet-visible version of the control server in your DMZ – it’s not rocket science, but it will take some knowledge.
Hot on the heels of anti-malware comes the other elephant in the room: patching. LAN-based patching servers bring efficiency (the patches are downloaded once from the vendor’s site – for example Microsoft – and then disseminated to the client devices over the LAN). Again, if you’re sending people home to work then you can configure the devices to update from the vendor’s site directly, but as with the anti-malware issue we just looked at, you have a similar problem of losing visibility and control. Can you be sure that all your devices are patched? And when the time comes, what are you going to tell the auditors when they ask to see your patch logs? When COVID-19 was at its height they would generally cut you some slack, but those days are now behind us. Logs and records need to be maintained.
The list goes on. In a general IT sense, if a user has an IT problem you can’t just assume that whatever software you used to remote-control their PCs to fix things will work when the devices are outside of the firewall and the physical LAN. So again, you’ll have either to deploy something in the DMZ or adopt a new solution (probably a cloud-based one) that doesn’t care whether the client device is on the LAN or the internet.
Everything Everywhere
How do we make our security world agnostic to whether a user is working in the office or at home? (Or, for that matter, in a hotel on some sunny island). Making systems accessible from anywhere brings productivity boosts: while we definitely don’t advocate making people work when they’re on leave, if people want to dip into their email and stay on top of things then why not let them? And there’s an additional benefit in the form of disaster recovery: if people can work from anywhere, it makes life far more flexible if the office burns down or becomes otherwise unusable.
Aside from deploying everything to the cloud (which is great if you’re a new company that has built everything in the cloud from the outset, but harder if you’re largely on-premise with legacy systems) there are a couple of ways you can go.
The easiest of the two options to secure is to implement virtual desktops. All your applications live on a central core of servers, and users connect in using a virtual desktop client on their devices. The benefits are enormous: patching is a breeze because each Patch Tuesday you patch the “gold master” desktop image and deploy it to the server farm, and because everything is within your server farm you have none of the qualms of user devices based out of the office or otherwise out of reach. From a security point of view the user simply has a “window” into the virtual desktop – you can’t copy files out of the network or introduce malware into it from the users’ machines – and so you can allow them to connect from any device they wish with no worries of cross-infection. The downsides are that: (a) you need a certain amount of specialist knowledge so there will at the very least be a training requirement; and (b) it’s not cheap to deploy a load of new server hardware and virtual desktop licenses. Oh, and of course, I know you would never contemplate deploying such a solution without Multi-Factor Authentication (MFA) in place to make it as hard as possible for unauthorized users to gain access.
The Resurgence of VPNs
Plan B, if you need your users to be able to work where there’s no internet connectivity (and hence no way to access your virtual desktops) such as on a plane or in remote field locations, is to implement a Virtual Private Network (VPN) solution. Its tried and trusted technology that will allow your company-owned laptops (I know organizations that allow users’ own devices to connect to their back-end systems via VPN, but this is a recipe for disaster) to connect to systems as if they were sat on the LAN. There are plenty of solutions, and the same caveat applies to all of them: you must operate a mechanism of admission control that refuses to allow a VPN connection from anything that: (a) isn’t company owned and managed; (b) isn’t patched up to date; or (c) doesn’t have the latest anti-malware software and signatures. This option is technically more straightforward to deploy, and it has some challenges. If you use a connect-on-demand VPN solution, which can include the MFA stage, then by default you have to rely on your users to connect regularly in order to download patches, check in with the anti-malware server, and the like. A more streamlined solution is to have an always-on VPN, and to do the MFA stage when the user logs in (for any device not on the LAN you absolutely must have MFA at some point), but this removes your ability to do admission control and so you’ll have to take the significant technical step of employing something like Microsoft InTune (other solutions are available) to manage the devices for you.
And whichever of the options you choose, there’s one final consideration – which is almost completely non-technical. And that’s one of policy. One of the questions I was asked most by colleagues around the industry when COVID-19 hit was: how are you handling printing? Do you allow your users to print at home, and trust them to handle sensitive documents sensibly? Or do you take the opportunity to say: we’re going to give people the convenience of working at home, but there are things we can’t do.
For the technical security elements of home working, the answer is that it’s eminently doable, albeit that you need to design it carefully, spend money, and probably acquire skill. But while you’re doing all of this, you certainly need to consider the non-technical aspects too, because some of them might actually be harder.