WordPress Disaster Week: Session Two - Are You Prepared For a Security Incident?

9:26PM Mar 8, 2022

Speakers:

Nathan Ingram

Kathy Zant

Keywords:

security

incident response plan

site

hacked

incident response

customers

hacker

server

incident

plugin

happened

cpanel

file

compromised

question

breach

intrusion

agency

theme

people

All right, we're back with the second hour of day one of disaster week for 2022. Kathy Zant is back with us talking about being prepared for a security incident. Kathy, give us an overview of what we're going to cover here in the next hour.

Hey, Nathan, well, like I said, last hour, it's not. If your site's gonna get hacked, it's not if you're going to have a security incident. It's when bad things happen. So we're gonna get prepared today.

All right, it sounds like fun. So if you're just joining us for this hour, let me review that. The chatroom is i themes.com. Forward slash chat, we invite you over there. I think.com forward slash chat, I'm dropping in the slides for this session. There in the chat room if you'd like to download those and follow along. Also, there's a link to the live transcript down below the chat. And you can follow along with that if you'd like to, and replays of each session will be available in a couple hours now or two after we wrap up today. As soon as we can get those videos rendered and uploaded. As you go. If you have questions, please just drop them there in the chat room. And Kathy, let's get started.

Alright, let's get started. So last time where we had Star Wars, we're going to go old school with some movies again, in this airplane. I don't know if anybody saw this movie way, way back in the day. But it is. It really has a few scenes that underscore the importance of incident response planning. And interestingly, one of my first jobs was working for an airline. And the one thing that I noticed working for them in my younger years was that they had everyone there had this philosophy that when bad things happened, it was well, obviously when bad things happen in the airline industry, people fall out of the sky. And they treated everything that way. So if mileage plus was not available, it was mission critical that mileage plus be bad brought back online. As soon as possible. Everything was an incident, everything that affected the availability of systems needed to be solved as soon as possible. And you do not want to be in the middle of an incident in the middle of your site not being available, or your customer, your customers being redirected to malicious parts of the internet. And you're sitting in the pilot's seat asking if anyone is able to fly the plane, you want to be prepared. So that's what this is all going to be about. So first off, what exactly is a security incident. And in the security world, they think about this stuff all the time. So we're going to bring a lot of thinking from security and cybersecurity into the WordPress space. So they consider an incident is an event that compromises what they call the triad CIA, confidentiality, integrity, or availability of an information asset. An event is anything that you can observe. So this could be a hack attempt, but not necessarily a successful intrusion. And a breach is an incident that results in the confirmed disclosure, not just a potential disclosure of data to an unauthorized party. So a security incident is something actually bad happening, an actual hack, an actual breach, something terrible has gone wrong. This all sounds very boring. And before you look at me the way this gentleman is looking at TED sitting in the airline seat, we're going to try to make this as fun as possible. This, it sounds just daunting, and something that makes you maybe not want to continue on. But this is going to save you a lot of trauma in the long run. And the incident response plan is a document basically, that you're going to put together, that's easy to get to everyone knows where it is everybody knows that it's you know what in it, and that this is the go to place when an incident is detected. And someone's going to maintain this, keep it up to date, ensure that it's accessible to everyone who needs it. And the reason we're going to do this, the reason we need this is because we are going to try to minimize the cost and impact of a security event. We're going to make the assumption that a security event is going to happen Our site is going to get hacked. You can apply this to various things, not just a WordPress site. But here we're going to talk about WordPress, you're going to assume your WordPress site is going to get hacked. And your job is to ensure that the confidential is going to stay confidential, that the integrity of your systems and data is going to be protected that your site isn't going to get deleted. It's not going to get modified. Your customer data isn't going to you know get legs or isn't going to get modified. that everything that should be available to your customers or to your end users or to your stakeholders, whoever needs access should be available remain available. Why do we need to plan? I don't know about you. But if you've ever been in a terrible situation, say, a car accident, even something bad is happening, and your ability to deal with things can often look like what's happening here.

