Security in the Cloud: Open Source

This is the first of a series of security-related postings, which Acquia will compile into a free ebook. In this entry, we'll look at the perennial question: Is Open Source software inherently more secure than commercial closed-source software?

Securing applications is an ongoing process. It's a continuum that requires vigilance.

Application security begins during the requirements analysis stage of the Software Development Lifecycle, and must be nurtured throughout the life of the application to be successful.

With Drupal properly configured and managed, it is as secure and reliable as any enterprise content management tool available. However, a Drupal application must be maintained and enhanced over the course of its existence. Acquia Cloud eases this management and maintenance burden on customers, and substantially reduces the risk that software vulnerabilities, external actors, or poor human choices will compromise the integrity of the application or the organization.

As requirements are gathered for a new project, and both open and closed systems are considered, evaluators often ask, Which solution is more secure?

This is frequently cast as a contest between the ideologies of open and closed source software.

It's the wrong question. All software is susceptible to errors at every step of the lifecycle: from first release, through patches, and on through end-of-life support, when the provider no longer supports the code.

Repeated professional and academic assessments have demonstrated that coding errors are simply part of software development. The professionalism of closed-source commercial software development, which has continually improved its security reviews and practices, is matched by the professional commitment of open source engineers. The main difference between the two is the visibility of source code to all users.

Because most malicious users take the same approach to probing for and exploiting known vulnerabilities, by trying to enter systems on the Web, source code availability seldom plays an important role in discovering flaws in mistakenly unprotected servers, services, or protocols. Open source code, however, enjoys a greater flexibility and speed-to-solution when a vulnerability is discovered, which we will look at later.

Writing, testing, and shipping perfect code is the impossible dream that falsely creates the impression that some software is inherently more secure than others. All non-trivial software is imperfect, and the hardware it runs on can also carry vulnerabilities. In fact, the likelihood of security vulnerabilities is inherent in any application, because people often make mistakes in development or configuration of an application.

So, when we talk about computer security, we must recognize that we're really talking about human security practices that can fail at any number of user-controlled points. Open source software makes those potential flaws a discussion among a group of coders, reviewers, and security professionals. In closed source software, a potential flaw is often regarded as a secret -- one that may impede the resolution time or increase the risk of a discovered vulnerability.

A race with intruders

At the time a vulnerability is discovered, the clock starts counting down to an increase in attacks against that vulnerability. The closed-source software world depends on security through obscurity, the assumption that hiding source code makes it harder to discover vulnerabilities. This means that a newly discovered vulnerability sets off a race between the developer and malicious users: who's going to patch or exploit that vulnerability first?

The same race happens in the open-source software field, but there are many more people familiar with the open source code, so the dynamics are very different. Sometimes projects even collaborate with each other to increase the number of developers working on the same fix, as was the case in August, 2014 for the XML-RPC Denial of Service affecting both WordPress and Drupal.

By comparison, in proprietary software only the commercial software company's employees can work to fix an error in the closed code.

Indeed, many commercial software security vulnerabilities are discovered by outside consultants and security professionals, who inform the company that built the application. These outside discoverers may bring a solution to the problem along with their vulnerability report, but ultimately the vulnerability will only be patched when the company decides to respond, when it is able.

In some situations, this vulnerability becomes an open secret held closely by an ever-expanding circle of people in the know, all hoping the Bad Guys don't find out before they deliver a patch. By contrast, commercial companies with a vested interest in the security and capabilities of certain open source systems are now frequently joining together to fund development or security remediations out in the open. Thus, open source actually adds another dimension of security through this community approach to development: it provides a constructive outlet for coders whose passion is searching for vulnerabilities.

Open source code software allows many hands to work towards the mission of identifying and fixing vulnerabilities. The same race to patch a vulnerability exists, but the open source community has a more distributed approach to responding to a known issue. This is generally understood to be an advantage. In a 2009 University of Washington paper, Is Open Source Software More Secure?, researchers, including a Microsoft contributor, concluded:

...Open source does not pose any significant barriers to security, but rather reinforces sound security practices by involving many people that expose bugs quickly, and offers side-effects that provide customers and the community with concrete examples of reusable, secure, and working code.

It's worth mentioning, by the way, that in late 2014 Microsoft itself, once the paragon of the closed software model, announced that it will make its server-side .NET stack and core runtime frameworks available as open source code. Acquia's Christopher Stone said it was the software equivalent of the falling of the Berlin Wall.

So the real operational security challenges come after a vulnerability is discovered, in the time between a patch becoming available and the time that customers patch their software. Most successful attacks occur in that window. Any system left unpatched is likely to be targeted at some point.

This is why Acquia Cloud's managed platform includes patching and maintaining of all server components, prepares security updates for their customers with Remote Administration, and recommends security best practices and configuration hardening for Drupal applications.

With Acquia, customers can count on rapid responses to vulnerabilities and a quick delivery of patches when available.

The intractable problems in computer security remain: open or closed, people write imperfect code; many are lazy about patching or upgrading to the latest version to close newly discovered vulnerabilities.

The challenge is bigger than open source versus closed software.

That's why we're confident that the Acquia approach is the best hybrid response to the threat of imperfect software. We leverage professional practice, the open source community, and a tightly managed continuous-deployment workflow to quickly patch vulnerabilities on our platform, while providing the tools to customers to stay up to date with regards to patching their Drupal applications.

We'll get into the details of Acquia's approach to patch management in one of our next posts.