Q
Problem solve Get help with specific problems with your technologies, process and projects.

Why is patching telecom infrastructures such a challenge?

Patching telecom infrastructures presents many challenges. Expert Matthew Pascucci explains those challenges and what can be done to make sure the systems get patched anyway.

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.)

Next Steps

Check out five tips for creating a patch management strategy

Read an introduction to automated patch management software

Find out how cloud patching can address the VENOM vulnerability in enterprises

This was last published in May 2017

Dig Deeper on Microsoft Patch Tuesday and patch management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How would you go about patching telecom systems?
Cancel

Thank you for presenting this article.

I believe that I missed the point of telecom in the text.  The basis of the patching issue is universal to all critical components and not specific to any industry.

Patching that is not driven by knee-jerk responses is always based on a fundamental risk assessment.  If a cyberattack will disable critical infrastructure, then the DHS and supporting ISAO will have something to say about the criticality of performing the activity.  Plus, the local governance drivers may chime in on revenue and public exposure (press) concerns.

It would be nice to see a realistic tabletop exercise presentation with real-world concerns presented to add a bit of firmament to the pros and cons of go/no go selection.

Again, thanks for the article.


Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close