Resource Starvation: An All-Too-Common Attack Type

Denial of Service (DoS) attacks are one of the biggest banes of networks, and good software developers play perhaps the most important role in their remedy. After all, without code that can withstand an attack, attackers' shenanigans will continue. Based on the number of DoS vulnerabilities discovered each month (I counted more than a dozen in September), I'd say developers need to quickly adopt better coding skills.

Although this newsletter's readership is primarily managers, network administrators, and end users, I want to remind you about a great resource that's probably most interesting to software developers: David LeBlanc's biweekly Writing Secure Code column on our Web site, which helps developers quickly learn how to fend off DoS attacks and more.

Formerly a lead developer for Internet Security Systems (ISS), David now works for Microsoft as senior corporate technologist in information security. Every other week, David offers detailed hands-on information that helps developers secure their code against attack. For example, in his latest installment, "Defeating Denial of Service Attacks," David offers detailed suggestions about how to protect a service's worker threads and memory space to avoid resource starvation-type DoS attacks. The next installment, "Defeating Denial of Service Attacks, Part 2," explains how you can avoid CPU-starvation attacks by using functions that consume less CPU time.

Even though the three resource starvation attacks discussed in David's recent columns are among the most commonly discovered security risks today, he clearly shows how better coding practices can help you avoid such nuisances. If you're a developer, be sure to read David's column. If you don't write code yourself, you probably know someone who does, so consider passing along David's column—it's great stuff. The quicker we enlighten developers about better coding practices, the sooner we'll see a reduction in DoS vulnerabilities. Until next time, have a great week.