03 Feb The SS7 Network needs its own Secured Borders
Anam CTO, John Murtagh, contemplates gaps in SS7 Security
I started my career in Telecommunications almost 30 years ago as a software engineer working on the design and development of the SS7 subsystem for the Siemens EWSD digital switch used in fixed-line and GSM mobile networks. It was the very early days of the SS7 protocol, which was establishing itself as the first truly international standard for inter-system signalling between telecommunication network nodes. In those days, versions of the SS7 standard were organized into “coloured books” – I initially worked on the Red Book published in 1984. As I was the only English speaker in the SS7 department, one of my main tasks was to understand and interpret the various clauses of the protocol specifications, which in typical ITU manner, were precisely written to a minute level of detail.
SS7 is a fantastic and very sturdy protocol for mobile network signalling control. The layers are well-defined with exact procedures dealing with redundancy, robustness, alternate routing, load-sharing all designed in from the start. Regarding the 3GPP defined GSM/UMTS/LTE networks, the underlying SS7 protocol stacks layers are MTP (layers 1-3), SCCP (layer 4) and TCAP (remote procedure call layer). These layers underpin the different “application layers” namely the Mobile Application Part (MAP) and CAMEL Application Part; CAMEL is s the abbreviation Customized Applications for Mobile Enhanced Logic, which is essentially a framework used for intelligent network services (e.g. Real-Time Charging while roaming).
I have remained involved with SS7 ever since and reflecting on the history of the SS7 standard, I do not remember any clauses or sections of the specifications dealing with security issues from those times. In light of the well published threats to mobile networks relating to SS7 vulnerabilities, I decided to make sure that my memory was indeed correct. On analysing the latest release of all the protocol specifications up to TCAP application layer, I made a search for presence of typical security-related words such as “encrypt”, “authenticate”, etc. Apart from an optional section in MTP dealing with bilateral links between different SS7 networks, the specifications are glaringly void of typical security terms. One may well remark that GSM MAP application layer does define security related nodes and related procedures such as AuC (Authentication Centre) and EIR (Equipment Identity Register), however it is the lack of security in the underpinning protocol layers which is at issue here.
The recently published “SS7” holes in the GSM/UMTS networks are indeed very serious – unauthorized and undetected intercept of voice, data and SMS communications, street-level location tracking, exposure of the encryption keys used on the air-interface, denial of service attacks amongst others. No doubt, governments are bringing pressure upon the mobile network operators as evidenced by US Congress . I also know of some European operators that are currently in discussions with government agencies regarding these security threats.
Similar to the response to the events of 9/11, the mobile network operators need to react swiftly to secure their network (SS7) borders to protect their subscribers, whilst also allowing the movement of genuine visitors (roamers) and interconnect traffic across these secured borders.
However notwithstanding the many good qualities of SS7 around robustness and resilient routing, it is unfortunately not possible nor is it pragmatic to design or retrofit security into the SS7 transport protocols – such a process even when defined would take years to implement and result in an enormous amount of disruption. Redesigning the network to use IP-related security (e.g. IPsec, TLS) is also not a practical option. Thus other approaches will be needed.
In my opinion the only practical approach is to introduce SS7 Firewalls at the network borders to closely monitor and detect any fraudulent activity traversing said borders. A sophisticated SS7 Firewall will act as a ring of steel blocking fraudulent attacks in real time. Fortunately some element of SS7 firewalling has already being deployed (as SMS Firewalls) in the mobile networks to counteract SMS (SMS messages are carried over SS7 transport) fraud and spam (it is estimated that approximately 50% of network operators today have deployed an SMS Firewall). A common and key technique of SMS Firewalls is “Home Routing”, (incidentally invented by Anam in 2004) which ensures the protection of the key sensitive subscriber identity known as the IMSI as well as the network node addresses (these addresses are known as GT addresses which are allocated from the E.164 telephone numbering blocks assigned to an MNO) serving the subscriber. Firewalling SMS alone is not enough, as in all of the recently publicised attacks the IMSI identity has been learned as a result of it being exposed across the network border.
It is my view that other detection and protection techniques supplemental to Home Routing are now necessary in an Firewall in order to achieve that “ring of steel” for the signalling network border, given that fraudsters will constantly attempt to expose weaknesses, for example to initiate Denial of Service as well as Brute force attacks. The SS7 firewall design challenge is to protect against vulnerabilities whilst at the same time allowing the network to support genuine roaming and interconnect traffic flows. . In addition to the firewall technology itself, a high degree of SS7 knowledge is crucial to the SS7 firewall deployment design to avoid unnecessary and disruptive changes to other network nodes as well as to peer networks.
Unlike IP, SS7 is only understood by very few people and companies worldwide. The above-mentioned techniques developed for SS7 Firewalling will require this expertise to be harnessed. The quicker the industry can work together to achieve this will ensure that this fantastic mobile network for global P2P and M2M communications will continue as a trusted media for all citizens.
John Murtagh
CTO of Anam Technologies
3rd February 2015