Host: Hey George, I hope you’re going well. So it is good to have you on board on this Security Bootcamp. I think we can start with the introduction. First you can introduce yourself to the audience and then we can start the presentation. The topic is about STRIDE and how we can use it to identify the bugs and all the things. So the stage is yours.

Joel Barbara: Yeah, sure. So hi everyone, I am Joel. I’ve been working with MelaPress as technical writer for close to four years now, however have been working with WordPress since the very early years. I remember WordPress sort of starting to come out, before that we used to work with Joomla quite a bit. So I have a deep appreciation for WordPress and the role it plays in democratizing the internet. Excuse me. Have worked in several roles within IT for a very long time, as IT manager, systems administrator, now more recently as a technical writer as well. Deep passion for security, and in this presentation we’re talking how to identify WordPress threats using STRIDE.

Host: I think we can start with the presentation. The people are waiting for the presentation, for the discussion of your topic. So here’s on the screen.

Joel Barbara: Yep, perfect, thank you very much. So hello everyone again, I am Joel, and in this presentation we’ll be discussing threat modeling for WordPress. More specifically we will be looking at one particular threat model which is called STRIDE, and how this can help us understand and mitigate threats in WordPress environments. So if you can go to the next slide please.

Yeah, so what is threat modeling? To better understand what threat modeling is, maybe we should start by answering the question of what is a threat. There are different definitions, however one that’s by Cambridge Dictionary is very fitting for this context, which tells us something unpleasant or violent will happen, especially if a particular action or order is not followed. So what this tells us is that we can reduce the likelihood of future violence or unpleasantness if we take action in the present. This is precisely why threat modeling is important. So hold that thought as we examine a more technical definition of the word threat. Next slide please.

So a more technical definition comes courtesy of the NIST, which reads as follows. Any circumstance or event with the potential to adversely impact organizational operations, including mission, functions, image or reputation, organizational assets or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also the potential for a threat source to successfully exploit a particular information system vulnerability.

So it is a mouthful, but if we dissect it we can see what we can take away from this, including what are the threats and the repercussions. So we can look at the threats first. So we have unauthorized access, destruction, disclosure, modification of information, denial of service, and system vulnerability exploitation. And the repercussions of these number of threats are adverse impact of organizational operations, including on its mission, its functions, its image, reputation, organization assets and individuals. So now through this we are starting to get a clear picture, not only what the threats are but how these threats can manifest themselves, what the repercussions are, and ultimately how we can mitigate the risk of these threats. If we can go next slide please.

So threat modeling allows us to identify threats so that particular action can be taken so that unpleasant things don’t happen now and in the future. So while modeling might sound like a big fancy word, at its core it’s very simple, it’s a checklist basically, and by using these sort of checklists we can be reasonably sure that we have covered all of our bases and are thereby in a relatively secure position. So keep in mind that risk can never be eliminated, it can be managed, it can be reduced, but never eliminated. So through these checklists what we have is a surefire way that we have covered all of our bases.

Now one way to protect yourself from security breaches is to install one or more security plugins. However this is not a strategy, this is more like hoping for the best, and hoping for the best is not effective WordPress security. So to make sure that our WordPress security strategy aligns with real world threats, we can use threat modeling to ensure that we are in a secure position. Next slide please.

So at MelaPress every year we do a WordPress security survey. We did one last year. We run the survey online and in person, excuse me, in person at WCEU. WCEU is run over the two, three days that we are there, and the online survey was run for a couple of months. And in last year’s survey we asked respondents whether they have experienced a security breach, and 72% of our respondents indicated that they have experienced at least one security breach. Half of them, nearly 50%, indicated that they experienced more than one. So these are not small numbers by any stretch of the imagination. So definitely security deserves our attention because a security breach can lead to, as we saw, a number of unpleasant things basically.

