#79 – Robert Abela on How to Keep Your WordPress Website Secure

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how to keep your WordPress website secure.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you, or your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today we have Robert Abela. Robert is the CEO and founder of Melapress, formerly known as WP White Security. They make niche WordPress security and admin plugins. He has over 18 years of experience in the IT and software industries and has written numerous web security articles and white papers.

We all know that your website is potentially under attack 24 hours a day, 365 days of the year. But why is that? And what can we do to mitigate that risk?

Robert talks about the security of WordPress Core and how it’s matured over the years. He feels that in most cases, it’s not the Core of WordPress that you need to be concerned about, rather the array of plugins and themes which are added on top. The unique cocktail of software that you add to your site makes it challenging for security products to secure it.

That being said, Robert is optimistic that there are strategies you can adopt which will make your site less likely to fall prey to malicious actors or bots. Updating plugins on a regular basis, keeping fresh backups and the monitoring of logs, all play a vital role and a straightforward to do.

Robert is also at pains to point out that this is not a one-click or one time fix. You’re going to need to dedicate time and resources to your website security, and those resources and time will need to be increased as the importance and reach of your website grows. Evolution is the key here. What worked yesterday might not work so effectively tomorrow.

Another topic we touch on is the automated nature of many of these attacks. Unless you’re hosting a website of some importance, hackers are not trying to break your specific website. They’re deploying automated attacks, trying to infect many websites at the same time. But why do they do this? What are the motivations of these bad actors? Robert explains that it’s not personal, but that does not mean that you can ignore the threat.

We also chat about the many layers which go into making your website work. Typically, you’ve got a web server, a database, and often much more, and Robert explains why you need to be mindful of all of these when drawing up your security posture.

Then, of course there’s the users of your site. The people who you’ve allowed to have legitimate access to the WordPress admin. If you’re in a large company with a high churn of employees, you’ll need to make sure that only people who need access have access, and that the permissions that they’re afforded a correct for the work they need to do.

If you’re curious about how you can secure your WordPress website as it grows this podcast is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to WP tavern.com forward slash podcast. Where you’ll find all the other episodes as well.

And so without further delay, I bring you Robert Abela.

I am joined on the podcast today by Robert Abela. Hello, Robert.

[00:04:31] Robert Abela: Hello, Nathan. Thank you very much for the invitation. Always nice to talk to you.

[00:04:34] Nathan Wrigley: Really nice to talk to you. I’ve spoken to you on various other occasions, so I know who you are, but it occurs to me that perhaps the audience don’t. Would you mind just spending a moment giving us a little potted history of yourself? Your relationship with WordPress. We’re going to be talking about security today, so perhaps that would be a good thing to concentrate on as well. So, Robert, over to you.

[00:04:55] Robert Abela: Sure, I started when I was 20. I started working for a security software company. And through the process of 10, 12 years, I worked through different number of software security companies. So I was working in security.

And for the last company I was working for, we needed a blog. And back then WordPress was up and coming basically. So yeah, we started using WordPress. Back then was the only viable, very good solution to use. But still, it was in its early days. It was around 2012, 2011, 2012. So of course back then security was a big issue, and there weren’t the vendors that there are today and the solutions that there are today. It definitely got my interest.

So while I was working with the company, of course we implemented WordPress, but it got my interest. And then I met some people who worked in WordPress. You know, I like the idea of working from home or doing something for yourself. So yeah, it started as a hobby.

I started writing about WordPress security and reading a bit more, because I was using it for my full-time job. Slowly, slowly it turned into a part-time, from a hobby into a part-timer. And then, yeah, it developed into full-time. And now yeah, I run a company, it’s called WP White Security, which currently by the way, we are re branding to Melapress.

And yeah, we develop a number of security and management plugins. We started mostly with security plugins. But slowly, slowly we’re developing also a number of plugins, which kind of like, a mix of both. Security and also user slash website management plugins.

[00:06:12] Nathan Wrigley: Thank you. People who are listening to this podcast, we have a real wide range of an audience. The audience is really broad and deep. And the reason I mention that is because there’ll be a cohort of that audience who understand all the ins and outs of security. And there’ll be a whole load of other people who realize that security online is a thing, but don’t really have any understanding of what we’re talking about.

So perhaps that would be a good place to lay the groundwork on. Tell us a little bit about the state of WordPress security, if you like. We often hear about a plugin being a fix, or a firewall being a fix, or maybe you sign up for some kind of SaaS app and that’s the fix. But I’m sure that that probably isn’t the fix.

There’s probably a whole bunch of different security vulnerabilities that we need to be aware of, as well as different ways to fix those. So just paint the landscape of WordPress security, if you like.

