Some wild claims have been made about 5G networking. I’ve heard mention of self-healing factories and smart highway systems. While such things might be possible, there’s nothing magical about 5G. In essence, it’s just faster wireless networking than we’ve had before. That’s nice, but hardly revolutionary.
In this blog post, I’ll provide some background about networking in general, and then talk about how 5G fits into the networking world. I’ll finish up by talking a little about how software security and networking intersect.
About networking
Networking is hard—it’s one of those subjects that has too much information available rather than too little. The networking world has so many protocols, so many options, and so many configurations that finding the information you want can be hard, especially for beginners.
Many introductions to networking start with the OSI seven-layer model, which you can find on Wikipedia. This is a comforting model for instructors, who can give quizzes on the names and functions of the different layers. And it’s a comforting model for students, because it clearly lays out a small, manageable body of information that can be internalized.
Unfortunately, it doesn’t correspond very well to how things actually work. For most network interactions, it’s impossible to identify all seven layers, and some protocols defy categorization.
If you must learn about seven layers, learn about this:
The concept of layers is useful
Although the specific seven layers of the OSI model aren’t tethered to reality, the concept of layers is useful. Each layer supports the layer above it. Another useful analogy is nesting dolls or envelopes within envelopes. If I want to send some information to the far side of the internet, I’ll put it in an IP packet addressed to the destination. Then I’ll wrap that up in an Ethernet frame with my gateway as the destination. Then I’ll drop that on the wire. The gateway picks it up and repackages it for the next hop in the cloud.
IP networking has a somewhat simplified set of layers, but again, it’s not a perfect model. Protocols like ARP and TLS don’t fit neatly into the model. The main thing to remember is that protocols always happen in layers, and typically different pieces of software are responsible for each layer.
Some layers are interchangeable
One of the best things about network layers is that it’s possible to change out layers without reprogramming everything in the world.
For example, the applications on your smartphone live in a world of IP networking, blissfully unaware of whether the IP traffic is carried over a Wi-Fi network or a cellular network. Your laptop is happy to use IP networking regardless of whether it travels over Wi-Fi or a wired Ethernet connection.
From that standpoint, then, 5G will hardly make a difference for many applications. Desktop or mobile applications that communicate over IP probably won’t even notice the difference. Is my device on a 4G connection? Wi-Fi? 5G? Does it matter?
Some applications will need the increased speed and capacity of 5G networks, but these will be outliers until the technology is more widely deployed and used.
How software security and networks intersect
Network protocols are sets of rules about how computers talk to each other. For example, the HTTP protocol lets browsers and web servers talk to each other to serve web pages to users.
In software security, network protocols are an important part of the attack surface of an application. The attack surface is the collection of all the places where the application takes input, each of which is an attack vector.
One of the fundamental problems of security is correctly handling input, so mapping out the attack surface and testing it properly is critically important. Because network protocols happen in layers, some of the networking code is probably code that you didn’t write.
For example, let’s say you’ve written a web application. Users (and attackers) provide input to your application using a web browser, so the full protocol stack for the deployed web application includes HTTP, probably TLS, TCP, and IP.
The code you wrote yourself handles only the application data. The other layers are handled by third-party code, probably open source components, as outlined here.
“That’s not our code” will not cut it
It’s often tempting to abdicate responsibility for third-party code, but such an approach is unwise. What if an airplane manufacturer didn’t take responsibility for the parts it buys from vendors?
A comprehensive approach to application security means managing the open source and third-party components you use to build and deploy your application. Software composition analysis (SCA) solutions automate much of the work of discovering which components you’re using and identifying the known vulnerabilities and license obligations that come along with those components.
In terms of testing the attack surface of your application, protocol fuzzing is time-proven technique for locating vulnerabilities by supplying malformed and unexpected inputs. It’s especially important to fuzz all layers as dictated by your application policy.
If you’re designing a web application for sharing cat pictures, you might decide that you have sufficient confidence in the Linux kernel, the openssl project, and the Apache web server that you don’t need to perform your own fuzz testing on them.
If you’re designing a web application for protecting nuclear launch codes, you need a much higher level of assurance and will almost certainly want to perform your own fuzzing on all layers of the network protocol stack.
Secure your network with application security testing
A comprehensive approach to security is vital to every phase of application development. Automated application security testing (AST) helps development teams locate and eliminate weaknesses. The exact mix of testing tools depends on the type of application and the technologies involved, but it usually includes some collection of static application security testing (SAST), SCA, interactive application security testing (IAST), fuzzing, and other dynamic testing.
The key is not blindly running tools, but making informed choice based on risk and policy. You have to decide how much protection your application needs (by making a policy), and then choose tools and integrate them into your development process to achieve the desired reduction in risk.
White paper
Securing 5G and the IoT with Fuzzing
Continue Reading