Now one common misconception among administrators and website owners is that their website is not big enough to be targeted by an attack, but it’s not necessarily the case. Bad actors can breach a website for a number of reasons, including to form a botnet to attack a secondary target, through a campaign of geopolitical aggression which at the moment we are going through quite a lot, to help the competition, which might not necessarily be the competitor but someone who has a vested interest in seeing you fail and see someone else succeed, and just because they can, as a target sort of practice. So they are gearing up to attack a bigger website but they will use your website as target practice. So threat models such as STRIDE have been developed to address threats in the real world, which is why they are important.

A few slides ago we saw what are the threats that IT systems face, from the NIST definition, but what are the threats that WordPress websites face specifically? There’s a number of them. There’s breaches where someone gains unauthorized access to your website, data theft, manipulation, and deletion for a number of reasons that I just covered, and loss of service. These are some of the threats, there are many many more, but they can give you a better idea of what are the threats that you are facing.

So how does threat modeling help us? Think of checklists and to-do lists as something that helps us to remember tasks we need to do in the future, and they help us ensure that everything that needs to be done gets done. Threat models work in the same vein, they work as a checklist to make sure that what we need to do gets done basically. Now STRIDE, which is what we’re going to cover in this presentation, is not the only one. There are a number of others, and STRIDE might not necessarily be the one for you. Which one you choose will largely depend on a number of things.

So there’s the environment, which is the scope and size of your website. So do you have a small blog site, or do you have a thriving e-commerce site or a large multi-site network? That’s going to influence which model you choose. As well as your risk appetite and resource availability, because all resources are finite and limited, be it man hours, financial resources, expertise, we always have to make a number of tradeoffs. And basically based on this we will choose a model that fits our requirements the most. So obviously there is STRIDE, which we’ll be covering in some detail today, however there’s also attack trees, there’s DREAD, PASTA, TRIKE and a few others.

So as I said, yes, your type of environment, your scope, size, your appetite, the market you operate in, as well as any applicable laws might mean a different model would be a better fit. So more than anything the purpose of this presentation is to introduce you to threat modeling and help you understand how threat modeling can help you and your organization, and how you can start implementing threat modeling within your organization.

So what is it about STRIDE, where does it come from? So STRIDE was developed by Microsoft way back in 1999. It is used extensively even today as a foundational tool in software development, however it has been adopted and adapted by different organizations to fit different scenarios. So it’s not just in software development but also in systems management. So STRIDE is an acronym and it stands for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. So these are the threats that we are going to be focusing on. Yeah, so while STRIDE has originally been developed for software development, even if you are a plugin developer this can work for you to make sure that the plugin is following all security best practices, but it can also be adopted in systems management, which is what we’ll be seeing today for the most part, basically to ensure that your WordPress websites are secure. So if you can go to the next slide please.

So we’ll start with the first one, which is spoofing. Spoofing is when a person or program successfully masquerades as someone else. So how can this happen in WordPress? Next slide please. So we have weak or compromised passwords, excuse me. So attackers use either credential stuffing or brute force attacks to login. So brute force attacks are basically trying every single combination until one works. Credential stuffing is a bit different. So of course you might be concerned with securing your WordPress websites, but many users and people ultimately reuse the same passwords as they do for your websites on other websites. So suddenly you need to be concerned with the security of other websites, because if another website gets breached and the passwords get stolen and leaked, or maybe someone will try to sell them on the dark web, now attackers are going to use those very same passwords to try to breach your website. Which brings us to the next point, excuse me, two-factor authentication.

Very very important. With two-factor authentication, even if credentials are stolen, 2FA would prevent unauthorized access. This is because even if they have the right password they still need the 2FA code. And something else that you need to be aware of are fake login pages through phishing. This can start through a man-in-the-middle attack where someone redirects traffic to a fake login page. They will typically use a very similar URL, so for example, work with MelaPress, they might add an extra L in MelaPress which can be very difficult to see, especially if you see the URL that’s very close, and then you enter your password and they steal your login information.