[00:07:04] Robert Abela: Sure. To start off with, we can start with the WordPress Core. Many people think that WordPress is insecure in the Core. But yeah, if you ask me like 10, 12 years ago, I would’ve said yeah. But nowadays, I mean, WordPress in general, the Core, is a really robust, solid product. So WordPress is not an issue.

But of course WordPress is surrounded, is made up from a huge ecosystem of plugins and themes. And nowadays of course, there are a lot of different solutions. And most issues usually are either user problems, lack of awareness. Or vulnerabilities, issues in plugins. But yeah, in terms of security, like it’s usually a mix of tools. It’s a mix of services, tools, the plugins for example, or services. Or a mix of both. And also best practices.

You definitely, for example, if you have a bare bone WordPress, you need some plugins and services to implement some things and automate. Like add two factor authentication. Implement a firewall. Automate backups. Enforce some policies, for example. That’s what the software can give you, but you also need to follow some best practices. You know like, let’s say have some logs, an activity log. You need to keep an eye on those logs.

You need to make sure that the software is always up to date. And by the way when we talk software, many people look just at WordPress, but you need to also keep up to date your own laptop software up to date. Any software you use through the process, your laptop, servers, whatever, everything needs to be kept up to date, not just WordPress.

And of course one thing to keep in mind is, let’s say you harden WordPress the first time. Security is not a one stop fix. It’s not a one time fix. Because it’s secure maybe today. But as we all know, as businesses grow, as requirements change your website needs to adapt to these changes. So you might need to add new technology. Or you need to install any new plugin, or change something, or change the configuration on the server.

So with every change, or with any new vulnerability that is discovered, make sure that you adapt your security strategy basically. What we call like the four pillars of security. The idea is of course first to secure, harden WordPress. Then of course monitor. Keep an eye of course, on what’s happening. Test, just keep on testing whenever you add something new. Is the firewalls still working as it’s supposed to be? Things like that. Based on findings, you need to improve.

So as the website evolves, as your business evolves or your, whatever you are doing with the website, the scope of the website, and the requirements of your team. Security needs to evolve as well. Okay, install a plugin. You maybe use some services as well, a good mix. You have some best practice in place, but yeah, that’s just as of today.

[00:09:20] Nathan Wrigley: It’s a never-ending enterprise really, isn’t it? You are constantly going to have to be tweaking this and examining this because the nature of the software, which WordPress itself sits on top of, the OS if you like, that’s always changing. WordPress itself is changing. The configuration of plugins, themes, and so on that you’ve got is changing. And also the nature of the attacks, which are coming your way is changing. The long and the short of it is the whole thing is changing. And so I guess you need to adapt with that.

I just want to switch to the attackers themselves, because I always find this subject curious. What is in it for them? So these days we constantly see about the latest hack. You know, if you read tech journalism, you are seeing about SaaS platforms going down. You see about ransomware attacks. You see about people’s Bitcoin wallets being stolen and there’s just seemingly every which way that people can because mayhem, they do. But in a WordPress website, why are they doing it? What are the reasons that they’re doing it for? I guess we’ve come a long way from just so that they can deface your website.

[00:10:27] Robert Abela: I’ve been listening to this podcast. It’s about the Lazarus group. I don’t know if you’ve heard about it. It’s from the BBC. Typically on the scale of attacks the motivation is mostly financial motivation. And okay, of course, like you don’t have any source of money or something on your website. This might not be the case. But these type of large scale attacks, they need a number of bots. Basically hacked websites, hacked servers, which they can use to ramp up their attacks basically.

Or of course, if you want to hide, if you’re hacking a website, you’re going to hide yourself. You don’t want to hack it from your own computer. So you hack a website, you hack another server and use that kind of like a stepping stone. So as long as you have an online presence, whether it’s WordPress or not you are a target.

That online presence, if it’s WordPress or not, any website or any device that is connected to the internet. It has resources. It has CPU power. It has memory. It has internet connectivity, bandwidth. So yeah, that’s a resource. Now, if it’s being hacked either to hack your website and deface website, or as a stepping stone to hack something else. But yeah, you are always target. So even if you have nothing of interest, even if you’re not doing, I don’t know, commerce to your website, and if you don’t have sensitive data, you are still a target.

[00:11:31] Nathan Wrigley: If you have an e-commerce website, obviously there’s a real motivation there. You know, possibly break into your website and figure out what kind of orders have been replaced and cause mayhem there. And maybe try some sort of social engineering attack to steal people’s credit card details.

But interestingly there you also just said just the resources itself, that’s enough. The fact that you have paid for a piece of a computer somewhere, a portion of a computer, the CPU and what have you. That’s enough for people because presumably they want to put their own software on the computer that you’ve paid for, and use it to do nefarious things.

