A recent encounter with the Mumu worm continues to cause my company's security team great frustration, because new infection reports keep trickling in. And as if viruses weren't enough, we now have another problem.
As for Mumu, most of the company is aware of the outbreak. We've communicated specific instructions via e-mail and an intranet Web page on how to detect and remove the virus. And at this point, the desktop support department has taken over responsibility for dealing with this issue.
But while cleaning up Mumu in remote offices, we discovered something else: We have a growing number of unofficial Linux installations on desktops and servers throughout the company, and they aren't configured for optimum security.
The weaknesses from the rogue installs don't necessarily stem from the Linux operating system itself. Rather, they come from the installation of third-party applications and utilities, which can leave a desktop or server vulnerable to attack if set up incorrectly.
Growing in Popularity
Until now, we haven't had a policy on using Linux because there wasn't a need. One year ago, only a small subset of users ran Linux. The Linux desktops mostly belonged to developers or quality assurance and technical support staffers responsible for supporting our company's software on Linux. Now there are many more. Employees are installing Linux on their desktops, either as the primary operating system or as a second one alongside Windows 2000, our corporate standard.
Staff members are doing this using VMware from Palo Alto, Calif.-based VMware Inc. and other programs that allow multiple operating systems to run on the same machine.
Also, my company is using Red Hat Linux for more of its application servers. For example, we recently purchased an application for conducting surveys that runs only on Linux.
With the increased emphasis on Linux, some departments within the company, including mine, are considering using more open-source tools to help with day-to-day operations. I'm looking at a Linux-based knowledge base engine for the IT security department.
Knowledge base applications are good to have, especially in a department that has many applications to support. Certain configuration problems and associated remedies can be stored within the knowledge base system for future reference.
I'm also looking at security incident reporting programs to keep track of problems that occur frequently. One thing that frustrates me is having to read through incident reports - we generate more than 300 of them per year -- looking for anomalies.
Currently, we write incident reports in Microsoft Word using a template and save them on a shared drive accessible only to the security team. When an incident occurs that might be similar to something that happened in the past, the only way to find such incidents is to do word searches or read through past reports.
An incident reporting and tracking system would ease that data collection and correlation burden. I found several open-source programs that could help, but not everyone in the company wants us to use them. One of the problems management has with open-source is the lack of traditional support -- the ability to call in to the software vendor's help desk. My team is technically savvy, so we don't mind accessing forums, knowledge base sites and other online resources to get answers.
Another objection is that troubleshooting usually requires some technical knowledge of the operating system and programming. But for the most part, if the application is department-specific and not mission-critical, my team and I don't have a problem getting approval to use open-source tools.
In addition to open-source, we've deployed commercial enterprise applications on Linux. It's a lot cheaper to run an application on Linux and a standard PC than to purchase Solaris and a Sun server. The problem is that each Linux installation is different, and that's a security issue. There are so many Linux distributions that it would be difficult to create and manage standard configurations for each.
Therefore, we're standardizing on Red Hat Linux. It offers strong vendor support, and many enterprise applications are written specifically for it. We will also standardize on certain applications, such as Web server, monitoring and security software.
Red Hat Linux itself seems to be fairly secure, but the same can't be said for programs that run on top of it. For example, there always seem to be vulnerabilities associated with programs such as file transfer protocol, sendmail and Apache. And other open-source software is vulnerable, especially when the developer hasn't written the program with security in mind.
One of the most common mistakes I have seen is when the developer doesn't write the program to sanitize it or restrict dangerous data from being passed to it. This is usually the cause of vulnerabilities such as SQL Injection, authentication bypass, buffer overflow and other Web application exploits.
We can't eliminate Linux, so the solution is to create standard baselines for our Linux systems, just as we do for Solaris and Windows. We'll start by doing this for our Linux-based Web, application and database servers. As with our Solaris and Windows systems, we will use imaging software and create a "jump-start" system configuration that will serve as the baseline configuration for all machines. Hopefully, this will keep security problems to a minimum.
This week's journal was written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at email@example.com, or join our discussion forum.
To find a complete archive of our Security Manager's Journals, go to
Copyright © 2003 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.