This past Friday, I gave a 20-minute presentation on WordPress security, giving a high-level overview of things you can do to help keep your sites secure.
The Presentation
Here's a SlideShare embed of the presentation deck:
And you can download the Keynote source file for my presentation, including presenter notes.
Twitter Questions
As part of my talk, I asked attendees to submit any questions they might have had via Twitter using the hashtag #wpvipsec. Here are the questions I received, and some brief answers to them as best I can provide.
@ryanmarkel Could you share your snippet enforcing 2 factor authentication per user level? #wcus
— Philip Downer (@manifestphil) December 1, 2017
As we have been transitioning some of the WordPress.com VIP platform to our next-generation VIP Go platform, we've had to reinvent some of this stuff slightly. :) You'll be pleased to know that we have made the mu-plugins we use on VIP Go publicly-viewable on Github, and you can see our custom two-factor module here.
I don't know very much about securing sites via VPN, but I'm assuming here that you have site access (even front-end) locked to internal IPs only based on that VPN connection. That should handle a large portion of your security from outside attack, assuming the VPN is using appropriate security precautions.
At this point, your chief enemy is likely to become human error. This is where portions of the talk surrounding things like limiting user capabilities and access to certain settings pages can really help you out. Making sure your users are following good account security processes for connecting to the VPN is also critical.
As I suggested in the Q&A after the talk, I highly recommend that user roles and capabilities be in your WordPress engineering toolbox. They are enormously useful.
How do we secure admin access on mu subsites? #wpvipsec #WCUS
— Wil Ranney (@wilranney) December 1, 2017
Multisites are interesting because they have additional layers of user access. Let's look at the two admin roles:
Super Admin: This should be as limited as humanly possible. The only users who should have superadmin powers on a multisite IMO are system administrators, your development team, and support users who will be assisting other users with account-level actions regularly. (An additional user or two might be necessary if you have people who need to spin up new sites on-demand rather than contacting your support team.) You should certainly require two-factor authentication here, and if you can require proxy or VPN access at this level, you absolutely should look into that as an option.
Administrator: This is going to be on a site-by-site basis within the multisite. If you can craft custom roles and their capabilities finely enough for your needs so that non-development users who are "in charge" of a site can use those roles instead of full admin, you should absolutely do this. Ideally, this user group and the Super Admin user group are as close to identical (and as limited) as possible.
The remainder of the roles are easier to parse. I'd like to especially recommend here (as I did during the talk) the use of an audit trail plugin; as you will have many users working on sites, and some with superadmin powers, the helpfulness of knowing which users performed which actions increases.
Additional Questions?
If you have any questions that haven't been covered above or in the talk, please send me a reply on Twitter and I'll be happy to drop them in the post and let you know when I have updated it.
I'll be updating this post occasionally with new information, as well as a link to the talk's video archive when it's available. To be notified of this, please either follow my blog or follow me on Twitter.