Now, that button means spraying out emails to people who don’t wish to receive them. But what other things are they up to? So if they’re not defacing things, but they are wishing to take your machine over. What kind of things can they do from there, once they’ve got that bridge established?

[00:12:23] Robert Abela: They can do quite a lot. For example, there was this, going back to the Lazarus group, one of the smart hacks they’ve done. They targeted some bankers, some people who work in banks basically with a phishing attack.

Quite frankly, it was the good old trick, like hi, you have won an award. Click here to win via email. Uh, someone from all those thousands of employees in a bank, someone clicked. And malware was injected there. And that led to allowing them to control some ATMs and stuff like that.

But to get to there, when they managed to inject the malware in ATMs and of course control that, they wouldn’t control that malware, or launch the attack from their own servers. Because otherwise it’s very easy to track them back. They need some sort of proxies or stuff like that. So basically they’re going to use your website, which is hosted on a server. The resources of your website, of the server where your website is hosted to launch this attack.

And it’s not the first time actually, they have multiple proxies. So from their machine, they send commands to your hacked website, which sends commands to another hacked website, as in hacked server, and then it sends the comment to the actual victim. The resources you’re paying for, the server you’re paying for, is being used purely for them to hide themselves basically as a proxy.

[00:13:29] Nathan Wrigley: I guess one of the things that I hear sometimes is that people believe that because their website is of a small size, or may not be interesting, in inverted commas, that they therefore assume that the hackers won’t find it interesting. In other words, it goes a little bit like this, but my website’s small. You know, it’s about something really niche. Why would the hackers want to come after me?

And I think what you’ve just said speaks to that. It’s irrelevant. It’s not really a hacker. There isn’t an individual doing this. It’s an individual at some point who wrote a script, which then got downloaded and redistributed a thousand times over the internet and deployed by a thousand different people.

So you don’t need to look for an incentive. The incentive is there all the time. It’s not a person deliberately coming after you for a personal vendetta, usually. This is just people trying to gain some sort of bridgehead in the internet, on the internet, on servers somewhere so that they can because mayhem in ways that you cannot even imagine.

[00:14:31] Robert Abela: Yeah. In fact, even when you say, okay, I don’t know, I have a website about a hobby, some old museum somewhere, whatever. We don’t accept payments. Who would be interested in our website? From the outside it doesn’t apply, because when actually hackers are trying to find, or malicious users are trying to find vulnerable websites. They’re not just browsing one by one.

They have automated tools. They scan whole subnets, whole networks, you know. And they don’t even know or care whose website it is, or how it looks most of the time. Okay, this website has a vulnerability, we can exploit it. So of course we can run commands, you know, on the operating system or depending of course, what they want to do.

But yeah, as long as they get access. So yeah, they don’t just target your website, just scan whole subnets. So, your website happens to be one of them. So yeah, if you have a vulnerability, if you have, I don’t know, an outdated plugin for example that has an issue, and you’ve never updated it and the vulnerability is there and they can exploit it, then yeah. They don’t care whose website it is or how it looks, whatever. It just, it flags okay, this website, they get a flag, this website is vulnerable. Exploit the attack, take over, and that’s it.

[00:15:29] Nathan Wrigley: And I guess the other important part in that, is that this is not a personal thing. It’s very, very, very unlikely, unless you are some kind of nation state actor, that there’s going to be people sitting at computers designing software deliberately to get into your machine. This is just people spraying out bots all over the place, looking for vulnerabilities and then stumbling across them randomly, and then deploying the things that they’ve got to exploit, those vulnerabilities. So it’s not personal, and it’s very unlikely at the other end of that is a real human being. It’s just scripts written, who knows where and who knows when.

[00:16:05] Robert Abela: Exactly. No, in fact, I’m sure like the bigger companies, you know, like Facebook. I’m sure they have a good share of targeted attacks because when you’re so big, I mean they definitely have some haters. But no, let’s say the normal websites, the normal hobbyist websites, whatever, which is quite funny because usually the hobbyist websites are the ones that people think, oh, who will attack my website? But yeah, it’s just like another number.

So, it’s not personal, it’s nothing personal. And as you said, most probably not, most probably, like most of the things are automated. So yeah, there’s not one person doing something to you, it’s just the whole process and it’s all automated. So yeah, nothing personal indeed, yeah.

[00:16:38] Nathan Wrigley: Yeah, which doesn’t make it any better unfortunately, even though it’s not personal. So let’s talk about the tech stack which our WordPress websites are sitting upon. Because again caveat emptor. I know that a lot of the people who are listening to this who are technical, this will be very obvious what we’re going to cover.

