cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Remote control: To self-host or not to self-host?

Level 11

Remote control software is a huge benefit to all IT staff when troubleshooting an issue. There are big benefits for using a service provider to host this functionality for you. There are many reasons, mainly security, to not use a service provider and instead host this application internally. However, internally hosting a remote control application can cost more in capital expenditure and overhead.

When you host something in the cloud you are giving that service provider responsibility for a significant portion of your security control. Even for something as simple as remote control software there are concerns about security. For many solutions you have to rely on the authentication mechanism the provider built, although some will allow you to tie authentication into your internal Active Directory. The provider may allow for two-factor authentication. You have to rely on the provider’s encryption mechanism and trust that all signaling (setup, control, and tear down) and data traffic is encrypted, along with the appropriate algorithms. The remote control service provider not only services your hosts, but that of many other organizations and you have trust them to keep everyone separated. Also, with all of those combined hosts, it makes the service provider a larger target for an attack than your organization may be on it’s own. When your organization’s Internet connection goes down you loose the ability to control any of your end hosts from the internal side of your organization’s network. When you delete an end host or discontinue service from the provider you data might not be completely deleted.

Hosting a remote control application within your own organization can be difficult in itself. You have to have the infrastructure to host the application. Then if you want redundancy, the application has to support redundancy and you have to have more infrastructure. Then you need to make sure you update the application on your server(s), on top of ensuring the end hosts are up to date, which requires planning, testing, and change control. If you expose your internal remote control application to the Internet, like a service provider would, then you need to monitor it for potential intrusions and attacks, and defend against those. That may require additional infrastructure and add complexity. If your organization’s Internet connection goes down and you are on the inside of your organization, then you loose connectivity to all of the remote hosts. If you are external, then you loose connectivity to all of the internal hosts.

There is no one solution that fits everyone’s needs. As a consultant I have seen many different solutions and have ones that I prefer. Do you use a remote control solution from a service provider or do you have one you host yourself? Why did your organization choose that one?

5 Comments
Level 17

We do much in house, while I do not manage it... someone does.

Level 15

We use an internal solution.  Being guared by regulation, the security concepts have been the biggest reason to keep applications out of the cloud.

Level 11

If you don't mind sharing, how many end hosts? Internal and external hosts? How often does it get patched? Do you have to update the clients with every update to the server?

Level 11

My biggest concern with 'cloud' solutions is how do you know that they haven't given someone else access to your data/systems. Also, when you delete something in the 'cloud', that application might delete it from their database, but if they are using cloud storage themselves, that data might not really be deleted from the underlying storage system.

Level 15

Yes that is some of the concerns that I too share.  I think we need to overhaul security before jumping into the clouds.  If the foundation links are secure, and the processes are secure, then maybe my confidence would grow.  

About the Author
I am a network and UC engineer for a mainly Cisco reseller. I have worked in the networking industry for about 14 years and started as a network administrator for a small CLEC (carrier) where I did it all in IT and worked on the carrier network. After the CLEC, I went to work for a large healthcare organization in the Houston area and stayed with them for about three and a half years. Now I work for a reseller in the professional services part of the organization. I am currently studying for the CCIE in Routing and Switching lab. You can find me on the Twitter @twidfeki or I blog on Packet Pushers and twidfeki.com.