Open Source Security Process Part 3: Are Today’s Open Source Security Practices Robust Enough in the Cloud Era?

In part three of this four-part series, Xen Project Advisory Board Chairman Lars Kurth takes a closer look at different open source projects and their approach to security practices with cloud computing to attempt to answer the question: Are open source security practices a fit for the cloud? Read Part 2: Containers vs. Hypervisors – Protecting Your Attack Surface and Part 1: A Cloud Security Introduction.

Most of today’s software stacks contain many different layers. And, in a layered software stack, you are only as strong as the weakest link.  Without consistent security vulnerability processes in place across different open source projects, there’s a real possibility of errors when handling security issues.

There are two common ways that open source projects approach security in cloud computing: “Full Disclosure” and “Responsible Disclosure.” Both of these approaches are Security Vulnerability Management Processes, which essentially are best practices that help to address security vulnerabilities swiftly. It is worth noting that these processes have been debated repeatedly. This article will dive into how they have developed overtime, how open source technologies are using these practices today, and whether or not they are a fit for cloud environments.

Let’s begin first with examining the difference between “Full Disclosure” and “Responsible Disclosure.”

Full Disclosure vs. Responsible Disclosure

• “Full disclosure” is the practice of publishing analysis of software vulnerabilities as early as possible, making the data accessible to everyone without restriction. The primary purpose of widely disseminating information about vulnerabilities is so that potential victims are as knowledgeable as those who attack them.

• “Responsible Disclosure” is more exclusive on who gets the information of a vulnerability, and is how the majority of open source projects within cloud orchestration stacks are used today. The process is straightforward: whoever discovers a bug works with project’s security team to evaluate and fix the bug. A number of privileged consumers of those projects (such as Linux distros) will test and prepare software packages that fix vulnerabilities, which are then pushed to its entire user base once a security issue is publicly disclosed. The basic workflow and steps in use in “Responsible Disclosure“ can be found in figure 1.

Although different philosophies, both attempt to effectively encourage discoverers to report security issues to security@your-open-source-project instead of selling them or using them for their own gains. Additionally, they both aim to fix security issues as quickly as possible and make sure “exposure time” to security issues (the time from discovery to fix deployed) is minimized. Lastly, they both attempt to ensure that a maximum of users apply patches as quickly as possible.

How Handling Security Issues Differs in the Cloud

Although security practices in most established cloud projects follow the same basic structure laid out in figure 1, there are typically significant differences in the following areas:

• Whether “responsible disclosure” is used for all vulnerabilities or just some.

• The list of privileged users (members of the pre-disclosure mailing lists) who are informed before a vulnerability is publicly disclosed.

• The criteria that are used to establish who can become a member of a pre-disclosure mailing list.

• The application process to become a member of a pre-disclosure mailing list (some projects don’t have a formal process).

• Whether the list of privileged users is published or not.

• What privileged users are allowed to do with the information about security issues that they receive.

• The typical time-period between the discovery of a security issue and the pre-disclosure to privileged users.

• The typical time-period between the discovery of a security issue and the disclosure of the issue to all users.

• The way a project publishes security issues.

• Whether CVE numbers are assigned for all or most security issues.

• Whether there is a single place to explore past security issues.

• Whether security issues are tracked in code commits and other project internae.

Most of the differences can be categorized in terms of operational execution efficiency in the context of an open source project, fairness towards the entire community and transparency with the information and operations of the project’s security process. Although these appear to be small deviations from the basic process, each of these differences can have a huge impact on users of a cloud project.

Distro and Cloud Model of Responsible Disclosure

Let’s consider the examples of “who qualifies to be a privileged user” and “what privileged users are allowed to do with information shared with them during the pre-disclosure period.” These two are closely tied to the goals of a Security Vulnerability Management Processes:

• Make sure that a fix is available before disclosure.

• Make sure that downstream projects and products (.e.g. distros) can package and test the fix in their environment.

If you look at a model commonly known as the “Distro Model of Responsible Disclosure,” only vendors of projects creating distributions of the upstream projects are eligible to be privileged users. The information shared with those users can only be used to package and test a fix for vulnerabilities.

In this model, hosting and cloud services and their users are vulnerable immediately after disclosure because it does not allow service providers that use open source software to start planning an upgrade (at scale this can take a week). It also doesn’t allow service providers that use the software to deploy an upgrade before the embargo completes.

In order to make the security process more aligned to the needs of cloud computing, Xen Project pioneered a new form of security vulnerability process, which for lack of a label, we will call Cloud Model of Responsible Disclosure. With this model, public service providers are eligible to be privileged users in addition to distributions. The information shared under embargo may be used to plan an upgrade, inform customers or deploy an upgrade. A similar model has evolved with OpenStack as well.  

An Overview of Security Practices of Cloud Projects

The following table lists what disclosure approach, or mix of approaches, different open source projects use.  

Despite the fact that Linux distributions have long followed a process of responsible disclosure, there is a complex and hard-to-understand web of different organizations, handling different aspects of Kernel and Distro security.

• Kernel Security: Handles kernel security issues, with the aim to fix and publicly disclose security issues as quickly as possible.

• OSS Security: A public list, which is primarily used for discussion and handling of existing and low-impact security issues.

• OSS Security Distros: A private mailing list, with membership limited to operating system distribution security contacts, which follows a policy a responsible disclosure that primarily handles medium severity or higher impact security issues.

• In addition, each Linux distribution has its own security team, which will work with one or several of the above entities to handle different aspects of security issues; in addition to security issues of all software packages that make up an individual distribution.

Conclusion

Despite the ubiquity of cloud computing today, the majority of open source projects still follow the Distro Model of Responsible Disclosure. Adding to the issue, many newer open source projects such as CoreOS, Kubernetes and Cloud Foundry all appear to have security vulnerability processes that do not go beyond allowing the discoverer to report security vulnerability issues. This is a reflection of the fact that members of different open-source software projects primarily think about developing code first, and security often takes a back seat to development.

Modern software stacks contain many different layers with incompatible or insufficient vulnerability management processes. In a layered software stack, clearly you are only as strong as the weakest link, and the lack of consistent security vulnerability processes across different open source projects creates complexity that increases the chance of errors related to security issues. The only way to address this problem is to establish consistent, industry-wide best practices that take the needs of cloud and service providers into account.

Read Part 4: Xen Project’s Policy for Responsible Disclosure with Maximum Fairness and Transparency