But there’s a proportion of the people who are listening to this who may very well not know that there is layers and layers of things making their website possible, and those themselves are vulnerable. Even though you may never interact with them. You may only go to your WordPress, log in over there. Type whatever it is that you need to type, save, publish, and then log out again.

That might be your only interaction with WordPress. But WordPress doesn’t sit in isolation. So what typically is the stack that it’s sitting on, and do we need to be concerned about all of the stack, or are there any pieces which are more concerning than others?

[00:17:30] Robert Abela: It really depends. First of all, your own computer. So if you’re accessing your WordPress website, even just to update. Your own computer needs to be up to date. So that’s part of the tech stack. In regards to the website, it depends like if you have managed hosting where you have access just to this website, the bulk of the work, you still have to take care of some things and updating your software, but the bulk of the work is done by the web host.

However, if you have a dedicated server or just any hosting where you just have to install WordPress, then of course because a typical, let’s say you have a dedicated server, you host everything yourself. The typical text tech stack, you have the web server, typically a Unix, Linux operating system. Then you have the web server, Apache, Nginx or something similar. You have also PHP, sort of like a framework, the language that WordPress is written in. You have MySQL the database server, that’s the most basic.

So you have PHP, Apache, the web server itself of course, and the database. And then of course it depends, like if you need to send emails, you’re going to have the SMTP server and stuff like that. So when it comes to securing that, let’s say that one. To be honest when you look at the tech stack software nowadays, it’s quite easy to keep secure as in like, as long as you configure it properly and securely. Like you read maybe a bit, I don’t know about the, the best practices, and of course keeping it up to date. Software in general is not a big issue.

The more time passes, I think the last few years we’re seeing a small shift, because usually it was always, okay exploiting this issue or exploiting this issue. But most of the cases vendors are quite responsive on their issues. The problem in the tech stack, it’s not actually any component in the tech stack, it’s the users. As in like, it could be even, you’re like, if you forgot to update a plugin or if you received a spam email or a phishing attack and you clicked on some untrusted link. Or downloaded something which you, you don’t know what it is, you know?

There are so many tools nowadays when it comes to keeping your software up to date. There are so many resources. Like, listen, let’s read the best practices on how to set up a secure Apache server. And there are also, of course, services. You can pay people, you can pay professionals who can do these things for you.

So the actual tech stack is, I wouldn’t say easy, because you need knowledge to do it, but yeah, it’s relatively easy if you know what you’re doing. You have the tools, you have everything you need to keep it secure.

The problem nowadays more weak passwords, phishing attacks, and stuff like that. Using public WiFi, using unpatched computers. Using public computers to access some things. Unfortunately the user has become the weakest link in the whole chain, you know?

[00:19:53] Nathan Wrigley: So you’ve got to really be careful what it is that you’re doing. What machine you’re using. Where you’re using that machine, and so on. I’m just wondering if there is, in your mind, any system which you would regard as pretty safe. I’m going to say a hundred percent safe, and then immediately withdraw that because I think we all know that’s not possible.

But is there a position you can get into where you can have done enough. You’ve raised your guard up so much that you can relax? Or is this more a story of constant vigilance, constant worry, constantly assuming the worst is going to happen tomorrow? Or is it possible to employ the services of a particular, say, SaaS company, or a professional who might look over things for you?

And be entirely happy that, okay, that’s now handled by somebody else. I’m entirely safe. Now I know that a hundred percent is off the table, but can we be confident that our sites are mostly safe if we take the right precautions?

[00:20:51] Robert Abela: Yes. I think nowadays with all the tools that there are and all the services even the web hosts themselves, they really up to their game the last few years, especially the managed ones. As you said, a hundred percent is, you’re never guaranteed. But yeah, there are so many tools. If you inform yourself and if you implement some best practices, you websites are relatively safe.

I mean, you should always take precaution steps. Like for example, backups, they’re very important. So if something happens, you can restore. Test those backups, of course, because many people miss that part. They take backup, like, have you ever tried to restore it? No.

So it is very important. because sometimes of course, it’s software as well and it can break. So the restore might not work or something has been corrupted. So that is extremely important. But yeah, from the tech stack point of view it’s pretty much covered. There are a lot of options nowadays.

Even like with a simple managed WordPress hosting, and installing a plugin or two, you’re pretty much covered, let’s say. What’s important is the best practice and the concept that listen, security is not one stop shop. I don’t think we should, one should be really paranoid to be honest. because as I said, we’re in a good position.

But it’s very important for people to keep in mind, especially as the team grows. Because if you’re on your own one thing, it’s relatively easy because you know, you have exactly full control between you and the web host. You have roughly full control of, and you know what’s happening. But as the team starts growing, especially nowadays, in the WordPress ecosystem it’s very common to have remote businesses.