So how do we address this? So first is through strong authentication. So have a password policy which says how long a password should be and the complexity, uppercase and lowercase characters, special characters, alphanumeric, non-recycling of passwords. So let’s make sure that users are not using the passwords they just had or a password that was two passwords old. There are two different ways that we can do this. One is we can ask the users nicely, send them an email, make sure that your passwords meet these requirements, or else we can have a plugin to make sure that our password policy requirements are met.

At times, SSL, TLS. So SSL we don’t use anymore, even though we still refer to TLS as SSL sometimes, but it’s TLS, and this is the certificate that basically renders your websites in HTTPS. And what this does is it encrypts the traffic, sorry, including passwords, from the WordPress web server to the visitors and users. This makes it more difficult for man-in-the-middle attacks to take place and reduces the risks of phishing. Two-factor authentication, as we explained, even if the password gets leaked, whoever is trying to gain access would still need the 2FA code, which can be sent via authenticator app on your phone or via email. Now we have also the push notifications and passkeys to reduce the risk.

If you have any forms, whether it’s login forms or contact us forms, use captcha. This will reduce the risk of bots submitting phishing attempts to get us to redirect somewhere else. Use captcha and limit login attempts. This helps us with brute force attacks. We can basically stop a user, so after three failed attempts, five, seven, whatever you choose, again it’s all about risk management, the user account gets locked. They can get either unlocked automatically after some time or else through a manual unlock, which makes it more secure because then the user has to get in touch.

Moving to the next one, which is tampering. So what is tampering? Unauthorized changes to data, insertion of malicious code, code tampering and file tampering. Next slide. How does tampering work? Several ways. We can have malicious plugins or themes which contain backdoors and then allow an attacker to gain access. Now, the vast majority of plugin and theme developers do test their plugins and obviously develop plugins in good faith. You need to be wary and avoid basically nulled plugins and themes, which are premium plugins and themes that are basically pirated and sold for much lower cost. You don’t know the person, where they’re coming from, they’re probably not the most upstanding citizens, so inserting a backdoor is probably not beneath them. They also have vulnerabilities that include SQL injections and cross-site scripting. Not much we can do, but there are some steps that we can take.

And unauthorized file edits via insecure permissions. So it happens a lot, we are in the process of troubleshooting something, chmod 777 to make sure that it’s not a permissions issue. Don’t go there, stay away. Whatever you are troubleshooting should work with the right permissions, so assigning 777 is never the answer, even whilst you are troubleshooting. In fact we see many hacks to WordPress sites containing modified index.php files mostly, but also WP config, which contains login information for the MySQL server, and the .htaccess.

So how do we address this? Next slide please. So one way is through file monitoring. So for example at MelaPress we do have a completely free plugin called MelaPress File Monitor. What it does is, so you do a scan, and it will create a hash of all files and all directories. Next time you scan it will create another hash and compare the new hash with the old hash. It can also compare your WordPress core files with what is available in the official WordPress repository. So if anything has changed it will tell you straight away, and this is a very failsafe way, so to speak, of trying to see whether malicious code has been inserted.

And another way is through activity logs. So keep a log of who’s logging in and when, what are they accessing, what are they modifying. The principle of least privilege, which tells us that user accounts should only have access to what they need to do, not more or less. So if you have very specific roles in your organization, use a role editor to basically create roles for those functions. Malware scanner always helps, if there’s some known malware running on your system this will help us to find it. As I said in the previous slide, only use themes and plugins from reputable sources. So do your homework and see what experience other users have had with the plugin or theme. Do check how responsive they are, and how often they update the plugin or theme.

Ultimately no one is perfect, even the most reputable theme or plugin can have a vulnerability, no matter how much testing is done before public release. But see how responsive they are. You can check if it’s on the WordPress repository, you can check there, and like the previous presentation was from Patchstack, you can check on Patchstack as well, to see how often they had a vulnerability, how they go about fixing it, to make sure that even if something happens you are covered and that the plugin developer is not going to abandon you and will try to fix it as soon as possible. And always set the proper file permissions, they should always be read only, especially files like WP config which contain important information about the database. Next slide.

