| Telco networks aren’t just connected to the Internet, in many cases they are the Internet! Whether protecting the internal network operations center (NOC) from malicious attack, or whether a component of a managed security service being delivered to an enterprise customer, the telco needs to ensure that their perimeter defenses are tested for security readiness on an ongoing basis.
As a best practice, IP networks typically have multiple layers of perimeter defenses to keep improper traffic out while allowing valid traffic through. Sophisticated firewalls or intrusion prevention devices incorporate signature-matching engines to identify and filter out specific traffic associated with known attacks. It is insufficient to simply load all possible signatures and presume that they are effective. First of all, protective devices get slower (less throughput) as more signatures are installed unless they offer integrated onboard processing or ASIC acceleration. At least as importantly, telcos need an independent way to verify the effectiveness of the signatures — failure is not an option. Telco networks are too important and service outages due to network elements being unprotected must be avoided.
Telco network customers understand if service is interrupted due to a backhoe digging up a bundle of fiber-optic cables. However, customers are far less forgiving if their IP service were interrupted due to a hacker exploiting a well-known vulnerability. For maximum vigilance, a best practice within Security Testing is to go beyond blocking known attacks, to search for unknown weaknesses in services by fuzzing (a process that statefully interacts with a target to deliver invalid or unexpected inputs that are carefully crafted to expose programming errors that frequently appear in protocol implementations). Fuzzing based on an accurate model of the service is able to expose weaknesses within the actual protocol implementations, not on the requirements documented within the standards.
Fuzz testing is challenging for traditional test vendors since they must wait for the standards to settle enough before beginning to create canned test cases for that protocol. This is flawed from the start though since these test cases are based on what the standards body says will happen, not on what the vendors actually built. To test IP services containing proprietary protocols (or aspects of protocols) and to deliver test solutions ahead of standards, it’s essential to consider a new scheme for security testing that incorporates fuzzing, based on accurate models of the service, which provides extremely fine-grained and guaranteed-relevant test cases that will expose many weaknesses before they ever appear in a production telco network. So, if the network goes down, it won’t be because of the telco network being unprepared or unguarded.
Last but not least, an important use-case for fuzzing is being used by Mu's carrier customers today when they are selecting new vendor equipment
for use in their future network planning. They deem it critical that all equipment must meet an
established baseline, especially around interoperability and robustness of the
protocols they intend to use within their service offerings. One of the
best ways to accomplish this is via fuzzing, either based on open
protocol specifications or on service-specific traffic flows that must
be supported by the telco network. Mu's Protocol Fuzzing and Studio Zx modules
make it easy to compare the results of many different target devices to
see which is able to stand up to invalid or unexpected inputs around
the traffic that must be supported by the network.
|