You don’t have full control of your employees, as in like, not the employees themselves, but as in their machines and where they use them and how they use them. So I think what’s very important is of course to raise awareness, train them, train your team. Make them aware that, listen, use your laptop here, or have some sort of guidelines and make sure you can use as many possible tools, documentation, and training to make sure at least you can take care of that part.

Which is, in my opinion, is the hardest part to secure. Because of course, you don’t have full control of users, users machines. That is the most important, because as I said the tech stack, like of course things can happen, but as long as you keep software up to date and stuff like that, unless there’s a zero day exploit, you really unlucky whatever. Okay, it’s never a hundred percent secure, but you are very near that number, you know.

[00:22:57] Nathan Wrigley: In terms of the tech stack and the maturity of it, do we often get really innovative and unique vulnerabilities in the tech stack that builds a WordPress website? Let’s say you’ve got, I don’t know, a server, Apache Nginx or whatever it may be.. Do we ever find a new, novel attack? Does that typically come across, I don’t know, once a year, once a decade, something like that?

So can we lower our guards a little bit or do we find, do you find, you’re the expert? Do you find that there are novel things that are uncovered by security researchers, which have been, maybe they’ve been exploited for a year or more, but kept very much under the radar, kept quiet. Is the landscape changing? Are there new and novel attacks happening all the time?

[00:23:40] Robert Abela: Not really, in terms of vulnerabilities. We’re still playing with the same, for example, SQL injection was discovered in the late nineties. The first decade of 2000 we started discovering other vulnerabilities, like cross size scripting, cross request forgery, you know, and the other ones.

When you discover a new type of vulnerability that I would say, of course, that is very innovative. But for the last 10 years, even if you look, there are some websites which keep kind of like an aggregate of the vulnerabilities that are found in plugins. It’s always the same, especially cross site scripting is very common.

By cross site scripting, it’s also very important to like every different types of cross site scripting, different type of vulnerabilities, have different type of severity. So if a plugin has a cross site scripting vulnerability, it’s not necessarily that one should panic, because I’m not saying, okay, just relax, take it easy.

But listen, some of the vulnerabilities, for example, are very, very hard or can be exploited in a very particular edge case. So it is very important to keep things up to date. But yeah, in terms of innovation, no. In terms of new vulnerabilities, not much.

What is really changing? I think the way malicious users are getting much smarter in the way they craft their attack. They’re still using the same exploits and same, same issues. Exploiting old software, old vulnerabilites. The good old SQL injection, cross my scripting. But the way they are approaching it, the way they are building, drafting their tech, it’s much more complex.

There’s a lot of intelligence behind it, like how they use a number of different vulnerabilities to build an attack. First you send an email. If the victim gets the bait basically, if they click something or whatever. And then if they click, for example, install some malware on the computer, which allows you then, for example, I don’t know, some sort of key logger, and then you see what they’re doing.

Maybe they are connecting to a website and they’re uploading something. So we’ve seen much more complex type of attacks where people are stringing a number of vulnerabilities together to successfully attack some particular target.

But in terms of innovation of new type of vulnerabilities, like new ways of exploiting software, we haven’t seen much, no. For the last 10 years, it’s been pretty much same old, same old kind of thing.

[00:25:42] Nathan Wrigley: Now I’m going to throw a spanner in the works here and ask you about AI. It’s all the rage at the moment for creating content and probably people in the WordPress space know that people have been able to create plugins, and create all sorts of things around the WordPress space.

Lots and lots of endeavors in WordPress using AI, and I’m wondering if this has started to become a trend amongst the hackers as well? Whether they’re using this technology to refine their processes? Possibly to go and look at the source code of things like WordPress or Linux kernel, or whatever it may be. Speeding up the process, finding new novel things. My question really boils down to, does AI and internet security, is that a point of concern, do you think, in the near future?

[00:26:31] Robert Abela: I think right now, not really. It’s still too early, but I think AI is a big changer in general, in every industry, every vertical of the internet industry. Having said that, AI is not a human, so it’s not necessarily coming up with something innovative.

It’s still, at the end of the day, it still has some sort of database where it gets information from. The difference is that nowadays, instead of using Google and browsing through search results, trying to find exactly what you need, okay, this website, no, it’s not here to click on the other one, go on that page.

Rather than going through that process of course, with AI, we’ve really accelerated that. We’ve really automated that. So nowadays, like with AI, especially if you know how to ask what you need, you’re going to get the answer much quicker. So things that usually would take you, let’s assume a malicious user wants to hack something, a target.

