Sergey Nivens - Fotolia
What is the best strategy for patch management within telecom infrastructures? What are the challenges for this...
kind of patching?
As with many priority systems, patching can become an arduous, and even political battle within an enterprise. These priority systems can be deemed so critical by the organization that patching them is viewed as a risk to the business, which is counter-intuitive when thinking from a security standpoint. This is normally the case when these systems run on outdated or legacy operating systems where installing patches would either void a support agreement or where the organization doesn't have the funds or architecture to test the patches' functionality in a QA environment.
Telecom infrastructures commonly fall within this patching adversity. However, there are a few things that can be done to assist with patching; though, many times, this will still be a political and funding conversation in the long run.
It's very possible the patching conversation was started by a vulnerability scan or the security and compliance teams reviewing outdated patches on flagged systems. This is commonly done within enterprises to uphold the company's security posture and to validate that the company is meeting all the regulations to which the business might be required to adhere. The issue then becomes how to patch the systems.
Many times, systems can't be patched because the operating system or application is so old it can't take the patch, or the business owners are too concerned that the system will go down when the patch is installed. If this happens, support will need to be called and, in many instances, patching these systems without consent can lead to a breach of contract or support. There are a few options at this point, and most require some type of funding to achieve an upgrade or compensating control.
Frequently, telecom infrastructures require some type of on-premises presence, and can't be completely outsourced to the cloud. This also means you might be at the mercy of a provider not updating the software or limiting what can be done with your on-premises equipment. It's possible you're running the latest version of the application, but that it's on end-of-life hardware and operating systems. These systems can also be extremely expensive to update, which can lead the business to shy away from patches.
If systems can't be patched out of fear of downtime, it would be wise to set up a testing environment for the telecom architecture that will give you an understanding of how the patch will react after it's installed. This works to an extent, but without the testing environment being completely integrated into other apps -- such as the call center, help desk and others -- it won't be a true test; but it's still helpful.
Patching and then failing over to a disaster recovery instance of the telecom architecture would validate the functionally of the telecom infrastructure in the most thorough manner. What matters in testing is having something that mimics or is as close to production as possible.
If businesses can't update to the latest versions of the software and they don't have a testing or disaster recovery setup to validate the patches being released, then they have no other option to review compensating controls. These controls can be anything, including setting up additional logging on the systems to look for malicious activity, applying software to assist with virtually patching the risks, implementing or tightening network segmentation, and locking down access to the system via role-based access control and firewall rules. If these highly critical systems can't be patched, they need to have additional security measures put in place to reduce the risk of exploitation.
Many of these recommendations are just good security, but unpatched systems need to be reviewed and monitored to protect the integrity of your security posture.
This doesn't apply to all telecom infrastructures, but it has been an issue in the past with applications put in place years prior that are still functioning properly without a business need to have a functional update. We need to get past the "if it ain't broke, don't fix it" mentality and understand that, by allowing unpatchable systems within our network, we're putting ourselves at risk.
Ask the expert:
Want to ask Matt Pascucci a question about security? Submit your question now via email. (All questions are anonymous.)
How SDN, NFV, IoT and 5G are driving the networks of the future
Read an introduction to automated patch management software
Find out how cloud patching can address the VENOM vulnerability in enterprises
Dig Deeper on Microsoft Patch Tuesday and patch management
Related Q&A from Matthew Pascucci
Understanding the differences between sandboxes vs. containers for security can help companies determine which best suits their particular use cases. Continue Reading
Troubleshooting VPN session timeout and lockout issues should focus first on isolating where the root of the problem lies -- be it the internet ... Continue Reading
What sets web roles and worker roles apart in Microsoft's Azure Cloud Services? Here's a look at how they are different. Continue Reading