In this movie, when they realize that there's problems on the plane, people panic, when you are under stress, the first time I had a hack server, and it was just a white hat hacker who basically got in to that server that I mentioned in the last hour and left a little note saying that the server I had inherited had not been properly secured. Everybody panicked. Even my boss is panicked when I'm like, What's this mean? Everybody panics and our ability to process information when something bad is happening, goes down. When you are perfectly relaxed, your ability to process information is seven plus or minus two bits of information are associated the neuroscientists. And when something bad is happening, like when I got into a car accident in the middle of Phoenix traffic, and I didn't know what to do or who to call, or what should happen. Next, I turned to the side to the driver's side window where there was an 800 number, they call that number, because it was right there. That is why we need to plan because our ability to identify, eliminate and recover in the midst of a security event without a plan is, is pretty limited. So we want a plan in front of us. So we don't have to think about it. And we don't have to ask questions about who's going to fly the plane. Now, what's at risk? Why should this matter at all? You know, does it matter if your site is down for for a week? Um, does it matter if you have an intrusion, it doesn't matter if your customers data is exposed, if all of their personally identifiable information of your customers, shipping information and passwords and email addresses, and even their IP addresses, which is considered personally identifiable information. If that gets exposed, it means you if you're doing business in the EU GDPR comes into play. California requires that you disclose information. Nevada has privacy laws. And according to the National Cyber Security Alliance, 60% of small businesses go out of business within six months of a data breach. So there's a lot at stake. And in contrast, at&t did a study and they found that companies with high levels of IT security, show better outcomes. What does that mean? It means that with proactive policies, they average 24% sales growth over three years with 20% profit margins. And companies that don't pay attention to security, only experience 6% sales growth with 3% profit margins, I have a theory that this is just a symptom of corporate culture. When you have a proactive corporate culture, you're more likely going to pay attention to security, incident response and security have proactive policies in place. And you're going to be doing that in the sales and marketing arena as well. So good security is good for business. And you can tell your customers, if you're an agency, you can tell them that that's why they need I theme security Pro on their sites. Because good security is good for their business. And that's what you're there to help them do. Because making good decisions to manage risk before security events or incidents, protects your business. It's going to keep your business in business. And it's going to help you think through things in a more proactive way which will have outcomes in a cultural way. All right. Let's talk incident response. The security people love their models. This comes from the National Institute of Standards and Technology or NIST. And they have four steps for incident response. And obviously, we spend a lot more time in the first stage which is preparation. We have to think through all of these things and prepare ourselves detection which we want to do as quickly as possible because the faster you can detect it the faster you can fix it. We want to contain the threats and then we want to do post mortems after the incident so that it can inform us to be prepared for when and future security events happen because insecurity we consider the when that if the SANS Institute has six steps, I couldn't decide which one I wanted to take. So I'm letting you know that there's a couple of different ones. But we're going to walk through the SANS Institute, because they break it down into six different steps here. And so we're going to walk through all of these from preparation,

