Recent security flaws highlight need for vigilance

9
Lee Schlesinger
Open source security is looking a lot like Microsoft lately. Last week we heard about a Linux kernel flaw that could allow non-privileged users to gain root privileges. This week the problem is in Sendmail. According to CERT, “An email message with a specially crafted address could trigger a stack overflow” that “could allow an attacker to gain control of a vulnerable sendmail server.” Is it time to re-examine the notion that open source code is inherently more secure than proprietary software?

Granted, two vulnerabilities hardly stack up to the almost weekly ritual of new security flaws found in Windows, Outlook, and other Microsoft products. The point, however, is that no development philosophy is immune to defects.

Open source developers often claim their methods are superior to those of corporate coders because their code can be examined, tested, and improved by a huge community of developers. Commercial vendors counterclaim that they have staffs whose sole job it is to assure the quality of their code.

Of course they’re both right — and yet both methodologies slip up from time to time. You can’t use news of new flaws to make points in any philosophical arguments about the relative superiority of one camp over the other.

A more productive approach is to monitor the press for announced flaws. Good resources for open source security include our weekly Linux Advisory Watch and Guardian Digital’s LinuxSecurity.com, while general security sites like CERT Coordination Center and SecurityFocus cover a wider scope of enterprise security problems.

Most responsible organizations get that far. Many, however, fail to take the next step of correcting the flaws. They may have good reasons: No one wants to be first to install a fix in case the fix breaks something new. Sometimes servers need to run 24/7 and can’t conveniently be brought down for maintenance. And it can be awkward to patch only a subset of your servers, leaving your network in an inconsistent state.

But those excuses, however valid, are not absolute. At some point you have to fix the security flaws in the software you’re using, and the time to do it is sooner, not later. I’d hate to have had to tell my boss that there was a patch available to fix the flaw the SQL Slammer worm exploited, but I hadn’t installed it.

How do you keep your organization on top of security issues?

Category:

  • Security