It used to take them days or weeks maybe to craft something and to think of something original and learn about something. Because of course you have to search for everything and read a bit more, and try this and try that. With AI, of course you’re accelerating this process. And by accelerating that process you’re achieving much quicker results.

And typically also, true AI, not because AI cannot come up with something new, because it’s always getting information from what there is. But I’m pretty sure it can, because of this fast process, I’m pretty sure it will lead slowly, slowly to also new innovations. In every aspect, content writing, security, security both in terms of attack and defense and every aspect of the internet.

[00:27:55] Nathan Wrigley: Yeah, that’s an interesting point. I hadn’t really thought about that. I was thinking about that from the attacker side. But of course, the defense side also has the same tools to deploy, and I’m imagining that if you’re the vendor of a, of a security product, whether that’s a firewall or a plugin or whatever, you’re also going to be deploying the same tools to try and mitigate what the adversaries are doing.

[00:28:17] Robert Abela: The thing is that luckily both the attacker and the, let’s say the white hat vendor have access to the same tools. So yeah, if you use them wisely. Also, this thing is always a bit of a cat and mouse game. The malicious users do something, the vendors up their game, then they do something, then they up their game and stuff like that.

[00:28:36] Nathan Wrigley: I want to just turn our attention to a typical WordPress user. Perhaps somebody who really doesn’t know a great deal about this. They’re listening to this podcast because they’re curious about WordPress. They’ve got a site which they run, it’s their own. Maybe they’ve got a couple of sites.

They’re beginning that journey on creating their own freelance business or something like that. Do you have any guidance as to how often things ought to be done? Is this really a process of you really should be logging in every day, checking for updates, and while you’re at it, why not just switch automatic updates for Core and all the plugins that you’ve got on?

Or is this more of a look, once a week is fine. I’m sure there won’t be a hard and fast rule, but people who are just beginning their journey with WordPress, they probably do need concrete examples of how they should best handle this.

[00:29:18] Robert Abela: It really depends on the scale of the business and how much traffic your website is getting. And also the number of people working on the website. Because one person or two people from the same room, it’s totally different than being even two people from different locations. And how much the team is security savvy, not necessarily technical, but at least have some basic understanding.

But yeah, in general let’s say a typical startup where you are switching between kind of like a transitioning from a hobby to a part-time. I think as long as you take care of the obvious, install some plugins, add 2FA, add some logs, add a firewall, make sure that you have backups. Work with a solid web host.

As long as you take care of the basics, you should be pretty much covered, and yes, like everyone else, for example checking Google Analytics, or any type of analytics software for that matter. Yeah like, people are doing it for SEO, but it also helps keeping an eye.

Maybe there’s a spike of traffic coming from some unusual location. All these things can lead to something. Check your website every day. You know, like it’s very important, for example especially if you have a very small number of users. You are two or three users. I mean like once a week, maybe you should have some sort of checklist, you know, check how many users are on your website. Run some file integrated scans. You know, like some basic stuff.

Once a week is more than enough at that level. So yes. But what’s important, I think at that stage, especially if you are growing, it’s very important to draft policies and follow security best practices when the team is still very small.

Why? Because if you are not organized when the team is very small, it’ll be much harder, and you’ll have much bigger problems when the team is very big. It’ll be much harder to implement a change. Like, I don’t know, like we used to do something one way, and after one year, the team now is a hundred people.

It’s much more difficult to convince those hundred people, listen, we’re going to change this and we’re going to start doing it this way. And yeah, this can of course, irritate people because people tend to resist change, especially if it affects their productivity or if it’s too complicated.

So I think what matters is, especially as you’re starting, set up some policy, some guidelines, some best practice for yourself, have some sort of checklist. Yes, once a week or so. You can also do it almost once a month, but again, play it safe. Why not spend an hour every week, have a checklist, check how many users are there on your website, check some logs, check the traffic on the website, you know, check the list of plugins. check the files.

Especially, a file integrity monitor can tell you lot of things because if there is a file, typically when a website is hacked, there is a file that has changed. A file has been deleted, or a file has been modified, even an actual legitimate file, it has been modified. So yeah, that can tell you a lot.

Luckily nowadays, of course most of these systems, configure email alerts, you can configure some SMS and stuff like that. So of course you’re automating much and much more. But it’s still good to take a look. And also it’s very important because we, for example, we develop an activity log plugin, and some people are, okay, what should I look for in the logs? It’s very difficult to answer that question, because it truly depends on your business. Because, it’s very important for website owners to understand what’s running on their website and how it’s being used, and only then you can make informed decisions.