identification, what we're going to do in terms of trying to see what is different what how we detect an event quickly, containing that threat, eradicating that threat, and recovering bringing our systems back to normal or website backup. And then those lessons learned that lead to step one again, and prepare us again for the future. And then I want to just make one note, because I've been through this 1000 times 1000s 1000s, I don't even know, many, many times. And the most important part. And the thing that's going to underscore so much of incident response is communication, your shareholders or your stakeholders, if you're an agency, your clients, if it's your boss, if you are in an in a corporation, and the CEO wants to know what's going on with the website, it could be your customers, it could be your vendors, there could be a number, whoever is the stakeholders, they're gonna want to know immediately what's going on. And yet you have your security team, whoever you identify to be your security team who are going to be busy bringing things back to normal. And they don't necessarily need to take a break from that all the time in order to communicate with this with the stakeholders. So there's a number of things that have to go into place. And communication is going to be a big part of that, because you want your stakeholders to feel they're going to be in a state of stress as well. And you want to ensure that they feel well, well informed. But that you're also giving the people who are on the frontlines, the ability to really focus and get done what they need to get done. So let's jump into the hardest part, where we're going to spend a lot of time where you never feel like you get everything done. And that's preparation. So does your team have what they need in order to be successful in incident response? First, you have to identify who is on that team who is going to be involved in this should consider 24/7 coverage because a hack can happen 230 In the morning on a Saturday or a Sunday, who is going to detect that who's going to be alerted to the fact that an intrusion or a breach has occurred? What systems are involved? What's the scope of of this planning? Does? Is it just the website? Or are there other systems involved? Who needs to be informed? Who are your stakeholders? And what reporting tools will you use in order to inform them? If it's the CEO? Does he want to text at 230 in the morning, these are things that you need to define in your incident response plan. And this is going to be you know, I can't give you like a template and say, Okay, this is what everybody should do, because it's going to be different by CEO probably isn't going to want to know that something has happened, but somebody else in the organization might. Who is the person that needs to be informed? First and foremost, who are the people who are going to be on the frontlines? All of this needs to be defined for every single website that is under your tutelage. So what tools are you using? How do you assess the risk? So this is going to be you know, not necessarily saralee Or not only vulnerability report? Reporting. But this is also going to take into consideration what is the risk the entire business if your site is down? You know, back in the day, when I was working on the airline site, and I, we were going through an incident with with them. And this was back way, way back in the day. I'm sure it's it's higher now. But the risk assessment was $50,000 per hour. If this is down, if just this one piece is down. So these types of risk assessments underscore the importance of what's happening with your incident response, what tools will be used? So you may have tools, I think security Pro is going to be one of your tools, but you may need other tools. When it comes to going over Apache log files, how will you be doing that?

And then document everything. The last thing you need, if site has been hacked is to spend seven hours trying to find FTP information or trying to find your hosting providers information. I'm trying to get into the cPanel all of this needs to be documented and needs to be a part of that incident response plan. When something is done tected, you should be able to pull out your plan. And you should be able to find the information that you need and not run around trying to figure out what's going on. You need to make sure that you have your clean and tested backups off server. And Backup Buddy is a great tool. One of the best tools for doing this, if you're not using backup, buddy, now's a great time to get that because it can backup off server and can deal with even complex file systems. And then user training. Also very important, everybody that it can detect an incident and this could be somebody in customer support, who answers an email saying, Hey, I just something weird happened on your website, this may be your first indication. So user training is also very, very important. Practicing your plan, incredibly important as well. You can't take someone else's incident response plan and plop it into place and then try to practice that it will just expose all of the ways that you need to make this unique to you. So they call these in the security space tabletop exercises. So you come up with basically an exercise where you say, okay, plugin a has just been exploited or user B just had their password and their their two FA wasn't on and this happened. And you create a scenario. And your incident response team goes to work as if it is completely and totally real, almost like you know, in the army, the drill is going off, and everybody has to pretend that this is actually happening. Another thing that can be done is red team exercise where you can hire a penetration tester to actually test your website, test your all of your systems, and see if they can find vulnerabilities. It's basically an ethical hacker who comes in and pokes holes trying to find a problem within your systems. When do you practice you practice regularly? This isn't something that you're going to just write as an incident. Well, we have our incident response plan. And it is it was developed three years ago, and it's where we've been set and there haven't been anything, you know, that has happened since haha. No, no, this is stuff that needs to be practiced. And it needs to be updated. And this needs to happen on a regular basis. Maybe it's quarterly, maybe that's right for your business. Maybe it's annually, maybe it's twice a year. But if you're adding a new service, or if you're adding new people, whenever you're adding something new into the mix, your incident response plan should be a touch point, it should be something that needs to be looked at. Okay, well, we just added a new commerce endpoint. How does this play into our incident response plan. And then once you go through these exercises, you should also go through the reporting. As a part of the exercise don't just go through the exercise of what you would do and make sure that the plan is updated, but actually go through the reporting and investigation part of it as well. Practice makes preparedness and perfect, right? Okay, detection, very, very important. The faster you detect a problem with your website, the faster you can come to remediation. Here's the deal. Let's say you just got hacked 10 minutes ago, and your backup is an hour ago. Restoring from that backup sounds pretty good to me, you know, we lose an hour of data on a very busy ecommerce website, maybe something we can live with there. And then we can just like figure out what happened.

