5G Security Blog Series (Part 2): The Engineer’s Perspective

Surely equipment vendors couldn’t be contemplating doing things the same way they did when the industry was launching 2G, 3G and 4G? Please tell me that they are not signing up contracts to deliver infrastructure while the standards are still in flux. In reality, the race to be the first, the fastest and to avoid those contract penalties will mean that poor security decisions will be made (again!).

From my experience, phase 1, get the network deployed and operational with internal users to allow the CEO-stage call to happen. (hopefully not involving unbreakable glass and a brick!) Phase 2, is to secretly re-architect phase 1 so that it can scale. Phase 3, is to meet the scale performance requirements. Historically, security has been lowered in priority during these initial phases. So we could be looking at phase 3 and 4 before security is really addressed. That is unless a major attack exposes a vulnerability that cannot be ignored.

Trust me when I say, it is a brave engineer, team leader or scrum master that says, you know I don’t think we should let this go out without the security features checking out. Contract deadlines, market firsts and revenues are king. Even more so in the post COVID-19 era. People of the world, we cannot leave the network security in 5G up to the equipment vendors, they ticked the security box in every generation of the mobile generation technologies from 2G to 4G yet we find ourselves knee deep in the lack of security they have left us to deal with. Security is often “expected for free” and if the “tick in the box” is made by the vendor, the operator fulfils their legal requirements but we know now the hazardous outcome of fulfilling minimum security requirements. I like the phrase, “Fool me once, shame on you! Fool me twice, shame on me!”. I am not sure how we extend that, or even want to extend it to say, fool me, erhmmm? Four times?

Even with the very minimum-security standards set and boxes ticked, the deployment, operation and configuration of the nodes in production will impact the security of the network as specifications are often “must implement” asks of a vendor in reality “optional to use” by operators. Operators must ensure they fund and maintain an expert security function or risk leaving the doors open to attackers seeking to access the rich data on 5G networks. Perhaps I am being a little harsh, it is no small effort in getting a new mobile network technology operational and robust. It is a full-time task. The same applies to securing the network, again it not a small ask and a full-time activity. I would say it’s similar to the child’s game of patting your head and rubbing your stomach whilst swapping arms every 15 seconds. For me at least, it’s impossible…

I do have a little insight into how this game is played out in the equipment vendors development and test teams, having led a system testing team in a previous life, before I turned to the dark side of marketing. The conversation with my director went like this. “Graeme, is the software ready to release?”. My reply, “Not quite yet during the exploratory testing we have crashed the software 17 times, I need to review with the engineering team.”, discussion with the engineering manager, “Graeme, I have reviewed the results and my engineers assure me that the software would never be used in that way, can you mark them all as no-fault-found, we need to get this release out ASAP”. And with the wave of a cigarette stained hand, all the security vulnerabilities are waved away. Note that the release of the software on time lead to bonus payments. Yeah! One of those test scenarios was for an externally initiated GSM MAP HLR Reset. Today we would call it a Category 1 Signalling Security Threat.

Add to this scenario, dropping profits and sales, delays in the 5G infrastructure rollout and handset availability and questions over the appetite over the coming years for people to want or afford the latest and greatest 5G ($1000 plus) devices?

From a purely engineering perspective, I do have sympathy for the guys trying to decipher truckloads of new 5G standards into an operational end-to-end system. It is honestly incredibly difficult to get the system running. Then to ask engineers to work out end-to-end how the system they are just getting their heads around, could be attacked and to make it secure? That engineer doesn’t exist, or at least in the 1000’s that will be needed to implement 5G solutions. It also isn’t a fair ask of an engineer working on a protocol module in a lab somewhere to be able to think like a nation state surveillance agency? Engineers in our industry are good, often great! But not that good…