Okay, is this log, not just in WordPress, even the web server logs, even in analytics. Is this traffic normal or not? Because, if for example you are based in the UK and typically you get all the traffic from Germany. So by seeing a spike from traffic in Germany, that’s normal to you. But for someone who’s based in the UK but only has UK traffic, a spike of traffic in Germany is a problem for them.

So first what’s very important is to understand your website, have some basic checklists. The most basic stuff, once a week or so. Keep an eye on these things. Traffic, and logs usually, and also log into the website. Why not? You know, just go to the plugins page. Are these all the plugins that I installed? Are these all users that I had? That’s a really good step.

By setting those best practices and those checks once a week, as the team grows it’ll be easier to maybe add something new because of course the team is growing, so you need to add more policies or you need to add, secure something else, you know? So, yeah, that’s very important. It’s very important to keep an eye on things, just check how things are running.

But of course with managed web hosting, especially for WordPress things, most of these things are almost covered for you. Many web hosts have different packages. Many web hosts nowadays they have their own kind of like internal monitoring systems as well. We’ve noticed you have this plugin, which is outdated, or we’ve noticed this. So at least there is a lot going on for you already.

And that’s why I said even earlier, it’s good of course, to be aware, and to be conscious that, listen, these things can happen, but we don’t need to be stressed. If you’ve done your homework, if you do your own homework, and you follow best practices, you choose a good web host and stuff like that, then you are in a good place.

[00:33:53] Nathan Wrigley: Yeah, I guess it’s a good point to mention that the WordPress ecosystem, given its enormous size and reach in the website creation space, you’re in a pretty good spot because there has been so much effort poured into, not only making WordPress secure, but making the update system for plugins and themes trivially easy to switch on.

And I’m just wondering about that one actually. I’m just wondering what your thoughts are on automatic updating. Personally I’ve, in most of the places where it’s possible, I have switched that on, and have had no negative consequences. You know, none of the plugin updates have destroyed anything in ways which would make me want to switch that off.

But that is an option which I know that a lot of people don’t make use of, and I’m wondering what your thoughts are on that. So in the WordPress admin, it’s possible to automate the whole process of updating. It’ll just do it on a regular cycle if it knows there’s a WordPress plugin update, it’ll just do it for you and hopefully everything will work out.

And obviously now we’ve got a safe mode built into WordPress not that long ago. So let’s just talk about that quickly. What do you think about automatically updating everything when possible?

[00:34:59] Robert Abela: Speaking about ourselves, we have automatic updates on minor version updates. Because we have like 4.0.1, 4.0.2. We allow that. because yeah, most cases, usually these updates are just small bug fixes here and there. The chances of something breaking, especially with a plugin update is with major version changes, because of course the vendor has implemented a new feature or drastically changed a feature and stuff like that. Of course, for the better.

But, especially for vendors, it’s very difficult. Let’s say you have a plugin, it’s installed onto a hundred thousand websites. It is very difficult to simulate all those a hundred thousand websites, and simulate upgrades. So of course we try our best to do as much as we can to test as much as we can in different scenarios. But it’s impossible.

So in terms of auto updates, for us and which is something I recommend, I would definitely enable them for minor version updates. In regards to major version upgrades, nowadays again, most hosting providers have the staging websites. Just run it on the staging website, literally, it only takes 10 minutes.

Run it on the staging website. Check the area on the website that is affected by that plugin. I don’t know if it’s an SEO plugin, for example, you check that the headers are still loading or the metadata is still loading. Or if, I don’t know, it’s the tables plugin, check that tables are still loading properly.

And yeah, if it works, update the live site as soon as possible. WordPress itself of course, as soon as you log into the dashboard, and you go to the plugins pages, you have that even, you don’t need to go to the plugins pages. You have that icon that you have updates. So it’s very difficult to miss updates. So that’s great.

But even if, let’s say you’re not logging into your website on a daily basis, there are many services, every vendor usually they have their own change log, you can subscribe to their newsletter. So yeah, whenever there’s an update, you’ll get an email or some sort of notification.

So it’s very important if you’re not logging into your website every day to see when there are updates. At least subscribe to the vendor’s newsletter or builds updates or something. So at least you get an email that, listen, we’ve released an update, especially if it’s a major update. If you have, of course, the automatic updates for minor version upgrades, especially if you have a big website.

Like an e-commerce website, you can have a good number of plugins, tons of plugins. At least you don’t have to do almost daily updates. For the major version updates, if it’s a relatively small website, you might get on with enabling, automatic updates on that as well. But yeah, do it on a staging website. It literally takes a few minutes. Just update the plugin on the staging, run a quick test, 15 minutes maximum and turn on updates on the live website. So yeah, definitely.