If you got hacked, and this when I was doing incident response and WordPress sites years ago, plenty of times people would come in and they just found out that they got hacked six months ago, three months ago, two months ago. And their log files were only available for the last 30 days. And finding out how exactly they got hacked was next to impossible because it was so old. Finding out that you're hacked and going into immediate response is the way to go. So you want to do vulnerability assessments with I themes security Pro as much as possible as soon as possible. Make sure you're scanning attack precursors. You've probably got bots probing. If you have WordPress, you have bots probing your WordPress site. But it maybe there's a baseline to that maybe this is normal probing, but now we have additional more targeted probes. And we're also getting all of these emails and their phishing emails that look like they're coming from our CEO but they're not and they're asking for specific information. These are things that mean you need to start looking at getting Incident Response Going. Another thing to mention is just log retention. Most hosting providers are only going to retain about 30 days of logs. And I highly recommend that you keep a year's worth of logs and that you also keep those logs off server so that not only you understand what your baseline is, but that if there is an incident, you know, maybe you had an incident that happened yesterday, but there were probing attacks 45 days ago, that would be good information to know. Because containment is something that needs to happen as quickly as possible, we need to verify what happened and prevent that situation from getting any worse. We need to identify whether or not the site's under active attack. Do we need to take the site down? Is there a vulnerability that is zero day that we need to that we don't have any kind of protection against we need to take down part of the site? Are there plugins that need to be deactivated and removed? Because there's no known fix for these types of things? What needs to happen in order to contain the threat? What can we figure out from this attacker? Is this a targeted attack? Or is it just general bot malware that you know is probably never going to come back. And then I was we have to prepare evidence for communication, especially if we are in a situation where we're going to have to report a breach to you know, because we are doing business in the State of California or, or wherever has privacy laws, maybe legal is going to have to get involved. Maybe you have cyber security insurance. And they require that you collect particular information, make sure that as soon as you identify that there is a problem. And this is all information that goes into that incident response plan. You want to know what needs to be retained, where is it going to be retained, and then also establish rules for chain of custody. So that if, for example, your site was hacked by a malicious disgruntled employee, an insider that's got access to things that they you don't know that it's down yet. But you should have a chain of custody to make sure that if you do have a disgruntled employee that's involved with these types of things, it's basically a crime scene that you're dealing with. And so you need to have particular rules all laid out in your incident response plan to go over all of this. Alright, eradication. I think blogging really helps here. Because you can see things like login attempts and discover where those initial intrusions came from. The intrusion factor is the vulnerability that was exploited the breached password wherever that initial breakthrough happened. And you need to identify that otherwise, how are you going to patch it?

