Alexander Loechel - Plone Security in Context

In Europe there is the CMS Garden project: combined marketing for open source CMSes. We are partners and learn from each other.

Is Plone secure? It depends. Core is pretty secure. But security of an installation is dependent upon maintenance: if you don't apply hotfixes, it is not secure.

You can look at number of hacked sites, but security is a process, not a state. You may get a zero day export today. Are you ready for it? Are there bugfix or hotfix release processes? How do you discover those?

OWASP has a top ten report on common vulnerabilities in web sites. Plone is handling them. [Edit: alternative link, as the main OWASP list is in a PDF, is from vpnmentor. Thanks to Paola Cherlan.]

Study from BSI 2013: the vulnerabilities in Plone are in the core, mostly not the add-ons, which is different in other systems. So Plone actually protects the add-ons: you don't usually make a site insecure with an add-on. New BSI study this year, not yet published, raw number may seem not so good for Plone, but there was only one really important issue, they were looking at the fresh Plone 5.0, and most problems have meanwhile been fixed.

For most of the other CMSes you need a lot of add-ons to come to a comparable functionality as Plone, and that may be less secure: their add-ons have more problems. On my university I see hacks for wordpress and Typo3 sites every week, for Plone: none.

Plone has a different focus. It is good for intranets, and is not only a CMS, but a portal engine. Security is built in, with RestrictedPython, AccessControl. There is no SQL database, which means you avoid a whole category of problems. We have generators for add-ons, giving a secure base for adding features, so you don't make beginner's faults.

Plone's market share is not so large, so large botnets will mostly ignore us. That does not mean we are more secure, but it does help in practice. But we are used by several high value targets, like the FBI, which will normally get attacked first. Zope/Plone users are usually more aware of security.

Permissions and workflow are a real strength in Zope and Plone. An institute like BSI will give Plone at most a medium security level. Not high security, because admins can see all information. If you really would want this, you could actually build it with workflow.

In PHP, data and code are mixed, also for add-ons. In Plone, code is on the filesystem, and you cannot change it.

Sanitised input. Warning: don't use the structure keyword to display unfiltered user input. We do automatic csrf protection.

Plone does not enforce active bans of ip addresses, and security studies may complain about it missing out of the box, but you can simply use fail2ban in front of it. Use tools like that. And use good caching to avoid your site going down under an attack. There are ways outside of Plone, or any other CMS, that you can use.

The Joomla security team does a good job of communication, we could learn from that.

But other security teams often belong to one company. Often only bug fix releases, not security hotfixes. Bug fix releases may contain all kinds of small or large feature updates. Sometimes no security information is available, especially for add-ons, which is where most of the issues may be.

Never use a system 'as is'. Think about extra security you can apply in front of it. Spend fifteen minutes a day per system to maintain it.

If you have a strong security need, check out the Zope Replication Service to have a read-only front-end.

Audience: shameless promotion for Radio Free Asia. It is using Plone, and it is a constant target of attacks, and we have a clean record, no successful hacks.