Behind the scenes of the cleanest ISP in the world
by Mirko Zorz - Tuesday, 17 April 2012.
The most tricky part was to get the connections up and running again – how would the customer be able to inform us that the box has been fixed. So we opened our system to our customer helpdesk and gave them the “unshut” button. When we realized that instead of copies of Viagra ads and firewall logs they really needed descriptions on each malware type, links for more information, etc. so they could pass that information to the customer, we started providing them exactly with that.

But this is all ancient history and was finished back in 2003. There's always something new popping up that we need to adjust to. Right now we're struggling with NAT a bit.

The trickiest part was and still is to detect the malware on our own instead of depending on 3rd parties. The most challenging part on that has been making the solutions compatible with our legal framework. One trick we got into production about four years ago is something I like to call a reversed darknet. With it, we more or less detect 100% of worms and other malware that try to scan the network. In a nutshell, we log all outbound traffic where the destination is not found from the routing table at that time.

When our customer has enough traffic towards unannounced IP space, the evidence is pushed as an incident ticket against that customer. Even in the current IPv4 space, there's still plenty of unannounced space practically behind every /8, so any malware trying to scan, say, random 10 000 addresses per hour will get caught thousands of times during that hour. We even detect malware trying to spread solely within internal networks, because customers tend to route the private IP address space not used by themselves up to their ISP.

How many people work on the team dedicated to fighting infections on the endpoint and what are their roles?

Our CSIRT team consists of five security specialists. None of us dedicate our work solely on customer infections, but rather see handling them as a part of our teams basic activities. Customer incidents contribute to our “other job”, which is to handle all internal IT security incidents, because instead of having to prepare for new threats by reading about them from media, we've usually already seen them targeting a customer of ours. We also detect our own infected workstations with our system, which is a nice additional benefit.

One person is mainly responsible for running the system and bringing new features to production, though he's running plenty of other systems not related to customer abuse as well. Additionally, most of us can code so we all contribute. Handling the customers is done by all of us, but it probably takes less than few hours a day altogether. I mean, when we get information from a credible source that our customer is, say, infected with Zeus, it's just a matter of clicking the “Zeus” -button. That takes a fraction of a second - and even that could be automated if we wanted to, but we've decided against it for now.

We don't have a dedicated helpdesk for these cases. When a customer needs support, the case goes to anyone that happens to answer our tech support number. There's the additional benefit that our helpdesk is more “security aware” than most as they are always reading about the latest threats. When the helpdesk needs help, we have an internal IRC server and a channel dedicated to this.

Spotlight

How security analytics help identify and manage breaches

Posted on 30 July 2014.  |  Steve Dodson, CTO at Prelert, illustrates the importance of security analytics in today's complex security architectures, talks about the most significant challenges involved in getting usable information from massive data sets, and much more.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Thu, Jul 31st
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //