The biggest threat to open source in 2009

TalkBack 59 of 59:

« Previous

• Thread View
• Flat View

RE: The biggest threat to open source in 2009

Hi Dana,

I believe that you point out symptom, but didn't see the problem. Security management in FOSS is an issue, but automated patch distribution is not a fix. To your direct points, the large closed source vendors use automated update mechanisms, but their success in resolving published security issues is not an example that I would hold up to scrutiny.

I recently spoke with Jay Lyman of 451 Group - https://fossbazaar.org/content/open-source-insecurity, and pointed out that . . .

1. Reported vulnerabilities does not directly equate insecurity, just communication

2. FOSS and closed source are basically equal in issues reported by app type (DB, browser, etc)

3. Closed source may have automated distribution methods, but their support contracts and legal requirements sometimes force them to delay distribution of a patch for weeks and months. FOSS has a good track record of getting the patches out fast.

The significance to FOSs and security in the enterprise is -
1. It is already in use by all (some may just be admitting it now)
2. FOSS has no central vendor. Enterprise uses support providers in place of vendors to deal with issues.
3. There is no uniform way for the community to test, validate and report on issues in a trusted and transparent way.

Enterprise managers have no interest in saying no to FOSS, regardless of a lack of integration with Windows SUS. Enterprises run operating systems and applications from vendors other than Microsoft. They are accustomed to managing software risk for platforms that have never offered an auto-update feature. Enterprises also have practical fear of patches that can free ride their way into a network because of a foolish trust setting (anything from MSFT must be good - go ahead and update).


FOSS for enterprises offers protection from vendor lock-in and price competitiveness. It allows multiple vendors to quote on the delivery of the same solution, further allowing expertise to be purchased at competitive rates.

The secret to security is NOT auto-update. There is something to be said for a diligent patch management process, but the biggest problem behind managing patches is actually knowing all those things that you are managing patches for, and delegating time to apply patches and make sure that something else didn't break as a result.

The secret to security is active responsibility for the process of managing FOSS. Just because a license wasn't paid for does not mean it is free, or comes without a management responsibility. WIthout a central vendor, the responsibility falls on the enterprise to establish risk management rules and test procedures to actively and diligently maintain the open source repository.

While vendors offer support around FOSS, users need to be aware of the additional responsibility taken on when using FOSS. It is the enterprise user that needs to define and police the rules around the management processes around FOSS.

In summary, FOSS security has more to do with strict definition and enforcement of management and audit policies, patch procedures and agressive testing. Auto-update is sort of sticking your head in the sand and hoping the problem goes away.


For a more current discussion of enterprise issues in FOSS security, take a look at

http://blogs.the451group.com/opensource/2009/02/10/open-source-security-debated/

https://fossbazaar.org/content/open-source-insecurity

http://gpl3.blogspot.com

Posted by: ernestpark   Posted on: 02/13/09  (Edited: 02/13/2009 @ 02:16) You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Get top-ranked Novell support for Red Hat when you switch Novell If Linux is going to power your mission-critical applications, you'd ... Download Now
• Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
• Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now