DE{CODE}: Keeping Your WordPress Sites Safe Amidst A Rise in Global Cyberattacks
Join experts from WP Engine and Cloudflare for this security-specific session on how to lock down your websites. The discussion highlights recent cyber attack trends along with specific examples of how WP Engine protects your sites. Developers will walk away with a clear checklist of steps to take for securing their sites.
Session Slides
Full Text Transcript
ERIC JONES: Welcome to DE{CODE}, and thank you for joining what promises to be an incredible breakout session. My name is Eric Jones, and I’m the VP of Corporate Marketing here at WP Engine. I couldn’t be more excited to moderate this discussion today between Joe Sullivan, the Chief Security Officer of Cloudflare, and Brent Stackhouse, the Vice President of Security for WP Engine, who between them have decades of experience in security.
Our discussion, Keeping Your WordPress Sites Safe Amid A Rise in Global Cybersecurity Attacks, could not be more timely given that cyber attacks are not only on the rise, but they’re at all-time, record-breaking highs. Joe, why don’t we begin with you? I’d love to hear from a broad, macro perspective what trends you’re seeing in the cybersecurity landscape.
JOE SULLIVAN: Sure. I’m happy to jump in. Thank you for inviting me to this conversation. I’m also really looking forward to it. I think there’s two, I guess, megatrends in the world of security right now. Number one is it is much more important in the eyes of the world.
So before we get it to the technical side of it and the actual challenges that we face day in, day out, it’s worth taking a moment to look at how much the world of security has evolved since Brent and I started in this profession, as you said, decades ago.
Security is not a team or a concept that sits off in the corner of an organization anymore. It is central to everything we do. CEOs are being held accountable. Boards are asking hard questions. Venture capitalists won’t contribute unless they see the right level of investment.
And, more importantly, our customers and consumers and business buyers of our products are demanding much more of us. And so that, to me, is the most important trend and why we’re having this conversation. It matters to every developer in every aspect of their work.
So turning to what’s actually happening in the world of security, it’s not getting easier. And the challenges just keep coming at us. If you’re paying attention to the headlines, you’ve seen over just the last little while the rise of ransomware. It’s really scary.
Ransomware changed the game in terms of security because it went from stealing some data or exposing something to the world to shutting down your business. And so the whole concept of the importance of security got magnified by that risk, the idea that we could wake up in the morning and not be able to turn on our laptops, not get our website running. That’s really scary.
Geopolitical things also are really starting to impact all of us. The situation in Ukraine is not contained to the physical world. It’s heavily in the cyber context right now. And it’s spilling over to impact the rest of us. So geopolitical events that are happening in the physical world have technical implications for those of us who are trying to operate businesses that are on the internet.
And I think the third thing I would mention from a technical standpoint is that we don’t live in worlds of our own code. We live in worlds that are an amalgamation of software and code that comes together to represent an organization.
And so, in security, we use the term supply chain to talk about all that other code and other applications and everything that becomes part of our identity as a company. So, for example, when there were recently stories about Okta being compromised, that wasn’t just a question of whether Okta was compromised. It was a question of whether my company and all the other companies that use Okta are compromised.
And my customers didn’t care about Okta. They cared about their use of us, and what controls did we have in place to mitigate the risk of Okta being compromised? So there’s just a lot going on right now. And it’s a good time to have this conversation.
ERIC JONES: Joe, just as a follow-up question, how do you think about the prioritization of all of those specific challenges that you have and that every security organization has?
JOE SULLIVAN: Sure. I think that’s the ultimate question. If we had an unlimited budget and unlimited people who could do the work, we could do it all. But that’s not the reality in any organization at any stage of its development.
So we’re always in the process of prioritization. And so what I would say is you have to prioritize the basics first. It’s shocking what a large percentage of the compromises come from failures in the basics.
As security professionals, we love to go dig into that zero-day attack or O-day attack and look at this really complicated thing. But 90% of the time, the compromises come from phishing emails or somebody choosing to use the same password that they used on a personal website that got compromised and not turn on multifactor authentication.
A lot of the times, we actually have the tools to do the basics well, but we don’t take the time to implement them.
ERIC JONES: Yeah, I think you’re hitting on a crucial point in security, right? That it’s something that we’re all responsible for. It’s a shared responsibility across the entire organization. It doesn’t live just within the security team. It lives with every single employee at a particular company.
Brent, turning to you, from a WordPress perspective, what’s the same, what’s different in WordPress, and what are some of the biggest points of vulnerability that you see in the landscape?
BRENT STACKHOUSE: Thanks, Eric, and thanks for inviting me. Appreciate sharing time with Joe. He knows a lot of stuff. We’ve been around the block a couple of times. So this is fascinating.
WordPress in many ways– the news is generally good in the sense that WordPress Core as differentiated from all the plugins and themes and other things in the WordPress ecosystem. WordPress Core continues to be robust and resilient against common attacks.
So WordPress itself is a good, stable, strong platform that customers should generally feel comfortable using in just about any context. The challenge is mostly in the plugin side of things, where wordpress.org or those core developers don’t have anything generally to do with most plugins and themes.
And the code quality variability, similar to apps you’ll get in Google’s Play Store or something like that, those are not written by, as I was just saying, Google. They’re not written by WordPress, these plugins and themes and it could be anything from a single developer to a team. The footprint of those plugins or themes could be very small to very large. They may have a good history of patching things quickly or not.
And so it depends. So, as WordPress grows in popularity, and the ecosystem grows in popularity, you can assume that attackers will continue to ramp up their efforts because attackers go where the money is, similar to why Windows has more malware than Macs in general. That’s because that’s where the footprint is, and that’s where the money is.
So WordPress is no different, and as it increases in popularity, you can expect the attackers to keep doing what it’s doing. The good news is, compared to when I started the WP Engine four years ago, the ecosystem is largely healthier.
Plugin developers, theme developers are more aware that they are going to get inputs from security researchers or other people noting vulnerabilities. And most of them are responsibly building that muscle so they can turn around patches very, very quickly.
So things are much better than they used to be. Four years ago, lots of developers were surprised when vulnerabilities happened and they weren’t really all that rapid or able to meet the needs of their customers in terms of patching regularly.
All of us as technology consumers are used to, quote unquote, “Patch Tuesday” or our regular updates from Apple, et cetera. So we’re not surprised about vulnerabilities. We would be, however, very surprised if that vendor did not patch something responsibly and quickly.
So the WordPress ecosystem is in general healthier than it was, I think, four years ago. Again, WordPress Core is great, but the plugins and themes are, I think, generally keeping up. So that’s quite a positive.
ERIC JONES: Just to double click on something that you said about WordPress Core, what is it about just the very nature of open source software that maybe helps with that issue around it being secure? Because I think that’s one of those misconceptions and myths that’s out there that somehow open source software is not fundamentally secure.
BRENT STACKHOUSE: Well, that’s a great question. And I’d be interested in Joe’s thoughts on this. And not to throw a curve at you, Eric, but I’m old enough. I’ve seen what we mean by open source change quite a bit over time.
Open source back in the day used to be very well-known projects like out of Apache, or, say, OpenSSH, or, say, Linux, and things like that and so when we say open source back then, that’s what we typically were referring to.
And, yeah, there was lots of secondary, tertiary, whatever smaller projects out there that were not nearly as well maintained, etc. Now what I think we mean by open source is virtually anything that’s in GitHub, anybody posting anything out there that anyone else can grab.
You’re talking about libraries, very small code that anyone could say, oh, that looks great based on its features, that we’re going to incorporate that. And I’ll talk a little bit later as Joe alluded to with supply chain issues. I’ll talk a little bit later into the developer-specific challenges in terms of supply chain risk mitigation.
Because open source– I think back to your question, Eric, about WordPress. It’s great that source is out there. Lots of people are looking at it. I think that’s also true back in the day with Apache and things like that. Anything that’s used in a widespread basis is going to get a lot of scrutiny both from the good guys and the bad guys and I think that’s a good thing. Security through obscurity has never been a good practice. And so having the code out there is great.
But open source equaling better security than closed or vice versa is a hard question to answer. Because they literally are apples and oranges. I think WordPress as a team has done a great job using other inputs other than their own intelligence such as using a bug bounty program. WordPress Core has been doing that for years. I think that’s smart.
They undoubtedly have unaffiliated researchers pinging them on a regular basis with their findings. And smart teams take those inputs and do the right thing. I’m sure they’re getting pen tested themselves, etc. So we do similar things at WP Engine, but that’s sort of par for the course.
Joe, any thoughts on that? Sorry to take it over, Eric, but–
ERIC JONES: No, that’s perfect.
JOE SULLIVAN: I think you hit a lot on the high points. When I think about open source soft– when I think about software from any source, I think we have to evaluate it before we put it in our environment. And sometimes open source software is going to be the better choice than something that’s proprietary. Because you know what? Sunlight kills infection.
And what we with a lot of open source software is that a lot of other people are also looking at it. I think that’s something in the world of security in general that we don’t do well enough is we all sit in our little teams and corners, and we try and solve everything ourselves.
Getting the community involved is a good thing. Transparency and dialogue about risks around particular pieces of software is a good thing. And we’re getting better at it. Your example of a bug bounty program is another way of bringing transparency and inviting third parties to poke holes.
Open source software has lots of people looking at it when we’re talking about the most used and most important pieces of open source software. But in the same way, I wouldn’t just grab some code from GitHub and drop it into my product without really scrutinizing it.
I would also say that you need to exercise the same caution when you’re purchasing a license to software that’s proprietary. You still need to look at who’s making it, what practices do they have, and how robust is it.
BRENT STACKHOUSE: Yeah, a lot of it’s about– and this is a risk nerd term– but about assurance. What assurance can we gain for anything that we’re doing in a technical sense of how secure are once we do A, B, C. And a lot of assurances, depending on the situation with closed source, it’s tougher to get.
In open source, you can get a better feel more easily of who’s done what to check out the code. It’s a little trickier with closed source. You’re having to use indirect inputs that show that this company has had good security practices over time, etc.
But, yeah, gaining assurances is at the end of the day what you’re trying to do when you’re deploying, using whatever technology in general. Thanks.
ERIC JONES: So, for the developers that are out there, what are those specific assurances that you both look for in companies? If these projects or pieces of software have these things, you then consider them to be good, to be a little bit more secure than they might otherwise be.
BRENT STACKHOUSE: Do you want a WordPress answer? I’ll let Joe go if you want to start generally.
ERIC JONES: Yeah, Joe, if you could provide maybe a broad perspective, and then, Brent, you can provide the more specific WordPress perspective.
JOE SULLIVAN: Yeah, so, from where I sit, I think about that question as a buyer and as a seller because I work at Cloudflare, where people are implementing our products. And the number one question that any Cloudflare customer has before they implement Cloudflare is, should I trust Cloudflare? Because we’re sitting in front of their entire business. And that’s a really risky place to put someone unless you trust them.
But I also, because we’re growing and need to build our products, we rely on third parties as well. And so I’m on the receiving end of the hard questions, and I’m on the asking end of the hard questions.
And, look, none of us has the time to go or the resources to go in and audit every single time we’re going to work with a third party. We don’t have teams large enough. We don’t have the skill set to. So we start with the security certifications as a concept that matters here.
When I say certifications, I mean things like a SOC 2, a SOC 2 Type II like WP Engine has, or the ISO 27001, or PCI. When you hear those words and certifications, what you should think is a third party used a recognized set of standards to go in and audit that company and evaluate whether they were meeting all of the controls for that area.
And so each of us– Cloudflare has a SOC 2 Type II report that we can share. WP Engine has a SOC 2 Type II report that we can share. And the nice thing about when I say Type II, it means that it wasn’t just a point in time audit. It was an extended period of time.
So, for example, with our SOC 2 Type II, it means that over the last year, at any point during that time that that certification exists for, we were in compliance with those minimum security controls. So often that’s enough for a customer. Like, oh, that company has a SOC 2 Type II. OK, I will trust them.
But then you might want to dig a little deeper based on your specific implementation. So when I think about buying a product, I think about not just the quality of the code, but how it integrates with my environment.
And so something that matters a lot to me is authentication. Can I integrate that with my single sign on so that I can manage who inside my organization and outside my organization has access to it? Because that’s where, like I said earlier, a large percentage of the security issues come from.
So you want to choose products like WP Engine, where you can integrate it with your SSO and let the security run through the tooling without you having to do a lot of hands-on work. So, to me, it’s certifications plus the combination of everything else that you want for your specific environment.
ERIC JONES: And, Brent, handing the question back to you, how do you think about that in a WordPress context?
BRENT STACKHOUSE: Yeah, I think that’s great. When folks are looking at extending the WordPress ecosystem, so to speak, by using plugins and themes, a couple of things to look for just even from a business context or business layer is, how popular is this given piece of code, plugin, or theme? And can I see in their changelog that they are updating on a regular basis, including for security updates?
Those are very qualitative measures or inputs, but they’re still relevant. Typically, plugin developers or theme developers that have a big footprint– they’ve got a lot of customers– they’ve got something to lose and gain, so to speak, by maintaining their code well or not well, depending on which way you want to flip that. And so simply going for the common most popular ones for whatever you need is generally a good practice.
At a developer level, you can apply more control, so to speak. You can use static application security tools for a given plugin. Are you likely to find something that another security researcher hasn’t? Perhaps not, but it’s still a good idea to run those things through whatever your tooling is. And there are plenty of open source free tools out there or even commercial tools with very low cost or free licenses that can enable you to gain better assurance over whatever code you’re using in your environment.
One thing that Joe touched on that I’ll talk to you a little bit, too, is WP Engine is also both a consumer of code as well as a producer and so we are also a service provider and very concerned about the integrity of our end-to-end development efforts. And it’s an ongoing challenge.
So one of the things for our developers out there running WordPress sites is they should be aware, hopefully, of their organization’s context about risk. What vertical are they in, for example? How much tolerance does the organization have for bad things happening? Certain sectors or organizations are much more susceptible to things like DDoS attacks, etc.
So thinking about that and potentially coding for those things, you can’t code for DDoS, but you can certainly be aware of it and surface that up. It’s very important for, I think, developers doing the right thing.
ERIC JONES: Switching gears a little bit, and with the goal of trying to provide some very specific recommendations, Joe, from a high-level security perspective, what would you recommend that website owners do to help shore up their security?
JOE SULLIVAN: Yeah, so the way I think about it, an ounce of prevention is worth a pound of cure. And, in the security context, that means choosing the right tools and platforms that you’re going to use before you start rather than trying to build something, and now let’s figure out how we bootstrap security on top of it.
So, when you’re selecting platforms, when you’re selecting tools, when you’re selecting code, you want to think about it with security in mind from the start. And so, like I said, if you can get the security to happen automatically through the tools that you choose, you’re going to be in a lot better place than if you have to hire people to come in on the side and do a bunch of audits, and then try and fix everything while the ship is cruising through the ocean.
You can’t patch it that way. And so, for me, I’m always looking for, what do I get out of the box from a security standpoint? What are the settings that are there for me? And if I take the basics of security, I think there’s just actually a few areas.
Number one, for me, is always that identity and access management. So that’s why I talked about the ability to integrate single sign on from the start. If I was starting a company I would, one of the first things I would choose would be the right single sign-on setup that will scale with my organization. And I would always try and choose products that will integrate with it.
The second thing I would think about is, OK, I’m going to have a bunch of code facing the internet. How do I withstand attacks from the internet? Am I going to have to go by my– Brent mentioned denial of service attacks.
Do I have to personally figure out how to have load balancers and manage all that and buy products like Cloudflare? Or does it come built in with a platform that I’m purchasing so that I don’t have to think about security. I know that it’s already there built in, and so on. So I would methodically go through my employees and identity and access management, the internet-facing code.
And then like the third pillar is probably– that we’re not really talking about here– is, how do I set up the laptops and things like that?
ERIC JONES: And, Brent, maybe going over to you, what are some specific things that WordPress developers should be thinking about to build the most secure sites that they can?
BRENT STACKHOUSE: Yeah, my initial response is it’s interesting. A lot of what we’re talking about is a decision around when to build versus buy. Are you going to build your own plugins and all the things you want to do to extend your WordPress ecosystem? Or are you going to buy so to speak even if it’s free?
But this applies to, I think, Joe and I, too, in the sense that we consume other folks’ code through GitHub or whatever mechanism and we could conceivably hire developers and do all that from scratch. Or we can use something that someone else has already done.
And why recreate the wheel when you don’t have to? But then how do you gain assurance that the code you’re using is in good shape? So back to WordPress specifically, I think there’s a couple of things– this is probably common sense for a developer audience, but we’ll say it anyway. When you’re coding, code securely, meaning know what you’re trying to do. Try to bound what you’re trying to do in terms of either your functions, all those kinds of things.
But keep the OWASP Top 10 in mind. OWASP Top 10 is probably well known to our audience. But, again, the basics are important as Joe alluded to earlier and so basics for developer certainly includes OWASP Top 10.
And then use one of those static application security tools that I mentioned that’s very good pre-deployed or while you’re deploying. You can do it automagically, so to speak. And make sure that the code you’re sending out there is actually in pretty good shape and that there’s no known obvious vulnerabilities with your own code if you’re developing custom code.
The third thing ties back to the supply chain issue we talked about. And GitHub has some free functions that can actually tell you when your upstream dependencies have known vulnerabilities. So Dependabot, a dependency bot, is a great thing that GitHub provides, and you should absolutely have that enabled on your repos. And it can actually create PRs automatically. And then you’ll have the option to merge that if you think you need to so that your upstream dependencies at least don’t have any known vulnerabilities.
Presumably all code has bugs even when you ship it and it’s got a subset of that is probably security bugs, but at least we need to avoid the obvious challenges that Joe alluded to earlier. We don’t want to get in the papers because we miss the obvious. Like, hey, you should patch things. So, yeah, those are three things I think developers could keep in mind to keep themselves out of the fire, so to speak.
ERIC JONES: I guess the question for both of you is, what are the things that you see coming down the pike that aren’t quite on the radar right now? And what are the things that folks, developers, website owners should be thinking about that they aren’t right now? And that’s a question open for either one of you.
BRENT STACKHOUSE: Well, yeah, I want to jump in because Joe answered the Okta thing earlier. So that particular group– this is interesting. So we’ve already seen it. So I can’t even say that this is almost coming down the pike.
But the group that exploded Okta and also other big names that we don’t need to mention on this podcast or this interview necessarily, they use very, very interesting social engineering techniques primarily, not very technical attacks at all.
And so maybe developers aren’t susceptible to this kind of an attack. It depends on the organization and where that developer fits in. But certainly anyone acting as an IT staff or person with access to assets, so to speak, for a given organization could very well be targeted by social engineering attacks.
So that’s something we don’t like to talk about because we can’t just technically fix it. But humans honestly continue to be the soft spot. Going through the front door as we call it, meaning an external attack, that’s often technically harder and more work for attackers. And sometimes, or oftentimes, they’ll go through social engineering attacks. Phishing is still very, very effective through whatever medium.
So I think that’s something that is proving to be still a challenge. And organizations probably don’t focus their time on that nearly as much as they should.
JOE SULLIVAN: Yeah, I think another way of saying what Brent said in a slightly different voice is I actually don’t want developers to be spending a lot of time with a crystal ball, trying to anticipate the next security issue. It’s more important to get the basics right.
And those basics will take care of most of the next big thing, whatever it is. And by way of example, I mentioned there’s been a fundamental shift in terms of the emergence of ransomware. It has brought companies to a standstill in a way that cybercrime never did before.
But it’s not like you go out and buy a product to block ransomware. You go back and do the exact same things you should have been doing already to deal with the prior threats. What is ransomware? It’s malicious software that gets placed in your environment.
Well, anytime an intruder gets into your environment, it’s bad. So we have the right– if we just keep focusing on the perimeter and not letting our employees get compromised or our code get compromised, then we don’t have to deal with ransomware.
So instead of sitting and worrying about what’s the next ransomware to come along, just keep focusing on the basics. And let the rest of us in the world of security speculate about the future.
ERIC JONES: Joe and Brent, thank you so much for your perspective, your time, and your advice today. So much to think about from getting the fundamentals right, the importance of transparency, what to look for from an insurance’s perspective.
And then maybe the most important thing of all is security should never be an afterthought. You’ve got to get it built in right from the start. I encourage everybody, if you’re interested in learning more about WP Engine or Cloudflare security offerings, please do check out our websites. And, of course, at WP Engine, we do have a wealth of security information available to everyone on our Resource Center if you’re interested in a specific WordPress perspective. So, again, to all of those who tuned in today, thank you for spending your time and for joining us today.