For example, with the case that we talked about last hour with the 30 sites in one cPanel, easy enough to remove all the malware because it was just a giant Search and Replace, but determining where that vulnerability in that in 30 sites happened was the was the hard part. And figuring out the one user on the one site that had to add the intrusion? That was critical in order to protect the rest of those sites, and then break them out of all one cPanel? Of course. So we want to see what kind of backups we have available. If you have a backup from an hour ago, and you know, an hour's worth of data is okay. That's fine, what malware exists. And you have to assume every single password is breached at this point until you can identify that intrusion vector. Because if the hacker did run off with data, and they ran off with the information in the database, assume all of your WP admin passwords are in that database. No hashed of course, but they can hash them, especially if they have it off server, they can they can figure those out. So assume everything has been compromised, and that all passwords are no longer good for you. So here's a little lesson in reviewing log files, I was just going to go over this real quick so that you can see what a log file Apache log file looks like. And in this case, we have a hacker found an unfinished WordPress installation without a WP config file present and then went through the installation process and let's see what they did. So first we see the IP address and then the date timestamp. And then we see a get request in there getting WP admin slash setup config. And then we see that that was success. cessful with a 200 code, you know, like a 404 code means something's missing 200 code means everything is okay. And then we see, you know, like a long string that basically tells us you know what kind of browser they're using. And a lot of times we see those being spoofed. And then the next entry, we see a post, where they are basically posting information from that forum and setting up that WP config and that site to get that ready for use. And then in our last next log files, we basically see here, the same type of thing that they're basically logging in, we see get to WP login. And, again, we see a 200 code, meaning that's a successful login. And then we see the install process continuing are the referrer there being the installation process. And then we see them installing a plugin, because they're accessing WP admin plugin install. And yeah, the site has now been compromised with one of those plugin files that has backdoors in it. It's basically a zip file that looks like a plugin walks like a plugin smells like a plugin, but it has malware in it. Common intrusion factor. Alright, so we figured all of this out, we know how they got in. And now we need to bring it home, land the plane. Scary stuff here, we need to bring the site back to life. Do we have a clean backup? If we do, let's go ahead and use it, it's recent, we will just bring it back to life very quickly. This is why you want backups regularly. And if you don't, you're going to have to clean the site. You might even need to take the site offline while you're cleaning it. If it has malicious redirects. I mean, this is obviously determination that you're going to have to put into your incident response plan, if the site is so infected, that it's going to be of damage to our customers, we're going to take it offline. If it's not, we're going to leave it online while we clean it up. And we make sure it's okay because our backups not, you know, we don't have a recent backup because it's taken too long. So this is the process we're going to go through in order to clean it. You have to assume that everything that that PHP that the user that runs PHP, everything that that touches is compromised. So everything if you're in a cPanel, everything under public HTML, that's all compromised. Maybe even everything in that hosting account, you'll have to review all of that as well and make that part of your incident response plan as well. So here's what we do, if we're going to bring it back to life. And we have to clean an infected site, we're going to back up that that infected site, because that's also evidence, right. So we want to save that off. And then we're going to extract that backup someplace maybe on a local computer, maybe on a special server that we have set up that we're going to clean from. And then we're going to clean that clean that entire site, clean all the files, we're going to check the database, maybe they injected JavaScript into all of the posts on the site, we need to inspect everything we need to look for extraneous users, sometimes hackers will add additional users. So everything needs to be reviewed, everything needs to be looked at, verify that the site is cleaned. And then what we're going to do, we're going to replace the live infected site with the clean sites, we're just going to swap those out. So maybe we extract out public html clean, and then change the name of public HTML to infected and then change cleaned over to public HTML, it just replaces the whole site. You don't want to clean a site on the server.