So moving to the next one, repudiation, fancy word which means denial of performed actions. So next slide. How does this happen in WordPress? So we can have an employee deleting content or changing settings, but when questioned denies that it was them. So this can happen with lack of logging of user action. So if we don’t have an activity log on our website we don’t have any sort of recourse. So if a user denies doing a particular action we don’t have a leg to stand on, we don’t have any evidence that would tell us a different story. It can happen if you don’t have an audit trail or a poor audit trail on critical changes, so for plugin installations, account creations, there’s a big chance that you won’t know. It’s one thing if you have one user and a handful of plugins, but if you have hundreds or thousands of users and many plugins installed, one new user, one new plugin, probably not going to notice it. So next slide.

So how do we mitigate these WordPress threats? So very important, activity logging, which keeps a record of when users log in, log out, the time, their IP, what they did, what they didn’t do. This is done through a plugin. You can also have the plugin send you notifications via email or SMS when certain things happen, so for example send me a notification whenever an admin user account is created, very very important. Same for users logging in, logging out, keep a record with their IP and everything, so if something happens we can always go back to understand the activities that led to this. Same with the web server logs and the logs of the server itself, if we have access to them, let’s make sure that they are on, so if something happens we can always revert back to them. Next slide please.

So the next in STRIDE, about halfway through, information disclosure. It means unauthorized access to sensitive data. Next slide. How can information disclosure happen in WordPress? So we have exposed files, sensitive content, sensitive information, so either through server misconfiguration which allows certain sensitive files to be exposed, leftover files either through, when we are troubleshooting something rename a file, backup, and forget to remove it. Vulnerabilities, there was one in 2018 a while back. So WordPress is very secure, but then again vulnerabilities can happen. There was one in 2018, the WordPress REST API, that allowed unauthorized access to user details. And some, we can have a plugin that displays SQL errors, which can reveal for example the table names and structure, and that is giving bad actors more information to use in their attempt to breach our WordPress website.

So how do we mitigate the risks of information disclosure? So always make sure to restrict access to critical files, disable directory listing, ensure all software is up to date. And ensuring all software is up to date basically works for most of the threats. And as we mentioned in a previous threat, make sure you have a TLS certificate. So one thing that you will notice for sure is that some of the mitigations apply for different threats, and these are the mitigations that we need, these are the low-hanging fruit. So make sure that they are always there. And something like TLS not only encrypts the traffic between WordPress and visitors, but it can also for example help you with SEO, because search engines prefer websites that have TLS. So there’s no reason to not have TLS. Many hosting providers make it very very easy to install a TLS certificate, so if you don’t have one just go ahead and install one. Next slide.

So we’re almost at the end. This is the penultimate one, denial of service. Not sure what’s happening to these slides, they got a bit squashed. It’s service unavailability, excuse me, due to an attack or a vulnerability. So how can this happen in WordPress? So we all know about DoS, DDoS attacks. So you can have an attacker or a number of attackers sending a lot of data to our WordPress server until it can no longer service new requests, that’s a DDoS attack. Brute force attack, so repeated attempts to overload the server. XML-RPC abuse, so they send massive requests to the xmlrpc.php until the server can no longer service new requests. And poorly optimized plugins as well, so you can have a plugin with poorly optimized SQL queries that once we hit a number of users, the plugin basically will take down the web server.

So how do we address the denial of service threats? Next slide. So rate limiting, we can limit the request rates. CDN, so now we are moving the risks to the CDN server, and CDNs typically have DDoS mitigation systems in place, such as how they respond to malicious user traffic, they shut it down, and routing, so a CDN routes through to a number of servers, so it is spreading requests across a number of servers, which reduces the risk of a successful DDoS. Install a firewall, whether it’s a plugin or at the server level if you have access, but do have a firewall. And always optimize the database and the server if you have access. Okay, moving to the next one and the last one, elevation of privilege, excuse me.

