Open-source software projects handling of security flaws

I blogged about Open-source software projects need to improve vulnerability handling practices some time ago.

This morning, I received an email from Zimbra - Zimbra News: Important Zimbra Collaboration Security Updates.

One thing to note is we are not a paid customer of Zimbra, but we have been running Zimbra Community Free Edition for a long time. Yes, not a single cent for Zimbra to earn. 

But, hey ... they still send us emails regarding security updates... as and when they are found over the years!


At the same time, Zimbra Collaboration 7.2.7 has been released, which fixes some security issues as well.

In the release note, there is a dedicated section on Security Fixes, where the security flaws are described and fixes/workaround are recommended.

Cool, right? Still remember we are not a paid customer?



Now, we know there is a commotion lately regarding the way ForgeRock handles the latest security flaws found in OpenAM.


In late 2012 (well, when ForgeRock was still young), they published security advisory publicly to the community. It is still available in the Internet today.

The root causes and workarounds were publicly shared then.

Moving forward, when the latest security flaws are discovered, ForgeRock now decides to only briefly inform the community with the following email in the mailing list.

Dear OpenAM Community Member, 

ForgeRock today issued security fixes for OpenAM releases 9.5.x, 10.0.x and 11.0. 

We are sending this notice to strongly recommend that community members update their OpenAM production deployments at the earliest opportunity. 

For OpenAM 11.0, fixes have been applied to trunk. If you are a customer, then you can upgrade to 11.0.1, which contains the fixes, and is available from the ForgeRock Customer Portal. 

For OpenAM 9.5.x and 10.0.x deployments, contact us at http://go.forgerock.com/2014OpenAM1101SecurityAlert.html 

Regards,

Security advisory is now no longer publicly available. It's now a simple one-liner: ForgeRock today issued security fixes for OpenAM releases 9.5.x, 10.0.x and 11.0.

Now, when I posted OpenAM 11.0.1 and Policy Agent 3.3.1 released!, I was of the impression that the difference between paid customers and non-paying community members is that a JAR is easily made available to the former.

If you are a paid customer and on the latest release of OpenAM, the patch is fairly simple.

1. Download the appropriate jar for your OpenAM version 

2. Restart your application server

Done. As simple as that. 

And I openly and still honestly think that this "convenient service" is what paid customers deserve. (Come on, there has to be a difference. Otherwise, who will pay premium service if everyone enjoy the same benefits?) On the same day, I tweeted a sentence from OpenAM mailing list - "Open Source software is NOT free. Open Source software still takes a lot of time and money in order to produce it." I was still on the same context on the "convenient service" provided by ForgeRock to paid customers.

What I did not know then (which someone later pointed out to me. Thank you very much!) was the detailed descriptions and codes that have been fixed are only made known to paid customers. The community members are expected to look at the source code trunk and to compare what has been changed. Even if the fixed codes have been found, one has to guess what exactly was the root cause to the security flaw. But all these delays will take time.

I do not agree to this. Security flaw is big issue -- to paid customers … as well as non-paying community members. Every single deployed OpenAM should be patched at the earliest time possible.


Take a look at Redhat …

Everyone single piece of information is shared publicly, including "security".

Paid Redhat customers can immediately download the latest binaries to patch their servers, while community members need to quickly see what has been changed and to apply the same into their servers.



In my opinion, paid customers should be differentiated by:

1. premium, top-notch & quick turnaround support services
2. product features

Security fixes should not be classified as product features. It should never be.


You see.. the point is: Yes, I may not be a paid customer now. But if your product is great and your service is excellent and you treat security as your top priority, I may well pay you for commercial support one day. Better still... for my customers, I'll definitely push your paid services to them. 


Dun you get it? I thought this is Business 101?

.

Open-source software projects need to improve vulnerability handling practices

I came across an article in TechWorld - Open-source software projects need to improve vulnerability handling practices.

The optimists believe in the following and they think every Open-Source Software developer will behave the same:

There's a line of thought among some users that open-source software is more secure than commercial software because there are more people looking at the source code and providing feedback or because open-source projects can patch issues faster.

In reality, this is hardly true. And that explains why most CIOs are pessimists, especially in Singapore.

While in other Asia regions (especially South-East Asia) where budget is limited, CIOs in Singapore have relatively huge budget to work with. Cost is never in their top-priority list. Security is, especially if they are looking for suitable Identity and Access Management software.

It is seldom the best-features product that wins tenders. (I was naive few years back that  I'll surely win any project if I have the best product in the market in terms of features, scalability and cost-effectiveness. I learnt my lesson. Humble now.) 

I think the process in handling security vulnerability must be transparent and communicated again and again.

I just visited Apache Software Foundation site and was pretty impressed with the way they communicate how they handle security vulnerability. The steps in handling security vulnerability are listed in detail.

They even have dedicated team with corresponding email addresses for certain high-usage products.

Now, it is never enough to tell potential customers that "there is a team of smart developers helping to take a look as and when security vulnerability is found. These are the smartest people around who know this particular open-source software inside out. They are the ones you need if vulnerability is found. And by the way, this is the email address you can forward your concern to."

CIOs are not stupid, I have to say that.

They need to be convinced that there is indeed a process in place and a dedicated security team to rely on as and when critical vulnerability occurs. Turnaround time in resolving the security loop-hole is very important to them.

By the way, if there is indeed a process in place, then it's better that the same information is communicated to the public. Otherwise, who knows you are working hard behind the scene?

Communication is an art.


.

Get open on GitHub for the Government?

I think by now almost anyone in the Identity world has heard of the Obamacare's Website glitch which happened few weeks ago. Read here and here and there are so many websites there that reported the incident. Just google it.

The White House’s Chief Technology Officer even said that “at lower volumes, it would work fine”. This must be the greatest joke I have ever heard!!

Today, I came across this article Governments get open on GitHub.

It's a good move! If the Singapore government can think alike, the open source community will be really happy. It might take a real long time, given the current state. Hopefully, it will happen...

.