Open source technologies are an increasingly integral element of many large-enterprise IT environments. And as such, they must be subject to the same rigorous security measures as their closed-source, commercial counterparts.
The main question facing users wishing to deploy open source in the enterprise is one of security and the ability to patch and protect the system, identify and login users, and secure and prevent hacking attacks.
There is a general notion that open source technology components, like the Linux operating system, are more secure than commercially developed IT products.
According to Graham Titterington, principal analyst for research company Ovum, a few years ago the comparative safety of open source was "undeniably true".
He said, "The statistics on threats from both [open source and commercial] camps do not always give the big picture. But when you look at the historical frequency and severity of bugs, commercial software has been more vulnerable."
Citing an argument used by many open source proponents, he said that the more open the development process, the heavier the scrutiny it is under to discover vulnerabilities and bugs. "Any type of malware amounts to errors or vulnerabilities in the source code that hackers take advantage of. These occur mostly at the platform level in the operating system or at the database level."
However, the situation is no longer clear cut, said Titterington. For example, four years ago there were some two million lines of Linux code. Today, that has grown to more than six million, with 75,000 different functions within its kernel. The sheer scale of growth in maturity and popularity of open source challenges the effectiveness of the "many eyes" approach.
Also, malware is increasingly not just confined to wanton vandalism, but is aimed at disrupting corporate systems for financial gain. So, if hackers are more determined, open source systems will not deter them.
In fact, the defences in both open and closed camps is somewhat more balanced, now that those with malicious intent will focus on the most lucrative targets as opposed to the easiest. While more people develop open source products, the code is just as available to those with malicious intent as it is to those who contribute benignly.
"The advent of regular patch cycles in the commercial arena has transformed security processes and helped administrators get a better handle on the issues. It does not really matter what infrastructure components you are running any more, as the level of security threats are pretty level pegging nowadays," Titterington said.
Earlier this year, the US government's Department of Homeland Security, a heavy open source technology investor, announced it is spending £600,000 over the next three years to improve the reliability and security of its open source systems.
The department is using automated source code analysis technology from US supplier Coverity, to pinpoint and correct security vulnerabilities in its key open source packages. The scanning technology is designed to pinpoint buffer overflows, memory allocation bugs and other vulnerabilities that are a constant target for malicious hacking attacks.
Automated scanning for bugs is not definitive, but can point to potential issues in a way that traditional in-house code review techniques may miss.
Coverity recently released a report on its findings from its preliminary work with the Department of Homeland Security, where most of the 40 programs tested averaged less than one defect per thousand lines of code.
The cleanest program was XMMS, a Unix-based multimedia application. It had only six bugs in its 116,899 lines of code, or 0.51 bugs per thousand lines of code. Overall, the average defect density of all the programs was 0.43 bugs per thousand lines of code. The most widely used programs scored well under this average. The Linux kernel code had an average of 0.33 bugs per thousand lines of code. And Apache had 0.25 bugs per thousand lines of code.
Ben Chelf, Coverity chief technology officer, said that, generally, it is difficult to determine how well these open source programs compare with their proprietary counterparts. In Chelf's experience, only a few commercial products had been tested, so direct comparisons could not be made, but the number of lines of code is not an indicator of quality.
"Smaller programs can have plenty of bugs while larger projects, such as the Linux kernel, can be tightly controlled," he said. "Quality is more accurately reflected by the ratio of developers to the size of the code base, and by the number of users who use the software and provide feedback."
This is useful to know if flexibility for further configuration or customisation of open source code is necessary. But the growing popularity of open source in large enterprises also includes the ready-made, branded open source systems for out-of-the-box functionality in the desktop and server environments, in particular.
Most major suppliers offering open source-based packages have security components designed to sit on top of their proprietary IT stack, as well as security resource centres for patch updates and advice, alongside managed security services.
Red Hat differentiates itself by claiming its security products are not designed to lock users into buying compatible components only from its portfolio.
Dirk Kissinger, Red Hat EMEA director of marketing, said security is built in from the ground up. "We do not sell anything on top of our products. We differentiate ourselves with the service levels and reliability embedded in the systems we provide."
Red Hat's Security-enhanced Linux (SELinux) operating system, for example, first introduced in version 4 of Enterprise Linux software, has access control architecture built into the major subsystems of the kernel. It is designed to enforce the separation of information based on confidentiality and integrity requirements to isolate threats and support more stringent security protocols.
Novell's own SuSE Linux Enterprise system offers similar security measures to Red Hat's, protecting open source-based platforms from malicious attacks.
Tony Dunn, Linux product director for Novell in the EMEA region said, "SuSE Linux running Apparmor protects your applications, particularly those that are not well written, and creates a "sandbox", so that if one breaks, the system can protect the others."
In addition, a market of third-party suppliers has emerged which are building parts of entire open source-based IT stacks along with security components.
In the past, IT security companies have generally focused on the main commercial platforms, since there has been less demand for Linux.
Jon Collins, an analyst at Macehiter Ward, said, "The open source products from pure-play security companies like Symantec and McAfee traditionally have not had to address the needs of the enterprise in the open source space, so it will be interesting to see how those products develop, as enterprise heterogeneous operating system security and interoperability needs evolve."
Given that companies like Symantec, McAFee, Trend Micro and Kaspersky offer products that perform extremely well-established commodity security functions within large enterprises, Collins believes supporting open source will impact the way firewall and anti-virus products evolve.
"Most of these functions were built into enterprise infrastructures when security was a very different issue to the one it is now, designed to keep the bad guys out. Enterprise customers now are looking to know the state of an entire heterogeneous environment from one central point," he said.
He urged companies to assess the risk of open source deployments in terms of corporate reporting, data security and user access requirements, sourcing services or heterogeneous management tools that already address enterprise-scale anti-virus and firewall needs accordingly.
"I would say the physical and process-based open source security risks are much higher, like an administrator not knowing how to configure Linux servers properly for instance," he said.
Comment on this article: firstname.lastname@example.org
This was first published in November 2006