Most hackers when they get into a site are going to litter the whole site with backdoors because they know that eventually you're going to figure out that there's that your site is infected and they're going to leave backdoors around so that they can get back in once you discover that something has happened. So you want to clean the whole site and then swap it out. So you need to inspect every single file you know one thing that you can do is just get like a clean copy of WordPress and then clean out the directory WP includes and WP admin and then clean out all the just replace with known clean versions of all of your files. And then you know that that's one way of doing it or just inspecting every single file or calling in remediation help if that is this. It's a big job, if you haven't done it before, it can be a big job. How are you going to handle it? The big important thing to do is to put into your incident response plan? How is it going to be handled? Are you going to call someone in? Are you going to try to do it yourselves? How is it going to be all that needs to be documented? And then once you have the clean site up and the site is recovered, change all of your passwords, FTP, hosting account cPanel. All of your administrative users, you might even want to have your customers, how are you going to communicate with your customers? Another thing that needs to go into the incident response plan? If you have an E commerce site, you're going to explain to them that there was a breach? How do you know if their information has been compromised? And what do you say to them? Put all of that into your planning? And then when you are recovering, you know exactly what it is that you need to do. And then you need to prepare for the next one. What happened? When did it happen? How did it happen? Did our team respond? Well, was the incident response plan useful? Where was it not? Where did we not think through something? This is why you need to practice because no one can tell you you know, all of these things need to be covered because each site is so individual. Each you know site and each hosting provider is so individual. So you need to take responsibility to document all of this. And a big question, what information did we need sooner, because as we notice, time is of the essence. If you know that your site is infected, you rush into your incident response plan as soon as possible. And what what tools What have made responding to this much easier. Now, I think security gives you a number of tools in order to prevent these types of things from happening, but also has you covered for when you're dealing with these types of incidents, there are so much reporting available, there are so many different tools that can give you what you need in order to figure out what went wrong where so definitely make sure that I theme security Pro is one of your tools. But there's some other places to go as well. And your stakeholders are counting on you. sans.org has a number of tools available for your incident response planning. And NIST also has some advice as well. And if you do just a Google search and incident response planning, you can find a number of different resources. California actually has an actual PDF that you can download that will get you started and thinking through all of the questions they might want to have answered. So you can do a Google search for California incident response plan, and that will that will show up for you. There's so many resources, resources in the security world that we as WordPress professionals can take advantage of. And you know, as we've learned, security is our responsibility. It's everyone's responsibility, because in a lot of cases, humans are the weakest link. And I themes gives you all have the tools in order to make your humans less of a weak, weak link and give them the tools they need in order to make good security decisions. And that's all I've got. I know this is a lot. And hopefully I didn't scare anyone off. Maybe a couple of people who are like, Oh, geez, maybe I'll think about that. If it ever happens, and thanks for sticking around. Because I know you guys know that planning for the worst makes the worst seem less of a bad thing when it happens. That's all I got.

Definitely. Thank you, Kathy. Great stuff today. Folks, if you have questions that you haven't asked yet, please use the chat room at i think.com. Forward slash chat. I themes.com forward slash chat, really only have one question in queue right now. So there'll be plenty of space. If you have a question to get over to Kathy Ernesto just had a question for you, Kathy. And it's fairly broad, give you some some room to answer here. He asks, What extra measures do you recommend when you're a web design agency diving into security? So we've talked very broadly here? Where do you where would you start, I guess

if I was an agency, and I was well, first of all, I'm selling security to your customers. And I know Nathan, you're going to talk about this in a couple of days. Right? This is like day three. Yeah. So make sure you definitely attend Nathan session because he's definitely going to help you. Selling security is important. It's incredibly important because like, it's not just about you. It's not necessarily all your responsibility. You know, if I talk about that that agency that had the 30 sites in the cPanel, nothing he did wrong, he was a smaller agency. And it was nothing he did wrong that that caused all of his customers on that cPanel to get hacked, it was one of his customers that had a reused password and had a problem, and it affected all of his sites. So talking to your customers about security, does a number of things for you. First of all, it helps them do better in their business, you know, that the slide I had earlier, where we talked about how people who are proactive, or organizations that are proactive, with security, have better business outcomes, their sales and marketing is better, you're enabling your customers to make better decisions and to be more successful. And if they're more successful, they have more business for you. So that kind of security partnership is really, really helpful. It also is a differentiator for you in your agency, because I can guarantee you that most agencies don't want to talk about security, they want to talk about, you know, this new logo and this colors and all the fun stuff, right. But when you go into an agent, as an agency, and you go into a customer and you start talking about security, what your customer hears is, we're going to create something that's so valuable for you that you're going to need to secure it because it's going to be an asset. And so it gives you a differentiator when you're going up in competition against other agencies. So baking security into every aspect of your business is good for your business. In terms of like apps, sides of things, you know, just making sure that you have good processes in place, making sure that the people who are in charge of maintaining and updating your sites, you know that they have staging servers, that they can make sure that updates go well, that they have a prop a process. And you have policies in place for keeping everything updated, that you have tools in place. Like I theme security Pro, and I'm fairly certain we have great pricing for for people like you, making sure that you have those tools in place so that your apps team can make good decisions, tools that your customers can use that help them make good decisions. Just baking security into every aspect. And every touchpoint that you have with your customers is going to make your business more successful. And there's so that's my, that's my stick.

