Categories
How-To WordPress

WordCamp US 2017 Presentation: Security, The VIP Way

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.

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.

https://twitter.com/NelsonTheFresh/status/936659951711408129

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.

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.

Categories
Code WordPress

More WordPress.com VIP Open Source

At WordPress.com VIP, we are currently hard at work designing new platform services for our clients we think will help us take their sites to the next level of WordPress awesome. And today, my colleagues open sourced two of the tools we are using internally.

(Both of them are use on this very site, actually—because my blog has been running on our new platform as a test for some time now.)

The first is VIP Jetpack, which is a series of forced module activations and testing preparation we use with the Jetpack plugin suite for VIP Go. (Yes, this site and other sites on VIP Go always use Jetpack. No, it’s not a performance hog.)

The second is VIP Support, which we use to access client administration pages when troubleshooting a site. This ensures that we don’t always have admin access to client sites, but that we can assist when something goes wrong.

This project is so exciting for me, because we have a dedication to developing as much as we can in the open, a test-driven development process, and a peer review-heavy culture. I’m not actually generating any of the code you see in these repos, but that doesn’t mean I’m not proud of what we are accomplishing and how we are doing it.

By the way, the source used to power this site on that same platform is available here; I’m working on things in the open as well even though I don’t have much time to work on them. :)