One of the problems with offering patch management services to your customers is distance. Even if your customer is next door, your customer probably isn't going to want you on site working with their servers every day. And if your customers don't have an issue with you being in their office all the time, as your business grows you will eventually be too busy (if you're not already) to visit each customer on a daily basis. As such, performing remote patching is the only practical way of running your business.
Of course remote patching has some problems of its own. Every customer's network is different, so how do you deliver, apply and verify patches remotely? Unfortunately, I can't give you a straight answer to that question. A patch management application that works for me might not meet your needs. As such, I'm going to refrain from recommending specific software. Instead, I'll use this article to guide you in creating an infrastructure that will allow you to successfully perform remote patch management.
Keeping remote systems patched isn't as difficult as it might at first sound. After all, large corporations do it every day. Think about it. Large companies often have a corporate office and numerous branch offices. These branch offices usually contain systems that need to be patched. You can therefore overcome the challenges of patching remote systems by paying attention to how large companies perform patching for their branch offices.
When large companies apply patches remotely to branch offices, they almost never target individual systems. Imagine what would happen if you needed to apply a 25 MB patch to an office with 50 computers. If you tried to send the patch individually to each system, you would have to transmit about 1250 MB worth of data. Even if you had all the bandwidth in the world available on your end, your customer probably wouldn't appreciate having their Internet connection tied up by patch related traffic.
To continue reading for free, register below or login
To read more you must become a member of SearchSecurityChannel.com
There is no need to send the same patch across the wire 50 times. A smarter solution is to place a server, used solely for patch management, on your customer's network. When you send out patches, you send them to the patch management server at your customer's site. That server is then responsible for distributing the patch across the customer's network.
There are a couple of advantages to this approach. The most obvious advantage is that the patch is only transmitted once across your customer's WAN link. This helps to conserve bandwidth.
A second advantage is that you don't have to worry about trying to communicate with each individual computer from across the Internet. Most workstations are configured to use dynamic IP addresses that are not directly accessible over the Internet. This makes direct remote communications with these workstations difficult at best. However, having workstations directly accessible through the Internet poses a serious security risk.
Typically, when you transmit patches to a server at your customer's office, it is the remote server's job to deliver, apply and verify patches on all other systems on the network. Usually this means that the other systems must run an agent specifically designed to communicate patch information to the distribution server. Because you can communicate directly with the distribution server from the outside, you should be able to access the information that the distribution server has collected, and use that information to monitor patch management within the remote organization.
Pretty much any enterprise patch management solution supports a hierarchical patch management server topology such as the one that I described. The one downside to using this technique is that it does require you to be able to communicate with a server on your customer's network. This almost always means that your customer will have to open at least one port on their firewall. You can count on most organizations being reluctant to open firewall ports because of perceived vulnerabilities. This means that it becomes your job to convince your customer that the benefits of ongoing patch management outweigh the risks associated with opening a firewall port.
There's no denying that applying patches to a remote network can be a little bit tricky. Hopefully though, I have given you some insight into some techniques that you can use to make remote patching practical.
About the author
Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien's personal Web site at www.brienposey.com.
