Telecoms, at its core, is about connecting people and machines. In technology terms, this means a specialized world of network protocols and all the security risks of broad attack surfaces in complex systems.
Each type of telecoms network has its various components and associated protocols. When you are looking at network diagrams, just remember that every box has multiple attack vectors, namely the protocols that it supports; and every attack vector corresponds to software that can contain vulnerabilities.
The telecoms industry can be roughly divided into builders and buyers.
A builder creates a product that performs telecoms functions, such as a session border controller (SBC) in a VoIP network, or a service gateway (SGW) in an LTE network. Network equipment manufacturers are a classic example of builder organizations.
A buyer purchases products from builders, assembles a network, and sells network services to its customer. In telecom, a network operator or service provider is a buyer.
Fuzzing for builders
As with any organization that creates software, adoption of a secure software development life cycle (SSDLC) is critical to minimizing risk. The SSDLC ensures that security vulnerabilities are located and remediated as early as possible in product development, which minimizes cost. Significant return on investment (ROI) is realized when using an SSDLC, just from the reduced cost of fixing vulnerabilities sooner instead of later.
Beyond reduced costs, using an SSDLC reduces the risk of what's euphemistically known as "adverse events." Catastrophic failures, hacks, breaches, leaks, and other types of skullduggery can cost a company money, time, and cause irreparable reputation damage. If the builder's product is the entry point for a highly visible breach, the headlines can drive down stock prices and drive existing customers away.
One key component of an SSDLC is fuzz testing, in which deliberately malformed inputs are sent to the target software to see if an error condition can be triggered. Fuzzing is a favorite technique for hackers who seek to locate unknown, or zero-day, vulnerabilities in software. Fuzzing as part of an SSDLC is an effective, proactive approach to locating and eliminating vulnerabilities in software before a product is released.
Fuzzing for buyers
A network operator purchases products from builders (vendors), assembles them into a network, and sells services to its customers. The operator's reputation hinges on the reliability and security of its network. Downtime is extremely painful, both in terms of lost revenue (and penalties built into service level agreements) and in terms of reputation. If the operator suffers a hack or a breach, it bears the brunt of accountability, even if a vulnerability in a builder's product was the ultimate root cause of the event.
One way the network operator can minimize the risk of downtime or security breaches is with fuzz testing. Before using any builder's component in the network, the operator typically subjects it to rigorous testing, both to make sure it works properly and to ensure that it is relatively free of vulnerabilities. The operator can perform fuzzing on the builder's products in a test lab, and then works with the builder to resolve any findings.
Operators who are in a strong position with their builders can require builders to do fuzzing before delivering products. This reduces the testing load of the operator and is actually much more efficient, as the builder can find and fix vulnerabilities entirely in-house.
Fuzzing is a crucial component of an SSDLC
While fuzzing is well understood as a method for locating vulnerabilities in software, it is only one part of the SSDLC.
From the buyer’s perspective, fuzzing is a powerful tool for evaluating builders' products, but again is only a part of an overall verification process.
Builders cannot continue "business as usual," do some fuzzing at the end of the development cycle, and expect to magically create more secure and robust products. They will see some improvement, but better software requires a better process. An SSDLC factors in security at every stage of product development, minimizing overall risk and resulting in products that are safer, more secure, and more robust.
Jonathan Knudsen is senior security strategist at Synopsys