Networkworld has an article on the DDoS attacks that appears to be originating out of North Korea. Here’s a link to it. The jist of the article is that the DDoS attacks were worse than they should have been because security folks did not know what ISP they were using. The claim was that if the government would hurry up and implement the Trusted Internet Connect (TIC) program, these problems would be a thing of the past.

First a little background, TIC is an effort to reduce the number of connections to the Internet maintained by federal, state and military networks. In 2006 there was somewhere in the neighborhood of 4,500 connections (at the time I was involved no one knew for sure exactly how many connections there were). The original goal was to reduce this to 50 connections. Last I heard the goal was 113. Expect it to float around in this ballpark for a while. Currently they’ve been able to eliminate about 25% of the connections.

There are many reasons why this is a good idea. Single point of security implementation, consolidation of resources, a more uniform implementation of security policy, just to name a few. There are many reasons why this is also a bad idea, one of which is the mitigation of DDoS attacks like the one described in the article.

Look at it this way, if I take 100 Internet connections and consolidate it into 1, I’m not going to implement a single link with 100X bandwidth (30 Gb is about the max we can push today anyway and running at that level severely limits your security product options). I’m going to do the same thing ISPs do, over subscribe the link. Since it is unlikely everyone will try and access the Internet at the same time, normally this works just fine. The problem occurs when a DDoS attack takes place as now there is less bandwidth that needs to be saturated in order for the DoS to be successful. It also means that a greater number of sites will be affected. So I would argue that TIC has the potential to make this problem worse, not better.

But let’s try and look at the true root cause of all of this. They quote Alan Paller as saying they could not get the ISP to filter the traffic. The author states this is because they didn’t know which ISP to contact. Huh? How about a whois query on the address space? Traceroute? Check the monthly bill? Direct ARIN query? I find it hard to believe that a staff of security folks would sit around staring at each other with no idea how to figure out who their ISP is. More likely the ISP did not want to take responsibility for filtering the traffic. I know I’ve run into that problem dozens of times over my career.

Its also possible that this was a pretty low priority. Think about it. The attack started on July 4th. Think back to that day. Were you out enjoying sun and family or thinking “Humm, I wonder if the Federal Trade Commission posted anything today on the state of the economy. OMG I’m financially ruined, I can’t get to their Web site!”? My guess is the former. This is/was a relatively lame attack which was easily mitigated by Monday morning, when access to the site actually had some value. For anyone who’s taken one of my classes, you know I’m fond of saying “Its OK to accept risk provided its an informed decision”. I can see someone making a business decision that it was better to get it working by Monday morning than to spend time, resources and tax dollars on recovering the site during a time period when it would see little use.

So it remains to be seen if TIC will make the DDoS problem better or worse. What would certainly help is a good SLA written into the contract requiring the ISP to respond to these types of attacks.

May the bits be with you,

C