5G Security Blog Series (Part 3): Different Day – Same Software, Network Snooping and Scams!
5G is no different from other mobile technologies. Same association between mobile device and user. 5G devices will still be in our pockets and bags wherever we go. They will still be the gateway via apps and messages to our online accounts. 5G mobile devices will still make and receive our calls. We have to assume that the similarity also holds true for the attackers and fraudsters using the networks. If a user is on 5G they will always be a desire to find a way to attack them, or complete a date intelligence mission. The similarities are not only on the threat side.
The telecom network software industry is less revolution and more evolution than you would think. 5G is a fresh start obviously, well no. That would be pretty much impossible. In reality, software reuse is the goal. If there is a proven protocol stack, database, OS or test tool available it will be used. This was the approach that I have taken time and time again. The benefits are speed to market, proven implementations of components, often the ability to consult with the original module development team and importantly all of those bugs and defects have been ironed out. But some of this code could be over 5 or 10 years old designed for different environments and even for a different target environment. Almost none of these stacks will take into consideration security aspects of the 5G environment. So if I use a protocol stack layered from 4 different existing modules, what do I miss? In a word, consistency. Meaning each layer is developed as a standalone component not knowing what protocol is layered above it, any consistency checking is left up to the higher protocol layers to implement, that is if the lower layer exposed the parameter to check. In reality people coding an application layer function don’t know or need to know the operation of the lower layer service module they link into their code. The result is that protocol layer consistency checks are not included.
One final point on software development and the practical limitations engineers face. Latency, memory and bandwidth. I remember being told by my product managers that there were 3 priorities for this release, performance, performance and performance. Every decision, loop, callout or write to log that you do, slows your code down. Every stateful store cache you keep for more time increases memory usage. Every cross network correlation you do burns up bandwidth. The results are speed of code and memory requirements and storage/bandwidth increases. Security functions almost always demand the opposite of this need. They require lots of calls to external services, policies and resources. They need historical information to be stored and easily retrieval for extended periods of time. They need information to be correlated network wide for entities that may not even be part of your network. It is nearly impossible to do both functional implementation and security in a single code base without it running poorly. One of my first engineering managers had a term for slow code, “It runs like a 3-legged pig on stilts.”
Security is a journey not a destination. What do I mean? The reason that most mobile networks are attacked is because there is inherent value for the attacker in doing it. Either they are harvesting information that can be resold, executing a mission for the sake of national security, setting up a more elaborate fraud like mTAN interception or they are locating something of value. My point is, that from the attacker’s perspective there is definitely something of value in those hills. For this reason, building a security feature into a standard is great. However that is not the scenario you need to protect against. It is when a new security vulnerability is discovered, how do you react, moreover how do you detect it? It takes constant vigilance and the security mind-set of looking for the needle in the haystack. Security attacks don’t jump out at you, they are not easy to detect. Even worse, if they are detected, the attackers normally know. They have test networks in place to know when an exploit is no longer viable. They then try something different until they achieve their goal. Now, do we think the same “things of value” will exist in 5G networks? Do we believe that there is more value in them-there-hills?
Yes! I think the answer is yes, healthcare devices, hospital records, autonomous vehicles, flood management sensors, agricultural sensors, banking transactions, governmental communications, documents, and more.
Back to my original question, is 5G secure? You can draw your own conclusions, but with the same players and approaches being used, the industry risking billions for licenses and infrastructure, with standards not yet completed, with companies fighting to be part of the service delivery path, and several times more complexity involved in 5G than anything we have seen before, we will inevitably need enhanced security capabilities.
My conclusion, is 5G out of the box secure? No.
Enea AdaptiveMobile Security continue to drive a pure security agenda through industry forums and in partnership with our customers. Our single goal is to develop and implement mobile security solutions that provide the protections our customers need. This is as true today for our current networks and technologies as it is for 5G and beyond.
I would ask Chief Security Officers to make their voice heard during the selection of vendors for 5G. Don’t be fooled for a time, the equipment vendors don’t have you covered.
Enea AdaptiveMobile Security experts Cathal McDaid (CTO) and Dr. Silke Holtmanns (Head of 5G Research) will break down some of the myths and share their industry knowledge on 5G core network security at our upcoming webinar on 16th of June. Registration will open shortly for the event.
Keep safe.
You may also want to read our post on the Future of Mobile Security.
