Navigating the Complexities: Telecom Signalling Firewalls

Josué Martins , CCSP recently listed "10 Limitations Of Telecom Signalling Firewalls" on Commsrisk . I personally found these so insightful that I can't help but share my thoughts on some of these points (but in an alternative order).

?? Few comments related to Signalling Firewalls functionality

?? JM: Signalling Firewalls have a Lack Of Cross Protocol Integration.

?? DK: I agree that this is necessary. According to ROCCO and their Signalling Firewall Market Impact Report 2023, such a feature is now available in many Signalling Firewalls today.

The real challenge is that in many networks where SS7 screening is performed by older STPs, making investment into 2G/3G protection is difficult. For cross-protocol correlation, MNOs need to have a single vendor for SS7, Diameter, GTP, etc., which is not always feasible. In such cases, at least the ability to integrate different solutions via API could help.

?? JM: Signalling Firewalls have Limited Modularity and are not flexible for APIs.

?? DK: Indeed, integration is critical but not always available. It seems like some vendors' greed and attempt to achieve lock-in works against declared openness. Good approach is to have your API available, be ready to work with other APIs, and onboard to SIEM – to be part of the cybersecurity process.

?? JM: Signalling Firewalls Lack the Stateful Protocol Inspection.

?? DK: Agree, this is essential and, to be fair, is available in some Signalling Firewalls. More to this, a good Firewall system should not only track specific protocol transactions but also:

?? Maintain a database of subscriber location changes to prevent Cat 3 attacks exploitation.

?? Perform analysis of network functions behavior to build profiles on Network elements to identify anomalies in the way they communicate with each other to prevent spoofing of trusted addresses and other attacks.

?? JM: Signalling Firewalls have Poor Reporting.

?? DK: Possibly true, especially for incumbent players with an old-school approach like 'CLI is enough for a good engineer' or 'We have a pragmatic 2000 GUI style'. However, times are changing. There are more user-friendly solutions with security analytics and reporting available.

However, the point about the requirement of deep knowledge of telecommunication protocols is only partially true, in my opinion, because the complexity and criticality of these technologies also drive the requirement for trained personnel. I'm not sure that the core network is a good place for a one-button solution.

?? JM: There are obstacles to Scalability, as Signaling firewalls still run on bare metal servers.

?? DK: Frankly, this point surprises me. All Signalling Firewalls, apart from legacy STPs and DEAs, are software solutions, and I haven’t seen any that cannot run as VMs. Once again, I can only reference the ROCCO list of vendors as an example.

?? And few comments related to maintenance

?? JM: Signalling Firewalls are too hard to Manage, take the Complexity of Rule Sets and Operational Modes as examples.

?? DK: I agree, this is an important topic and it relates to who the end-user is – the security engineer, or telecom engineer.

Vendors must do their best to simplify the management of the Signalling Firewall, but proper training is also mandatory: for telecom specialists in security and the nature of control plane attacks, for security specialists in 4G/5G networks, and the similarities and differences from IT security.

However, we should be realistic and not expect a network node in charge of passing or blocking the entire control plane traffic at the network border to be a one-button solution. It is too critical for stable network operations, so only trained personnel should be in charge of deployment and maintenance.

?? JM: Signalling Firewalls have Inadequate Monitoring, not integrated into SIEM.

?? DK: Yes, this happens quite frequently. The root cause, as I can guess, might be:

??Some MNOs may not be onboarding Core network nodes into SIEM systems in general.

??SIEM is a SOC tool, and SOC might not cover the Core networks, possibly because security teams are not yet allowed into it. Sometimes, the Core remains the sole responsibility of the NOC.

??Legacy STPs, DEAs/DRAs may not be flexible for syslog collection.

All these points are not good, and ideally, they should be resolved.

?? JM: Signalling Firewalls run Outdated System Software and have Poor Hardening Hygiene in place.

?? DK: I guess this may happen if the system is not properly maintained. We are talking about basics here, things like – Inventory, Updates and Patches, Change Management, Backups, Performance Monitoring, Documentation.

If this is not happening, the question is, why?

Probably, end-user priorities are focused elsewhere.

So these were my comments on Josué Martins’ "Top 10 Limitations Of Telecom Signalling Firewalls" article on Commrisk ??.

Thank you, Josué Martins , CCSP , very much for these points! I would really love to contribute to this dialogue, as there is nothing better than open discussion! ??

#TelecomSecurity #Cybersecurity #NetworkSecurity #SignallingFirewall #Telecommunications