It's a great answer. And yeah, we'll be focusing in on that on Thursday, two hours I'll be doing on working with clients in regard to security, not only how to talk to clients about security, but also how to use AI themes, products to put together a WordPress care plan package that you can offer to your clients. So that's really our focus on Thursday. And hopefully you'll be back for that. Let's see, William had a question here about how you price your security sales offers and what criteria differentiates prices? And again, William, I'd invite you to come back Thursday, cuz that'll be a great focus on exactly those issues. On Thursday afternoon, Jack has a question. If you're not a WordPress professional, how can you determine if you get a file change warning from our theme security if your site is compromised? And Kathy, if you want to add to that, I would just invite you, Jack to come tomorrow when Michael and Timothy are here. We're going to be focused just on I think security. And Kathy, unless you have something you want to comment on that.

Yeah, I can comment on that for sure. Because I'm you know, I get those notifications as well. And it's so so if something has changed, and I know that it's reasonable that it's changed, let's say for example, Cor just had an update or a plug, I just updated a plugin. And you know, having good documentation, if you have an agency, and you have a number of people who do this, documenting what has happened when so like, James went in and updated, you know, this particular plugin on these five sites so that when those alerts come in, that file changes have happened. It's when things get changed, and you're like, Okay, I didn't update Elementor I'm just pulling one. I didn't update Elementor it hasn't had an update recently. And there's like these new files in there that have weird names. A lot of times they'll they'll name like backdoors like these ad names or things that just it just doesn't seem right. It's out of the ordinary. Those things I would just definitely investigate just get into via FTP and take a look at those files. And if they look like they're obfuscated PHP code, then assume your site is has been compromised and put your incident response plan into place or into action.

Yeah, very good. Chris says just out of curiosity, do you have any idea If most hackers are in the US or they overseas,

ha, here's the deal. They're all over the place. And you might see intrusions coming, or intrusion attempts, or even brute force attempts coming from not to pick on anyone but Scottsdale Arizona. That's probably not necessarily a hacker in Scottsdale, Arizona, but it's probably a GoDaddy server that has been compromised and is being used in a command and control type of way by a hacker anywhere in the world. That is, then you know, using that particular resource in order to command and control a larger initiative. And you know, we've seen hacks coming from all over the place, they that might be somebody hack hacking from Algeria, you might see a hack coming straight from Algeria. But it's very rare that hackers are like, exposing their home IP address, they're normally using some other type of resource, whether it's a spun up server somewhere AWS is often used. They shut it down pretty quickly, but they typically use resources from elsewhere. So you might see something coming from, you know, Oregon, and it's just, you know, AWS servers that are being used.

Yeah, for sure. So following up on that, you know, a lot hackers are using other server resources to do their dirty work, that Paul is asking, Does blocking an IP address really matter? If so many are spoofed or used as a pass through?