So this is when a user account assumes responsibilities that they were not intended to have. How does this happen in WordPress? Next slide. So you can have vulnerable tokens that allow privilege escalation. So there was a past case where a plugin had a vulnerability that allowed attackers to gain admin access. You can also have misconfigured user roles, so you created custom user roles and you mistakenly assigned a role a capability that you should not have. Or exploiting unpatched WordPress vulnerabilities, so in 2022 for example hackers exploited a bug in a plugin that allowed the creation of administrator access. So these things happen regardless of how well known the plugin is, these can happen. So we need to take some mitigations. If I can move to the next slide please.

So what are the mitigations? So always audit and remove unused user accounts, especially admin accounts. And ideally, there are plugins that will automatically disable inactive user accounts, this is the best way. If you don’t want to use a plugin, make sure that every so often you audit admin accounts on the site, so if you’re not sure this account is history or not, look, the user can always ask us for access afterwards. Always always always keep WordPress core, themes and plugins updated. Have an update process, so whether you want to install updates as soon as they become available through automatic updates, that’s one end, at the other end you would want to test all updates in a staging environment before rolling them out to live. Typically this is used if you have a highly customized environment and you want to make sure that new updates don’t break your website, that’s fine obviously, but make sure that you are constantly aware when new updates are released, and that you test them as soon as possible. Use a custom role plugin to create custom roles keeping in line with the principle of least privilege, and as we mentioned in other threats, keep an activity log ideally with notifications, so when something that is high risk happens we are informed straight away. So next slide.

So yes, WordPress is a secure CMS and a lot of effort goes into making it secure, however we need to take ownership of hardening our WordPress website and security maintenance. Keep in mind security is an ongoing process, not a one-time setup or fix, which is why I intentionally say security maintenance. And using threat models such as STRIDE, whenever we are auditing our security systems, whenever we are auditing WordPress, we have something to go through, so is this done, is this done, is this done. Several mitigations, as we noticed in the presentation, help us across the board, such as keeping everything updated, having an activity log and such. These are the low-hanging fruits that have the best bang for buck, so always start from there so you cover as much as possible, especially if your resources are limited. If you can’t handle all of this in one go, pick the ones that help with multiple threats, start from there, bang for buck, and then as you iterate start addressing the other mitigations.

And very very important, stay informed. So AI has already started to change how cybersecurity works significantly. So for example, before, when it came to spoofing or spam, it was always some Nigerian prince. This doesn’t happen anymore so much, now it’s highly customized efforts. I received an email recently, someone pretending to have read one of my articles and they mentioned what helped them and how, and I could see that certain things didn’t make a lot of sense, but if you’re not looking for it it’s very easy to get sort of sucked in. So AI is changing cybersecurity significantly, which means we need to stay informed more and more. And now it’s making it harder to differentiate between something that is legitimate and something that is not. At the same time hardware advancements make it easier to for example crack passwords, excuse me. Passwords that don’t follow best practices can be cracked in seconds, in seconds. So some things like having a password policy is very very very important. So stay informed, read blogs, or watch podcasts, or attend bootcamps like the one we are in now, to basically make sure that you can stay ahead. That’s it. Last slide. So again I am Joel, I work at MelaPress as technical writer. I’ve been teaching since the start of my career many many moons ago, I’m quite old, and yeah, I really hope that you found this presentation useful.

Host: Yeah Joel, I think it is very insightful and very informative to understand the STRIDE framework. So let’s have a look on the comment section, I think we have some questions for you. And the first question is from Christina. The question is, someone warned us that activity logs use a lot of server resources, is there any way to mitigate that?

