making a story out of the Drupal hack – and addressing security

The widely twitterphrased BBC news story from Friday 31st October drew to a great many people’s attention a recent Drupal security vulnerability. Drupal, for anyone who doesn’t know, is an open source content management system (CMS).

The article really was quite a poor piece of journalism, in that it painted a worst case scenario, using the Drupal security team’s public service announcement — (PSA) as its prime source of information, coupled with some unsubstantiated data on reach.

Why was this lazy? Because the advice given in the PSA represented a measured and calculated approach for how to deal with a serious on-going issue. In giving that advice, Drupal’s security team dealt with it in the best way they could. The correct approach with issues like these is to work from a worst case scenario, otherwise they don’t get sorted. BBC just turned that into a ‘big numbers’ story.

In reality the number of sites that could have been affected is considerably less than 12 million.

Firstly, any Drupal 7 site hosted on Acquia, and any of the other dedicated Drupal hosting specialists who had an opportunity to deal with this across the board would have been fine, as they patched immediately.

Secondly, the BBC article quotes Mark Stockley from Sophos who says that up to 5.1% of global websites use Drupal 7. The only source I can get 5.1% as a figure for Drupal usage is of Drupal’s overall share of the CMS market, not its overall share of all websites, so I’d like to know how the article arrived at its figures. Using the source above, Drupal 7 usage is about 1.24% of all global websites, not 5.1%.

And the actual number that could have been compromised will be less than that still, because a lot of people would have patched in a timely manner. But of course, that doesn’t make quite as good a news story.

In any case, as for the announcement, that refusal to bury heads in the sand and share information transparently is a key part of the open source ethos. A such, the actions of Drupal’s highly visible security team is to be commended.

So, what if people are now worried about Drupal? Well, if we work from the sensible premise that all systems are penetrable, the first question to ask yourself with any system is how are those risks mitigated? Comfort in your answer should exist as a result of there being a security initiative in place that is as visible as Drupal’s. If there isn’t or if you believe that your system is impregnable, then it’s you who has your head in the sand.

I saw some people comment on the back of the BBC story that somehow this issue strengthened the case for either proprietary or vendor supply solutions and that the cost of open source was never ‘free’. Frankly, this is just tribalistic nonsense. And rather than throw stones, these people should consider to what extent they too live in a glass house. As ircmaxell says in his excellent post on the issue any decision on what sort of solution to use is based on a trade off and there are two ways to look at things:-

  • Use a CMS/Framework, because they are better than you and can fix vulnerabilities quickly, so everyone benefits.
  • Don’t use a CMS/Framework, because any vulnerabilities found can be exploited en masse.

Further, clients who come to us at miggle, having already decided to use Drupal have reached that point because they’re sold on ‘freedom’ not ‘free’. The two are very different. Those that are primarily interested in the latter are generally not the right sort of clients for us. And the agencies who support licence fee based products, arguing that ‘free’ lacks credibility, merely just do so to protect and justify their investment in that.

As the MD of a small agency I can neither own a rock solid proprietary system built in house (because we are a team of 14 and I believe it’s an impossibility for so few people to do that) or pay money to use a solution I have limited opportunities to influence and contribute to. I buy into Drupal because of the community, it’s the community (and the security team is a part of that) that fix issues and it’s the benefits of community built open source that our clients are trying to leverage, for all the right reasons. This is why we have a good cultural fit with the site owners we work with. Maybe someone can tell me how you establish cultural fit with clients around a vendor supplied solution?

The issues of the last two weeks have been the most serious I have encountered since starting with Drupal three and a half years ago. So, there have been some learns obviously. Will it stop us using or supporting or improving it? No. Because even if we wanted to jump, there is no ship with a perfect deck we could land on. As for our clients? I can’t answer for them, but I can say the reasons for which they chose Drupal (and the risks inherent with it) still prevail after this issue, of which there’s an open knowledge. Security is of course key, but we pick up most of our work because our clients are restricted by either proprietary, vendor supplied or poorly implemented open source solutions and what we do is use the power of community driven standards to deliver them operational freedom both now and for tomorrow.

I’ve now been working in this evolving digital industry for 20 years, so as things have developed I’ve seen things mess up too. What I’ve learnt is that it’s how you respond to those challenges that counts. I’m proud of how the community I’m a part of has done that, as it matches my and my business’s values.

So, in the spirit of openness at a business level what did we learn at miggle? On the back of an announcement that came out at 5pm on 15th October we started upgrades at 8am the next morning and completed that in a few hours. That seemed good enough at the time. Two weeks later Drupal has advised us it might not have been. As a result we’ve been following the advice as well as forensically analysing all of our sites. We’ll also change our processes so that the next time there is a threat we will move more quickly.

If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.

First published here