Oh, yeah, that's the thing is, they know that you're on to them eventually, right? So they rotate through IP addresses pretty quickly. Um, to me, it's, I don't even think about blocking stuff, honestly, I have, like, on my servers, I have Cloudflare. And so generic types of attempts, you know, they are pretty good at blocking those types of things. And, you know, I just make sure everything's like, you know, tightened down, and then I have intrusion detection with, with it and security and stuff. I'm blocking IP addresses it, they just rotate the truth through them so quickly, that it to me is, you know, it's like playing whack a mole, you can block that IP address now. But, you know, could be a problem, you know, could be the same exact hacker using a different IP address an hour later, even.

Right. And, you know, that's the beauty of the way I theme security approaches, that sort of attack is you can set it, we'll be talking about this in more detail tomorrow. But you can set thresholds where if a if an IP is being used and multiple, invalid login attempts or whatever, all that hat, like you're not actually having to sit there. I want to block this IP and clicking a button. It's all happening automated behind the scenes. So as I believe William mentioned in the chat, blocking the IP offers temporary relief, but it's not really getting to the heart of the issue in many cases.

Exactly. Right. Yeah, I mean, most of these attacks are all but it's all bot driven. It's not like a dude sitting in his basement in a hoodie. Like, I'm going to get into this blog. It's a dude with, you know, an army of bots. And so the great thing with the army of bots is there's a lot of pattern recognition recognition with them. So you can use automated protection, like I theme security Pro, to protect yourself.

Right. All right, I believe that's gonna bring us to an end for questions. Great stuff today. Kathy, any final thoughts as we're starting to wrap up?

No, this is a lot of fun. I was really happy to participate in all this. It's, you know, security is very interesting to me. There's, it's always something that you got to kind of keep in the forefront of your mind. And so it's exciting to me to see i theme security pro putting on disaster week, this week to keep everybody on their toes here. It's great.

Definitely. And before I give you a quick preview of what's happening tomorrow and Thursday, let me just again, remind you that there are two really good deals over in the sidebar beside the chat room 40% off the things plugin suite using the code disaster 40 are actually those links have now been updated to be direct purchase links using those coupon codes. So if you don't have a license for I think security, you can grab 35% off or just get the full plugin suite, which is all the plugins that I themes offers with a lot of things, including I think security Pro, and that suite is 40% off those deals are good through the end of this week. Just use those links over in the sidebar. Now tomorrow. We've had a great overview of WordPress security today. Cathy's done a great job getting the big picture of security. Now tomorrow we're going to be specifically talking about using I theme security Pro to protect your WordPress site. In the first hour. We're going to hear from Michael Moore, who is one of our security experts, and the Product Manager here at AI themes, about seven ways to detect and stop malicious behavior on your website and those specific features, and I think security Pro that are going to help you do that. And in the second hour, I'm super excited about this. We're gonna have Timothy Jacobs back with us. Timothy is the lead developer for I theme security. He's a WordPress Core contributor and one of the maintainers of the WordPress REST API, that Timothy is going to give an advanced talk that's focused on the I think security dashboard, in depth customisations with actions and filters, and even some WP CLI commands that make working with I think security even easier. Now. This is the first time in all the webinars in years I've been doing this, that we've ever had that Developer Focus talk on security, with our own I think security and I am absolutely thrilled that Timothy is going to be with us to talk about that. Now, even if you're not a developer type y'all Timothy, if you've ever heard him present, makes very complicated subjects very easy to understand. So it's gonna be a great talk. We've not ever done a security talk like Timothy is going to give tomorrow. So that's all tomorrow, one to 3pm here for disaster week. Now, Thursday, as I mentioned earlier, briefly, we'll be talking about how you provide WordPress security to clients inside of a WordPress care plan. I'll be talking about, you know, how do you explain the need for care plans to clients, how security, you know, good analogies and words and phrases to use when talking to clients about security, and then also how to actually create a care plan using iframes products that you can then sell to clients. So it's going to be a great week, all about, I think security tomorrow and client work on Thursday. And that's gonna be it for today. So thanks for joining us. Hopefully we'll see you back here tomorrow. 123 on I think training where we go further together.