Joel Barbara: Yeah, actually it’s a very very good question. So when it comes to activity logs, it’s not that they use a lot of server resources, it actually depends on the number of users and how much activity, how active those users are on the server. So for example if you have five users who log in once a week, that’s one thing, but if you have 100 users who are logged in eight hours a day, that’s a very very different thing. So, one, you need to be careful of which plugin that you choose, so you try to test the different ones, see how much resources they use, and of course you need to make sure that the package you have comes with enough resources to handle the amount of activity you have on your web server.

Host: Great. So Joel, we have another question from Resty, and the question is, what security tools can we use on a WordPress site which would not negatively affect the site performance, and is there a minimum recommended server specification that would run these tools while maintaining site performance?

Joel Barbara: Yes, very good question again. And this all depends, as I mentioned at the start of the presentation, all resources are finite, so we can’t have unlimited resources, server resources, and we can’t have the fastest server in the world. So we need to understand how much risk are we willing to take on. Now having said that, so for example a firewall is very important, but the firewall is going to be examining all of the traffic that is coming in, so that’s going to use more resources than for example a 2FA security plugin, which works only when the user is logging in. But there isn’t a minimum recommended server spec, because it all depends on how much risk you are willing to take on.

So what I would suggest is first understand, this is the risk I’m willing to take on, I’m not willing to take this risk, so these are the plugins that I need, install those plugins and make sure that they are working. Make sure that you test different ones from different vendors, pick the one that you’re most comfortable with. Once you have that then do a test on your web server, how fast is it, is the response rate working within the parameters that I’m happy with? Yes, everything is fine. No? Then look at upgrading the server, or if not willing to upgrade the server then you need to reassess how much risk you are willing to take on. But the way that I see it, always start with which are the plugins that are a must for me, these plugins I need to have, install those plugins, once you do run the tests, is it fast enough? Yes, all is good. No? Let’s look at how we can upgrade the server, might need to look at a different hosting provider, or might need to spend a bit extra to basically get the next server up or next two servers up. But always start with, these are the plugins I need, this is the risk that I’m willing to assume, and work your way from there.

Host: Okay. We have the last question, that is related to logs. So Carlos is asking, what to look for in logs, how to systematically monitor activity to find suspicious activity?

Joel Barbara: Yes, very good question. So of course there are a number of things that we need to be on the lookout for. So for example a user logging in is not something that we should monitor all the time, however if a user logs in outside of their usual hours then that’s something that we might need to have a look at. As I mentioned earlier there’s the creation of administrator accounts, typically this is something that is very important. If a plugin got installed or removed, again something that we need to be on the lookout for.

Now, as a disclosure, at MelaPress we do have an activity log plugin called WP Activity Log. With using activity log you can choose what to log and not to log, so basically it gives you a list of all activities and you can choose, I want to log these and not these. Obviously keep in mind that what you do not log is lost, so I do not suggest it, but if you are short on resources that’s one thing that you can do. And then you can create notifications. Obviously log everything, because the information that you don’t have you are blind to, you can never know. So always log everything and you can always revert back to that information if something happens.

But for example WP Activity Log also has notifications, so you can build a notification like, if a user logs in between this time and this time send me a notification via email, and then once we receive that notification via email or SMS we can go back to the log and say okay, show me all logs of this user, so we can see if the user logged in outside of normal hours, we can see what they logged in to do, and we can get in touch with that user, make sure that this is a legitimate login. If we can’t, we can look at the log, see what they did, what they accessed, what they changed, did not change, and all of that. But keep in mind that it’s also environment dependent, so for example if you have an e-commerce store with WooCommerce then there are other things that you need to be on the lookout for. But again through notifications you can really narrow it down and keep the log, and then once you get the notification go to the log, filter it, I want to see activity by this user or activity by this IP, and then you can find if something risky has happened.

Host: It was wonderful from your side Joel, and I again thank you for the wonderful presentation. I hope people like it, learn from it. That’s it from Joel’s end, and I again thank him for taking time for this presentation and participating in the Security Bootcamp. So thank you so much Joel for your time.