Getting Slammed with SQL Slammer

Well now, this weekend was interesting. It is sad to say, but with the propagation of the SQL Slammer worm this weekend, my business got a huge boost this afternoon. I can't say much about it right now, but I would love to share a small part of it.

The new company I founded this year has a product which... point blank.... stopped the SQL Slammer worm cold. In my small test environment (mostly VMWARE unfortunately) a vulnerable SQL server gets nailed by the worm, and then quarantines itself and eliminates the propogation. How it does this is by significantly reducing the speed of propagation of network-based viruses and worms, and in many cases preventing the propagation completely. It does this in a few ways.

1. Firstly, it monitors corporate security policies to ensure compliance and containment. Knowing that a SQL server should never call the operating system function to open a socket and connect in this manner (the actual propogation itself) the access control mechanisms block the call, eliminating the ability to open the socket.
   
2. Secondly, if for some odd reason the security policy allowed this operation, the worm would be significantly slowed down since all new unknown connections are qued. Most worms start scanning and finding more vulnerable hosts like the plague. As such, a single host trying to go outbound may have 10s to 100s off concurrent connection attempts (which means 10s to 100s of half open sockets). The security software can detect this, and que the connections and slow down the attempts. In this way... instead of being able to infect 100s of machines in a matter of minutes... in many cases older connections simply time out and die. (gotta love sock opts time outs). By RFC specs TCP can self regulate itself, so valid connections will try again and reque. However the worm moves on to newer targets. Of course by this time, the que triggers an event to alert the admin... who can manually quarantine the infected host or apply other security measures to limit the propogations. And.. it doesn't significantly impact on clean, valid connections.
   

And to think... this is just a side effect of what the security software does. In other words the software I am writing by default significantly reduces these sort of risks because of its own intelligence in enforcing security policy characterisitics across the network. Even though a vulnerability exists, if the central policy server knows how the network is supposed to act, it can enforce unknown conditions by using a "least priviledge" policy from the get go. Yet I didn't actually go write an anti-virogen system. Man am I pumped.

Top that off with the fact some of the players I have been talking to in the last two weeks called this afternoon to say they are on side for a more technical review as they themselves have now be "slammed", and they can now see where my solution can seriously mitigate their risks.... I am feeling quite happy. So now I am in over drive. I finished the business plan this weekend which means all the corporate documents are complete, hold that to the cash flow model which I just started working on. I will get to that after I finish up on something I have in the debugger right now. With all this talk about the SQL slammer I think I will go write a business case to explain how my software would benefit an organization in a practical example that is fresh in everyone's mind. I bet the CIBC would have loved to have stopped the Slammer... since it killed their ATM systems and Interac completely for the weekend. Hmmmmm that just gave me a thought.... gotta go. TTYL