There has been a lot of debate over whether open standards or open source are more important to the success of the cloud. While this debate transcends cloud security, the relevance to cloud security in particular is still very important. Also, the debate really is about whether open licensing is important too or is it just open standards.
One camp in this debate, as summarized by Krishnan Subramanian on Cloud Ave is led by Tim O’Reilly. O’Reilly says it is the open standards and interoperability that matters. The other camp says that just open standards are not enough. You need the protection that open source licenses provide to allow the innovation and evolution that is needed to reach as Subramanian says “the open federated cloud ecosystem”. Without this you are vulnerable (just a little security pun) to vendor lock in. There was actually a great debate on this at the collaboration 2010 conference. Here is the link to the video (beware this is a 60 minute discussion but worth it).
So is open source security in the cloud subject to the same pros and cons? Actually yes and no. Security is based on CIA. Confidentiality, Integrity and Availability. While open source in security has been widely successful, generally speaking many end users don’t look as closely on whether the security is open source or not. In the cloud, more so than on the desktop world, you are going to probably know less and less about what is under the hood of the security your cloud provider is providing. You want to know the security is there, but less about whether the security is open standard or open source based. This is true in security as a service, but less so in the older model of security appliances and software sales. When consuming security as a service, generally less attention is paid to what the underlying technologies are under the hood.
On the other hand because so many cloud based open source solutions actually have open source underpinnings, it has created its own open standard. The Snort IDS signature is a great example. Whether you have an Alert Logic cloud based solution or some other security provider, chances are Snort based signatures are acceptable. While signatures themselves may not be open source, the syntax and format are standardized. Also, many security providers have taken the base open source Snort IDS engine and built more functionality on top of it. An example is the patented, automated process of correlating vulnerability data to model complex attack scenarios that the Alert Logic service performs. Again, customers may not care that some of the underlying security technologies are open source. It is the service and security they receive which is important to them.
So on one hand, customers and cloud consumers don’t seem to care too deeply about open source or not in the underlying security infrastructure. But it is that open source and open standards that allow cloud security to function. So bringing it back to Tim O’Reilly and the rest, cloud security needs both open standards and open security to continue to evolve and meet the task of securing the cloud.
{ 3 comments… read them below or add one }
As technology advances and the Information technology (IT) community adopts those advancements new business models will be developed. A good example is Software as a service (SaaS) and cloud computing, the evolution of SaaS.
A major difference from traditional software distribution when compared to SaaS or cloud computing is that with these new business models there is no transfer of the software to the end user. If the provider of the service uses open source licensed software, for example GPL, they are not transferring the license to the end user and therefore are not required to provide the end user the source code. They are also not required to provide any changes to said source code back to the open source community. Companies who provide their product(s) through SaaS or in a cloud environment don't have to disclose what software they are using or if any of their software is open source. They are not restricted from doing any of these things but they are not violating the GPL license if the choose not to do them.
As such delivery methods become more commonplace there will be an increasing number of companies benefiting from the open source community who choose not to release source code or make changes available to the source code available. Without modifications to open source projects being given back to the community some of these projects could fail to evolve. Effectively by choosing not to give back to the open source community these companies would have created a derivative closed source project.
Likely open source licenses will also adapt to these and other business models as they are developed. The GPL license recently was updated from v2 to v3, and many suspected that v3 would close what has been coined the "service loophole". But when V3 was released no restriction was introduced. But it is important to keep in mind that some future version could introduce terms that would remove the "service loophole". If introduced and widely adopted this would require service providers, using software with the new license, to the same requirements as those who distribute software through more traditional methods.
In conclusion I think a good follow up discussion to this, very good article, would be: "What role does open source play in the future world of cloud computing?"
Nick, the FSF *has* already done this work, and created the GNU AGPL: http://www.gnu.org/licenses/agpl-3.0.html
Nick, you bring up a an excellent point. In fact I was so taken with it, I actually wrote a follow up to this piece on my Network World blog. You can read it here:http://www.networkworld.com/community/node/61836
{ 2 trackbacks }