 Yeah. Welcome back to Drupal South everybody. It's been a couple of years and welcome to my talk, The Pragmatic Guide to Defending Drupal. So my name is Nick Xu. I'm Operations Lead at Previous Next and I also architect the Skipper hosting platform. Today I'm going to take you through defending Drupal, talking about the scope but also process projects and products. And as my co-worker Michael said over dinner last night, like those are all pros. So these are all getting pros tonight. I mean today. So let's get started. Okay. Step one. To delete your site. Delete the whole thing. Gone. No site. No problems, eh? How I saw Lee's talk before. He didn't want to make people raise hands, but I will. How many people are using Terraform? Okay. Run it. Actually, don't. Carl, don't. That's our cloud. How many people are actually running Kubernetes? That's a good amount. Yeah, cool. I didn't know this command existed. Yeah. And for everybody else that has a local or a, you know, like just, yeah, have fun. Like all done. All done. Any questions? Done. Record time. Let's go. But that's not particularly very pragmatic, isn't it? I decided to make my talk the pragmatic guide to defending Drupal. So what I just said isn't very sensible or realistic. And I really do want to emphasize on this talk being practical rather than theoretical. I think there's this talk comes from a place of seeing a lot of other talks that are very theoretical, very high in the sky. I want mine to be a little bit more grounded and things at least you can take one or two things away with you today. So let's talk a little bit about scope and the state of web development. And I've been talking to a lot of you guys here today in the hallway track. And, you know, it's pretty clear that over, you know, my career, it's like 10 years, it's definitely accelerated, you know, front and back and operations, it's all gone. It's different different ways and it's become more complex, like with the web as well as the web's gotten more complex, right? But we don't use the same tools, for the most part. I mean, I don't use the same tools that I did, you know, a couple of years back or a couple of years before that be used, you know, just basic bash or then I think there was a bit of a bit of thing in there. I went like if you go back in the previous next archives, I was a big advocate for Bing and then Robo now make come up full circle. We don't use the same hosting. I mean, that's, that's pretty evident. We have a lot of vendors myself myself included skipper. We don't have the same workflows. We like some of us have different branches for deploying to different environments, we tag releases, we, you know, go, go straight off master to production. It's okay. But ultimately, to me, it boils down to we just have different business goals, right? We're not building the same site. Like if we did have the same business goals, we'd build the same site, right? So that kind of sets the scope. What I want to talk about. So what can I do? Process. It's very boring. But it's not really it's it's an and I want to take a stab at the first one, which is standards. So I'm talking about like your ISO 2700 ones and your IRAps and your essential eights and all those kinds of things. And I truly believe that they align us. It doesn't matter tools, workflows, hosting environments. But standards, I do believe that standards do give us kind of like raise the bar, give us a common ground to sit on and talk about and then figure out where we are. And if we if things need to change or be implemented, but get your cameras out, they're not practical. Standards. If you go headlong into like an ISO 2700 one or something similar and go, we're going to implement this. By the time you you've implemented it or you've looked at the scope of that document or that, you know, that process. I your your months and months down the line and haven't actually implemented anything yet you're taking on way way way too much. So so if you don't have any of these standards in place yet, honestly, have a little scan, pick out a few things and go from there. And I want to give you a couple of recommendations from here. Does everybody in this room know for their site, if there's an incident, like I'm talking website down or we've been hacked? Do you know who to contact? Who's running point on that thing? I think it actually surprised you how many how many folks just as a team go, hey, no, we're cool. It's fine. When it happens, we'll deal with it. But you really do need somebody to take that take that load, take that direction and then and charge on into it. Can you restore your site? I mean, I I've taken this for a given, but I I definitely know that there's, you know, certain situations where I've heard where people can't restore their site. So I feel like this is very, very important. Can you can you restore your site database files? Infrastructure could be could be anything. It could be going to your hosting provider and going, well, if you're down, are we going to spin something up on AWS? Are we going to, you know, it's not just like, can I restore my whole site? Maybe we take a static version of that site and put it on s3 or something like that on a separate cloud hosting provider for a temporary period of time? Could mean different things to many different people. But if you ask yourself this question, I feel like you would get a few of these things out and know what to do in a scenario. Incident response plans. Now, as somebody who's written an incident response plan, they can get a bit big. Very multifaceted. And I think to begin with, you should ask yourself a couple of key questions. Like I said, who do you contact? Write it down. What do you do while you're under attack? You know, and then what do you do when you've been compromised? And I think these three questions, like you don't need to initially write a document around it and make a big process around it. I think you just need to sit down, have a coffee, have a drink, you know, keep a casual, I keep it very, I guess, hypothetical, and then just rattle off a couple of couple of things that you could do. And I'm even proposing that folks, if you have a single project, you put it in your read me. But it's super easy, right? And at least you've answered these questions off out of the gate. And there are checklists that you can use when these kinds of things happen. Right? But for us, as we have more than one site, that's, that's where a document does come into place. Or even in this case, like, who do you contact? That's in our handbook, because you're an agency. Do you have a patching schedule? I mean, Michael covered the other yesterday, around patching and Thursday morning patching and, and being in a bit of a rhythm and, and really shrinking down what you're shipping. But, and it's not just patches, right? Like, I'm covering like dependency updates and things like that here. But, but even if it is just like a bump in a module, it's not a security fix. And you're doing that on a cadence on a Thursday morning, or on, you know, once every Thursday morning, or every fortnight, whatever it is, if you're shipping frequently, and bumping up those dependencies will then, you know, when something does happen, the change that you have to make is very small. And very, very incremental versus having to do a big, big, big jump in that direction to solve the issue. So that's process. Now we get on to the fun, the fun techie stuff projects. So for this, I want to talk about some open source projects, things that you can integrate in your, in your environments. The first one's called trivy. And trivy is a static, static code base scanner. It's born out of the cloud native ecosystem. I mean, it's directed towards containers, but it also scans file systems, and it picks up all kinds of different things. But on top of it, like you can see here, it picks up things like, Oh, somebody committed to GitHub access token, or an AWS token or just the really easy to catch kind of things that are simple, but have massive ramifications. A tool like this can pick up for you very, very quickly. And it can sit right here, smack bang in the middle in your pull at your pull request layer is CI CD, right? You could run it locally. But ideally, you would put this in your CI CD pipeline. And every time somebody is doing a commit and a push, and you're doing this scan and doing it as part of your your release process. And I mean, depending on your hosting environment, if you don't have access to the, the CI CD part, you can still add another CI CD. Like, if you're on GitHub, or something like that, you can, you can use GitHub actions on top of the other CI CD solution that you're using. I've also covered two more down there, which are actually, well, one of them sort of a project slasher slasher product, which is SNCC. And then GitHub security is actually a seems to be a very, very good solution. However, it's free for public repositories. And then it's and then it's paid for private. So, so if you have an open source repository, there's and it's on GitHub, there's probably no reason why you can't can't use something like this. There's no excuse. Cool. The next one is Falco. So, which is an intrusion detect detection project. So, yeah, Falco was also born out of cloud native, but it can run anywhere. It and this one's more for if you're running your own hosting solution, or you have access to your own hosting solution, and your own instances, but it's, it's extremely easy to deploy. It's a single binary. And then once deployed, it listens to all the sys calls, very level on your infrastructure, and it picks up all kinds of really, really interesting things and alerts you based on rules. So it's on your hosting. And here's just a couple examples from the website, which are, which you know, this blows me away, how it could just be this powerful, right? So, so a rule like this. So the first step is, you declare these kind of like reusable components called macros. And then you set up a rule. And in this case, you know, it's the old like install x binary into your USR local bin directory, you'll get a notification if somebody does that. And on your hosting, that's that's a pretty big deal, right? You want to know when people are writing executable binaries to very, very specific parts. But to show you how flexible something like this is, you can even do super interesting things like my video device got opened by the process. It's sort of a little cut off, but by Skype or WebEx, you can kind of filter it down and get notified and get notified when you know, WebEx or Skype is pinging. So you can do all kinds of different things. For us, given we're in a containerized environment, and everything's kind of split up into the nginx container, the FPM container, the CLI container, and deployed separately and scale out independently. That gives us puts us in a really good spot for this because we know that the nginx image only executes nginx. Like PHP, FPM only ever executes FPM and if bash gets fired, well, then we know that there's probably an issue. And then CLI is a bit different. Okay, next, I want to talk about products. So if you can't implement many projects into your into your CI CD pipeline or your workflows, well, then I've got some products that you could use as well. And the first one to look into is a CDN. If you went to Kim's talk yesterday, you'd see that quite a big portion of that talk was around the CDN and scaling through the pandemic. And all the configuration that you can make is to be very resilient under the case of high load. But it's also extremely important when it comes to defending Drupal because you still want to be able to serve content to your end users. You want to have your edge out as far as it can go and not be tied to your actual infrastructure. You typically a CDN then has WAF services provided to it. And it has way more compute than than the app servers that are running your infrastructure ever could. Now, which CDN provider you pick is very much up to you in some cases. I would say if you're on AWS or you're on Azure or on a cloud service provider, pick the one that's integrated with your cloud service provider. So if you're on AWS, CloudFront is an absolute no brainer. It's extremely cheap. You can have as many CloudFronts as you want. And then it's usage based. So there's really no excuse to have like a dev staging production distribution CDN distribution setup. And then the neutral ones is where it kind of gets interesting because I see this a lot with on-prem customers or even potentially like I've seen it with like Acquia customers and where they want to control the CDN and then route to the back end. So they're hosting providers back end with us too. We have clients on Skipper, we turn off our CDN, then they control it themselves. And in this case, I would recommend something like CloudFront. But then you also have, if you have a, no, I spelled fastly wrong, that's fastly. But if you already have varnish on your infrastructure and a varnish configuration, then a very pragmatic, practical thing to do is take that configuration and then use fastly and deploy it to fastly and run it there. And then benefit from their CDN infrastructure. But you, yeah, definitely get a CDN. And this is something that's very, very practical and pragmatic to me because you can just put that in front of your existing infrastructure. Dust. Dynamic application security testing. How many people have heard of like the shift left movement? Couple, couple hands. How many, how many people have say like a security team who do routine security testing, like run a security software against your infrastructure on a routine basis? And then think about how often do you see that report? Like what's that, what's that feedback loop like? Yeah. Shift left is all about taking that and accelerating it. You need to own that. It's okay that they're running those tests and doing those scans. But what's not all right is to hear months and months and months later that, oh, we found this, you know, like once it's all collated and then they're analyzing it because they're analyzing an entire organization's worth of web infrastructure and they get back to you. That is a really, really slow feedback cycle and you can get on top of this by doing this yourself. Oh, actually, I'll go into that soon. But there's a whole suite of different tools that you can use here. And we've had a little bit to do with every single one of these. But honestly, my favorite is a tool called Stackhawk. It was in there. It's literally in there, docs and everything. It's a thing. Between Falco and Stackhawk. It's a very interesting project naming scheme that we're seeing now instead of the container nautical theme. But this is a great tool because it's actually built on open source scanning technology and it's a service where they host the reports and you run the scans yourself. Which then means that you have the ability to run Stackhawk via a container or the application itself, the CLI itself at any layer of this directed and at any layer of the stack. So you can be running it locally to determine is there any security issues locally. You can run it in your CI infrastructure, which is a game changer. The further you shift left here from your hosting to your pull request to your local is a quicker feedback loop. I highly recommend considering doing it in your pull request layer. Then the final one is hosting and just be wary because Stackhawk actually does do post requests. It is quite aggressive. It is trying to find issues. I'm actually kind of looking into the more discovery aspect of it. But there shouldn't be any worry in running a tool like this that is aggressive in trying to find issues in your application at the pull request or even the local development layer. Another real big benefit for something like Stackhawk is that I've seen with every single one of these bits of software, I've spent a lot of time talking to vendors, like actual like these vendors and a lot of it the pricing model is actually based in like number of assets you scan. So if you have one site or you know a dev staging production that's three, well that's okay. You're probably going to have a smaller bill. But if you're somebody like us or you're an agency or you have multiple web properties, that gets very, very expensive very, very quickly. And then you start have to start have to making trade-offs of do we just scan dev? Do we just scan production? Like how do we minimize that? And I feel like you're really compromising there. Something like Stackhawk is actually a headcount system which I really, really like. So it's number of developers that are using the software. That's the billing model. So have as many sites as many environments as you want. It just comes down to how many logins and how many folks are actually associated with that billing account. And I also want to talk about threat detection. So something like we run on AWS and AWS has an amazing suite of tools for our threat detection. This is actually AWS GuardDuty. And when enabled, it will sit there and scan all your infrastructure and all the streams of your flow logs, your EKS logs. It goes through there and then it detects and then makes recommendations. I think for us, I was very much amazed when it started to show us, hey, somebody's trying to brute force one of your instances they tried four or five times. When you look and go, oh, cool. Okay, we're going to block that or we're going to turn off that port or we're going to, yeah, it's extremely convenient to enable. But then it's also very, very informative. And honestly, when it comes to some of those standards, this ticks a lot of those boxes too. They also came out with malware scanning which is really nice. It will scan all your volumes and tell you if there's any kind of malicious files on your infrastructure. And there's one for every flavor of cloud there is. So there's no excuse. And then if you're with a hosting provider, then you should expect that something like this is turned on and enabled and being run. So I fly through that. Nice. Okay, so to recap, be pragmatic. Think about the processes. Think about bite-sized pieces from your processes don't take on too much. Answer some very simple questions for your projects. Pick one or two of these if you don't have one. They're very easy to integrate into your CICD or mostly your pipelines. And then finally, products. Definitely consider something like a CDN solution or threat detection because these kinds of products are becoming even more easier to enable as you go. And finally, as like a bit of a thought exercise, for those who did, you know, did delete their stack, think about, you know, what would you change and maybe what you'd keep because that might even point you in the next direction of the little change that you should make in your infrastructure. If you don't like something, you should definitely consider changing it. And yeah, so any questions. I welcome people to ask questions about this tech or maybe you can tell me what you would keep or delete. And we are absolutely high. Nobody? Oh, there we go. It's like I talk to everybody in the hallway. Yeah. Um, not particularly Drupal aware, but I have started looking down the route of Stackawk because there is a whole bunch of, I believe, their modules or there is like like you can give it credentials and start to build out a suite of tooling to actually go through there. And yeah, I would love to do a Drupal version of that myself, actually, because they do have tools for WordPress in there for logging in and clicking through. So it also depends, I guess, which is scanning there too. Like if you're logging in, but yeah, like what kind of experience that is. I'm saying that I have flashbacks to when we gave pen testers credentials and I think they got admin credentials for some reason. And then, you know, 1am in the morning because they were overseas, the theme got turned off on like devil staging or something. You come back the next morning and the site's broken because this bot just went through and clicked everything. So, but yeah, but for log, yeah, for logged in, I guess what you would do is for like a logged in kind of Drupal site, which is very, you know, authentication based for end users, you would then work with Stackawk and then build out kind of a scenario to step through and make it aware of those parts of the log, didn't it? Okay. On that note, any questions?