preloader
Resources

Industrialised Attacks and Infrastructure Blocks: How to Use DNS to Get Ahead of the Threat

In Partnership With

Ever since its inception, the RANT community of cybersecurity professionals has fostered an atmosphere of rigorous debate, good-humoured discussion and incisive questioning of event host companies. It’s rare for the visiting executives to ask the assembled guests to evaluate an entire strategy and assess whether it’s a good idea or not – but that was the path chosen by Infoblox during a roundtable they hosted in London.

“We’ve given up chasing malware,” the vice president of the company’s cybersecurity strategy, Craig Sanderson, explained in his opening remarks. “There’s too many. It’s like trying to shoot down a swarm of drones with a pop gun. You’ll hit some, but the one you miss will take your business down.

“We don’t really care about the low-level players – we’re interested in the industrialised players,” he continued, pointing out that certain threats are seen by more than half the company’s 3,000-plus customer organisations. The priority, Infoblox has decided, is to deny the adversary room to manoeuvre: rather than waiting to see whether an attack is going to target a particular organisation or system, they believe it’s better to proactively prevent any attack from succeeding by blocking access to the infrastructure attackers have set up before they launch their campaign.

“We profile that threat actor. They use a traffic distribution system. That makes it easier for low-level criminals to launch large-scale attacks,” he explained. “So we look at DNS registrations and traffic, we partner with service providers, and, based on that, we say: ‘These domains are associated with this threat actor, so I’ll proactively block them, even though it may not be a threat at the moment.’ We don’t know what the malware may be, we don’t know what technology it might go after, but we stop it anyway. We haven’t caught every threat actor out there, but we see this as an industrialised process, and we try to prevent it operating.

“We think this is the right way to go,” he concluded. “But my question to you is: is this the right approach? Should we invest more? Or should we be doing something different with all our DNS data?”

 

Back on the block

The initial response from RANT’s co-host, London Stock Exchange Group head of cyber threat intelligence and threat hunting, Adam Orton, was certainly provocative. But his tongue-in-cheek “Nah, it’s not worth it” got the ice-breaking laugh he’d intended. But on turning to the topic seriously, he found much to commend in the Infoblox approach, particularly in recent years.

“Historically, I would have said blocking IPs is the wrong approach,” he began. Instead, he said, his preference would have been to pursue policies which “imposed more costs on the attacker.” Recently, though, with the growth in what Sanderson called the more industrialised nature of many attacks, the need for new tactics and defensive strategies has been heightened.

“We’ve had a lot of success doing something similar to what you’re doing,” Orton said. By which, he explained, he means “putting hard research into threat actors and identifying their infrastructure.” Doing that has enabled the business to become more resilient. “We’ve seen a lot of stuff bounce off the perimeter; we’ve seen a lot of criminal activity, a lot of fraud, and knew about it before it tried to get to us. If you look at DNS, you can spot them spinning up IP addresses well ahead of time. You can probably find a few hundred IP addresses a day – before they’ve operationalised it we know where it is and we’ve neutralised it. We just watch it and wave at it. From that perspective, there’s a lot of value.”

But there are limits to how effective this approach might be, he argued; and much of this will come down to the resource the strategy demands.

“Is it worth it? From our perspective, 100%,” he concluded. “But the investment in time and people is extensive. Tomorrow things change, and that means another week of effort. It’s a cat-and-mouse game.”

 

Time is money

The members of the RANT community around the table were quick to weigh in with their own thoughts and questions.

“For me, it’s very simple,” one senior cybersecurity leader said. “I have some budget I can invest, but I need to look at my tech stack, and see what I’m missing.” This person’s challenge to Infoblox was clear: “Prove to me this is the one I’m missing.”

“For us, I think, it’s about the proactivity,” Sanderson’s colleague, senior cybersecurity account executive Jason Nolan, replied. Infoblox maintain that they are able to shut down adversary access to infrastructure more than 60 days before an attack is launched. “We think that’s unique. Controls are reactive: they need to see something hit the network in order to unpick it. We don’t care about the malware and we’re agnostic to the threat target – we’re just blocking it based on seeing the infrastructure as suspicious. The proactivity piece is where most people have a gap.”

Another advantage this approach gives is to free up defensive staff more opportunity to attend to other vital tasks. Nolan says that, in analysis of feedback from existing customers, having Infoblox block threat-actor IP infrastructure frees up 68% of SOC staff time. As one attendee put it: “they’re fighting fires – this takes away a lot of the fires.” Nevertheless, there are potential risks.

“On the one hand, it’s great to proactively block,” Sanderson said. “But there’s a whole lot more you can do. Am I caught up in a broader threat, or is it really against us? How do you prioritise?” To help address these problems, Infoblox analyses the asset data from DNS and works out which are the campaigns that need further attention. He suggested that if the data are indicating half a million security events per week, the analysis could boil that down to around 25 incidents.

“We built this tool specifically because our customers were getting overloaded,” he said. “Because we have the asset data, because we’re a DNS platform, we know it’s not 50 different events – it’s six.”

 

Automatic for the people

Questions around how automated the process is by which Infoblox identifies infrastructure as malicious proved illuminating. A large part of the company’s capability comes not from technical sophistication or algorithmic application, but through the experience of the firm’s analysts and something like a gut feel for when a picture starts to look wrong.

“We look at enough infrastructure to get to a point where we know something odd is going on,” Sanderson said. “Because it’s become an industrial process, it has to be repeatable – and the tipping point for us is the point where it begins to look weird.”

“Are you not worried about threat actors changing their habits?” one attendee asked. If they did so, perhaps the indicators the company relies on would no longer be relevant.

“One threat actor – because we were really getting on their nerves – changed the algorithm they used to register domains,” Sanderson replied. But it wasn’t enough to get one past the Infoblox team. “We see them changing their behaviour, and we can track how they do it,” he added.

Ultimately, the approach will be adopted only if corporate decision-makers can see a business case to invest in it. The LSEG has been doing something similar on its own, and Orton believes that the return-on-investment argument has been made.

“The selling point to a mature organisation is time,” he said. “We’ve all got all the controls. We’ve got threat intelligence for days. What makes the difference are those marginal gains – getting an edge. We find that valuable – and I think everybody else would.”


About Infoblox

DNS is notoriously tricky to interpret and hunt from, but Infoblox’s deep understanding and unique access gives them a high-powered scope to zero in on cyber threats. The results in numbers: 60% of threats detected before the first DNS query; 63 days of protection on average before an attack; 0.0002% false positive rate. Visit the Infoblox website or reach out to Craig Sanderson on LinkedIn.