Recently a Dutch agency investigated the vulnerability of Dutch municipality websites and the results are quite shocking. At least, that was my first sentiment when I read the results. Almost one quarter of all local government websites use an outdated Web CMS or other web software tool version.
The municipalities with open source CMSs (Joomla!, TYPO3, Drupal) scored the highest in vulnerability. TYPO3 scored best with 63 percent being up-to-date, but that still means 37 percent used an outdated version. The researchers even found out some software versions were so outdated that updating was no longer a possibility.
When Will We Ever Learn?
The results were shocking, because at the end of 2011 we had quite a big scandal in the Netherlands, when the Dutch certificate provider DigiNotar was hacked through their website. This website was managed by a DotNetNuke version from March 2008 (!). In May 2008 DotNetNuke warned against a serious leak in their software, for which they provided an update. The 2011 hack used this vulnerability. That's 3 years later.
This hack had a huge impact because the hacked organization was the certificate provider for the Dutch government. Government organizations, notaries and others had to delete all their DigiNotar certificates and renew them. Without this renewal their websites were banned by all kinds of services throughout the internet. Many government websites and extranets didn't work for days and weeks.
You might think everybody was alarmed after this incident, but another initiative under the name of "Leaktober" (Leaktober, from the month October in which the initiative took place) proved that government organizations keep on neglecting their web software security. Both in 2011 and 2012 this yearly October investigation made clear government websites are still quite vulnerable, despite a government manifest and even an official team of government experts that can help.
Hacking isn't as Difficult as it Used to Be
The problem with these scandals and warnings is that people tend to ignore them. “It didn't happen to our website.”
Right. Not yet. But what if it does?
I help organizations select content management tools and nine out of ten of my clients have an outdated Web CMS when they contact me. Reasons for having an outdated version are: they are not happy with the CMS, they are not happy with the system integrator, they ended the service contract because it was too expensive, they didn't update because some tailor made modules and integrations didn't work after the last update, they didn't even know you can update a CMS, and so forth and so on.
Organizations with an outdated CMS are quite vulnerable for any hacker. Make no mistake, hacking is not just for whiz kids. You can find hacking tutorials on the internet (even video tutorials for newbies), you can find tools to search for outdated web software. In other words: almost anyone can find, hack and mess-up a website. So the question is not if you are going to be hacked, but when.
Risk Management is Serious Business
I believe that when no one is responsible for risk management, websites will stay vulnerable. You cannot expect editors, web masters or developers to do this task. You need to address your update policy to a specific role, e.g. the functional manager. If release management isn't a recognized process in your organization just get inspired by the IT IL Release Management Process and you're almost there.
The problem with keeping track of CMS updates is that organizations select a CMS and rebuild a website in a project. In this project, security is sort of less covered, at least in the requirements. But once finished, the project is handed over to a department and things like security, update management and other issues are often neglected if it isn't part of your governance plan.
How to Keep your Web CMS Up-to-Date
Having a security officer or a release management process helps, but even in this case you need a security policy for your websites and web software. Which is just a "paper tiger" if you don't act on them. But here are some things you can do:
- Update your CMS on a regular base. Be it open source or proprietary software, update your CMS at least twice a year.
- Be pro-active in your updates. If there's a new patch or update, please don't wait until the next update cycle. Update now!
- Let your system integrator do the updates. Updating a CMS can be tricky, so why not outsource this to an expert? But keep track of what's happening.
- Test your site and CMS after each update. Again, updates are tricky. So test both your CMS and your site after each update. Just in case. And report any anomaly. BTW, if testing in a D TAP environment makes any sense at all, it's after an update.
- Make sure your tailor made modules still work. Most organizations have some tailor made modules or plug-ins connected to its Web CMS. The main reason for organizations not to update their CMS is that its tailor made modules might break. In case of proprietary software, let the vendor and the system integrator guarantee that nothing breaks after an update or that they will fix it at no cost. If you use an open source tool, ask the system integrator to guarantee the same. If you downloaded and installed the open source CMS yourself, just try another plugin until you found one that works or build one yourself. Hey, you wanted a free beer. Don't complain about having a bad hangover! ;-)
- Make someone responsible for the update policy. Somehow web projects have little alignment with the IT service department. Make sure you find someone within the IT department who can execute this policy, preferably as part of their default IT service management. If you can't find someone like that, address this risk in your steering group and make sure someone else outside of the project team is responsible for updates once the project ends.
Security is Not Only About Updating Your Web CMS
Of course I realize updating your CMS is not the only measure against web vulnerability. But it's a clear and easy step. So please do it.
And yes, ask your vendor about their update policy, their SSL access, their OWASP compliance and such. But even highly secure tool have security issues, be it tomorrow or the next day. So keep on track with your updates.
From security experts I learned that the "human factor" is the most critical issue in security. This varies from employees stealing business critical information to writing their password on the bottom of their keyboard. Password management is a challenge by itself. In the DigiNotar case the hacker found the CMS password from the 2008 version of DotNetNuke in no-time.
Unfortunately this password "Pr0d@dmin" -- which ironically stands for Proud Admin -- was used for MORE
systems within the organization, including the DigiNotar 'business critical highly secured' certificate system. Why have different passwords for different systems, right? There's no security tool that can prevent catastrophes happening because of people's stupidity.
I'm sure the Netherlands is not the only country in the world with these problems. I would like to hear from you about your experiences with Web CMS update pitfalls and best practices. What works, what doesn't? Did you experience a security breach, what happened and what measures were taken? We can all learn from this.
Image courtesy of Pedro Miguel Sousa (Shutterstock)
Editor's Note: To read more by Erik, check out his Get More Value Out of Your Web CMS with a Content Strategy