Tame the Wild, Wild West in Service Provider Networks

Let’s face it: it’s not easy being a network service provider today. Both wireless and wireline service providers are expected to provide exceptional service to their subscribers while, at the same time, protecting their resources from abuse and attacks. In one sense, providers must be very tolerant of the data that is allowed on their networks, but in another, they must take swift and decisive actions when a threat is seen that can disrupt service. Unlike an enterprise network, where there is strict control over the applications and protocols allowed, with a service provider, it is much more of a “Wild West” sort of mentality where, for the most part, anything goes.

To provide effective protection in this Wild West era requires deep visibility into the traffic on the network plus the ability to quickly identify the source of the threat and its target victim.

It is critical that service providers have visibility into a constantly evolving application and threat landscape. The traffic on their networks is always changing, both the applications that traverse the networks (take the rise of Google’s QUIC, for example) and the threats that traverse the network (the Mirai botnet was just a twinkle in the eye of Paras Jha and Josiah White a few years ago[1]). Service providers must also be able to quickly identify the various types of malicious traffic flowing to and from their subscribers as well as determine the nature and severity of each potential threat.

Determining the nature of a threat is important since threats come in many forms. There are threats that could negatively affect the endpoint or the subscriber, such as ransomware, phishing emails and applications that perform identity theft. There are threats to the network itself, such as botnets or applications that create signaling storms. And, of course, if the bull’s eye moves a bit, there are threats that target another provider’s network. An example of this would be a botnet that is used to launch an attack from service provider A towards service provider B.

Not all threats require action, and service providers must be especially careful to apply accurate threat classification before any mitigating response. Accurate threat classification requires correlation of threat indicators to ensure a confident and accurate conclusion. The more data samples you have, the better your correlation efforts will go.

Put another way, you need a lot of data! To be effective, a threat intelligence cloud should include billions, if not trillions, of other real-world artifacts that are accessible for query via a machine-friendly interface. For each suspicious packet or piece of information (in security speak, we call these indicators of compromise, or IoCs) on its network, a provider needs to be able to query this threat intelligence cloud (or multiple clouds) to identify what other real-world IoCs correlate to the one seen on the network. Successful correlation sheds light on potential threats and allows appropriate responses to be taken.

Let me use a real-world example to illustrate my point.

Suppose a provider has a network sensor in place that has intelligence about malicious DNS sites, and through the course of the day, it observes several thousand suspicious queries. Some of these map to risky websites. Some of these map to malware websites. Perhaps some are even websites known to be used in phishing campaigns. While the provider wants to know about all of these examples, the provider isn’t yet willing to take action on them for a number of business reasons. However, for other more dangerous and suspicious queries, the provider is willing to take action – for example, on any domains or IPs that point to the presence of a botnet on the network that could threaten network availability. Often, these are not easily determined nor the infected endpoints easily identifiable.

If the provider were to see, in the midst of the other domains, one like injbot[.]net, would the provider be able to understand what it meant? By itself, this domain could just be a typo as a user navigates to a website. However, if the provider were able to correlate other activity from this endpoint, such as communication to fast-message[.]xyz and some HTTP requests with a User-Agent value of “2zAz,” a clear picture begins to emerge. This example endpoint is most likely a part of the DarkSky botnet, which is known to launch various types of DDoS attacks. Most likely, the provider would want to identify all similarly infected endpoints as well as stop communication to all other known IPs and domains used by DarkSky. So, consider if a threat intelligence cloud is able to send back hashes for malware that has queried this domain, or even metadata, such as the name or the category of the malware (e.g., botnet or ransomware). Armed with this additional data, the provider would be well-equipped to take further steps to protect the network.

Sample IoCs from DarkSky sample found via Palo Alto Networks AutoFocus tool
This is a challenging environment, but just because the traffic traversing a network seems like the Wild West doesn’t mean there can’t be an intelligent and effective sheriff in town. With the right tools, including the ability to leverage machines to quickly and accurately identify threats of interest as well as their sources and target victims, there is no reason a provider can’t rest easy at night, knowing its customers and its network are safe.

Get more information on Palo Alto Networks Security Operating Platform for service providers.

Additional details on our threat intelligence cloud:

• Threat Intelligence Cloud white paper
• AutoFocus Threat Intelligence

[1] https://krebsonsecurity.com/2017/12/mirai-iot-botnet-co-authors-plead-guilty/