[00:37:16] Nathan Wrigley: It’s also the kind of thing that once you’ve done it a few times, it becomes kind of muscle memory and you can do that staging to updating plugin to, you can do that very trivially quickly and get on with your day if that’s not the main part of your business.

Just one last question. You talked earlier about members of staff and what have you. I’m just wondering if you’ve got any guidance, again possibly for the more inexperienced WordPress user, about the kind of roles that you might assign to people in WordPress. Obviously, if you are giving everybody the administrator role, you may well find yourself in a bit of trouble.

And also about the nature of cleansing out the users that you’ve got on your WordPress website on a regular basis. So, you know, if you’ve got a big team and you’re constantly churning through staff, that’s probably something you want to be thinking about as well, because that’s an attack that you really can’t avoid if you don’t make the effort. You know, if you’ve given somebody an administrator account and they’ve got bonafide access to get into the website and you don’t revoke it. Or you’ve given them too many permissions and they then get fired and you know, they fall out with you, there could be problems afoot there.

[00:38:19] Robert Abela: Yeah, indeed. Definitely one shouldn’t give admin roles, assign the admin role to everyone. In fact, as a best practice, I would say have an admin account, really difficult to use and that should only be used by you and only as back up. Because even you as a website administrator, you don’t need admin access whenever you log into the website.

If most of your work is still updating some posts, or maybe changing something from the theme. So no, admin roles shouldn’t be used that often. WordPress has a number of built-in roles. It depends again on the nature of the website, what you’re doing with it. For some people, those roles work.

But yeah, the fact that there’s this technology of roles is, it’s already good, because there are also a number of plugins which you can use to create different types of roles to assign multiple roles to users. And most plugins nowadays they either create their own roles on your WordPress website, or they have different types of functions where you can, okay, like, literally some plugins, you can say, okay, I created a new role for them and I want these people to do only these type of things on this plugin.

So the role control, and what people can do and cannot do, especially when you use a third party plugin to create your own custom roles and to assign different privileges, is very granular. Definitely no admin access for no people, quite frankly. But yeah, the rest, I definitely recommend using some sort of custom role editor so you can create your own custom roles as well if the default ones don’t work for you.

We always talk about the principle of least privilege. I was a systems engineer when I used to work for their companies and, the easiest way, I was like, yeah, give them admin access because it’ll work for sure. Of course. Unfortunately, it’s a very common practice. But no, the reality is you should, yes, start with the least possible.

And if they don’t work, see what else they need. Okay. What else do you need? I need to access this page from this plugin, and check. Contact the vendor from the plugin. Listen, do you have specific privileges for this? Or do we need this? Do we need this? And to build slowly. Yes, I understand that it hinders the productivity, kind of slows down things. But it only slows those things for a day or two. Or give them maybe a bit more access for a day or two until you check with the vendor and then reverse that access.

So always give the least possible. It’s also a question like of user accountability. Some compliance bodies actually have regulations about this. If someone shouldn’t be seeing certain customer data, regardless if you trust them or not, they shouldn’t be seeing it. Why are you giving them access kind of thing.

So, it’s very important to live by the kind of like principle of lease privilege when it comes to users. Give them the lease possible. Even for them, especially if they’re not tech savvy. This doesn’t have to do with someone being malicious, or even if they make a mistake, at least they make a mistake within their environment, their privileges. Not a bigger mistake.

Roles definitely should be used. And yeah, there are a lot of plugins. We’re lucky because there are a lot of plugins which allow you to create your own custom roles, assign different privileges for roles and stuff like that. Definitely roles are definitely things that should be used.

[00:41:05] Nathan Wrigley: This is a topic that we could probably talk about for days.

[00:41:08] Robert Abela: Yeah, roles on their own, yes.

[00:41:10] Nathan Wrigley: And more broadly about WordPress in general. You know, should we keep the REST API on, and are there a bunch of things that you would switch off by default. But unfortunately we’re kind of running out of time, so I’m going to leave those questions possibly for another episode.

Or another way of getting the answer might be, if people want to contact you, Robert, directly. Where can you be found? Do you hang out on social? Is there an email address that you prefer to mention? Where can we best find you, Robert?

[00:41:37] Robert Abela: Yes. Uh, our website is wpwhitesecurity.com but as I said, we are rebranding. So we are announcing the new name at WordCamp Europe. The new website will be melapress.com. m e l a press.com. So yeah, my email is very simple, robert at melapress.com or at WP White Security. I’m also on Twitter and stuff like that. But yeah, I think email is definitely one of the most efficient.

[00:41:58] Nathan Wrigley: Thank you very much, Robert. I really appreciate joining us on the podcast today. Thank you.

[00:42:02] Robert Abela: Thank you. Thank you very much.