 is this thing on? Oh, there we go. Hello everybody. Thank you very much for coming. I know it is the, well getting towards the end of the second day and I'm sure everyone's feeling pretty tired and exhausted, I know I am. I went out and had a bit too much fun last night. But hopefully we'll all get through this just fine. The topic of this talk today is asking the right questions, how business managers and project leaders can gain confidence in their site security. And I would like to kick off by telling you all a little story of a personal professional failure that I had about four years ago. When I was still pretty fresh with Drupal and still working my way through Drupal and understanding it properly. And that was that I got asked by a client that we work with. I'll do introductions in a second but I wanted to kick off with the story. I got asked by an agency that we work with to help them with a client of theirs who had 12 sites, 12 Drupal sites, seven and eight on a single web server and they were all performing poorly. They were all very slow. Their host who was a non-specialized Drupal host, more about that later, was having problems figuring out what was going on. The agency didn't have any specialization in the hosting side of things, which is my specialization. And so they asked me to get involved and take a look. I did so and very quickly I found, I'm just gonna take this out so I can, I like to pace. I found very quickly that there was a crypto miner in the server that was using all of the CPU just mine cryptocurrency. I think it was Ethereum. So that person's probably seen their fortunes rise and fall a few times over and that makes me sleep a little better at night knowing that if they had that cryptocurrency maybe they've got some stress to go along with it and some highs and lows. So we discovered that their server had been hacked. They were not aware, their hosting provider was not aware. This wasn't an area that I specialized in. I specialized in hosting, but I'm not a security consultant by any means. I wouldn't put my hand up as a security expert, even though I'm doing a whole talk about security. However, I prepared a report for this client. I was very excited to see how the attack worked. I actually replayed the attack on a test server somewhere else. It was really, really fascinating. And I probably got a little bit too smug with it all, but I went back to the client. I said, look, here's the report. Your Drupal sites were unpatched and one of them has been hacked with this thing called Drupalgetten2. And if you'd patched them and if the server was configured correctly this probably wouldn't have happened. We can help you, we can fix it for you. What would you like to do? Now you might hope, as I hoped, at that point in the conversation the client would say, holy shit, okay, well we better go and fix this. Forgive the language. They didn't. The client, the chief marketing officer of this building services company, said, ah, so Drupal is insecure. And at that point I knew that I'd lost. I tried very hard to sort of backtrack and say, no, no, no, Drupal's not insecure. The implementation of Drupal that you were using was insecure and that can be fixed. However, the sad end to this story is that organization went ahead and replatformed all of their sites onto WordPress. Those WordPress sites are on the same server. So I feel like I've been constantly atoning for that mistake, for that failure to really explain the situation to that client. And I've sort of made it a little bit of my mission to help everybody realize that Drupal is, in fact, a very secure platform, but it is only ever going to be as secure as you make it. So I am Mike Richardson. I am the managing director at a company called Ionstar. We are an Australian managed Drupal hosting provider that works with government, federal state and local government and large enterprise aviation, commerce and medical services. And we like to think of ourselves as the guys that you call when you absolutely must have the A tier of Drupal hosting and, most importantly, support. So we don't have an operation in Europe. However, we'd love to. But I've spent about 20 years in hosting. I've spent the last six of those years working in Drupal and building our platform and working with our clients to help secure them and accelerate their sites. And this talk is for non-technical decision makers. This is for the people who find themselves, whether through good fortune or bad, responsible for the security decisions and the budget decisions of a Drupal website, but who don't come from a programming or otherwise technical background. May I ask the question? Can you just raise your hands if you consider yourself non-technical? I'm not, I'm certainly not judging. Some hands up there. All right, so this talk is for you. If you didn't raise your hand, this talk is for you to help you to convey the importance of these things to the non-technical decision makers that might be in your organization. Because we all have this shared responsibility towards making sure that the Drupal sites that we're responsible for, whether because we host them or because we build them or because we pay for them, are secure. We're gonna step through these things in terms of a cost benefit, and now nobody has an unlimited security budget. If you have an unlimited security budget, I would love to talk to you at the end of this. But so far I haven't met anybody that does. And not every solution is appropriate. Some of these things are no-brainers. Some of these things are only applicable in certain scenarios. So we're gonna talk about what each of these cost, both in terms of euros or dollar value, and also in terms of effort to implement and maintain. And we will start with the things that are easy wins. I'm going to try and not make this too technical, but I need to cover a little bit of detail to help. But these things that we're gonna talk about next, these four or five things are free and very easy to implement, and they provide a lot of extra security for your Drupal site. And I think if you turned all of just these easy things on, you would find yourself in the top 10, 20% of Drupal sites in terms of security posture. And the first of those is a Drupal module called SecurityKit. Has anybody heard about SecurityKit? I'm sure some have. Okay, that was less than I thought. Okay, so SecurityKit is used to inform browsers of the security posture that you would like them to take with your site. It sends security headers in the response metadata whenever somebody opens a page on your Drupal site and it will tell the browser how to behave. And it prevents browser-based attacks against user data, things like cross-site scripting, cross-site request forgery. These are things that take advantage of a real user's interaction with the website with a trusted browser like Chrome or Firefox that gives that user the impression that they are in fact working legitimately with your website, but in the meantime, there's something in the middle that's picking up that request and manipulating it. Your site can send instructions to these browsers to say, I want you to behave this way, and the browser in doing so can be much more secure for you. So we should be asking our technical teams, do we have SecKit or SecurityKit configured? Do we, how do we mitigate cross-site request forgery and cross-site scripting? And if you're curious, and this is probably the most interesting thing in this whole talk because you can play along with it, if you go to securityheaders.com and you can type, this is a free tool, and you can type in your website address and I would not feel bad if any of you picked up your phone right now and did it live, you don't have to share your result with anybody. We didn't have this A plus when I started talking, when I started preparing for this presentation, we had a different score. I'm not telling you what it was. And we had to work pretty hard to get this done, but the really great thing about this site is that it tells you what you need to do for each of those headers, and you and your team can make the decision about what's appropriate. And don't feel discouraged by your score because you might find that other organizations have something similar. This, for example, is Microsoft.com and this is CIA.gov. Now this is a bit of a trick because there's no good reason for CIA.gov to have these security headers. If you don't log in to CIA.gov, you would do it on some other system, but just having a less-than-stellar score in this doesn't mean that you're completely exposed and at high risk, but that site is a really great way for you to figure out what your next path should be. And again, SetKit is free and it's very easy to configure. And just as an aside, if you like that tool and you wanna look at something, I can't help it feel like that's, I'm responsible for that somehow. If you like that, you can also have a look at sslabs.com slash SSL test. There we go. That will give you an assessment of your site's SSL security. That's much more technical in terms of its response. It's less helpful in terms of what you should look at next. But anything less than an A from this site is worth having a look at because it might be that your site is exposing weaker encryption algorithms that somebody could potentially take advantage of. But those sorts of attacks are more sophisticated and not your sort of everyday thing. So that's number one. Number two is patching. And I know that we would all think patching is everybody patching, right? There's no reason why you wouldn't be patching. But a lot of us don't patch. Or even more common, a lot of us don't patch until there's something that we know we need to patch. Drupal.org and the Drupal association will release. We should say the Drupal security team will release security updates on a periodic basis. Some of those apply to you. Some of those don't apply to you. Some months there isn't one. And I've seen organizations and teams that will say, right, well, I don't need to have this patch. There's nothing in it for me. I'll wait for the next one. And then suddenly something like Drupalgeddon or whatever comes around and it's scary and you need to patch immediately. But you've missed six months of patching. None of those six months apply to you. But the third month has a breaking change. And you're only finding out about it when there's this whole big scary thing that's going on. And we saw this with Drupalgeddon too when it came out. There were a fair few sites that we work with with our clients who weren't up to date and what could have been a 10 minute routine, really boring thing, ended up being in one case a five day exercise. And for those five days they had increased exposure. If you patch regularly, at first it's going to feel like a lot of extra work and a lot of teams. And I know agencies really have a problem with this with their clients. It will be like, okay, this is going to take a day or two every month and we don't have that kind of time. We can't convince the client to pay for it or I can't convince my boss to prioritize it. But if you make that commitment to do it every month, the time required will get shorter and shorter and shorter until it just becomes boring and routine. And I know that doesn't sound exciting but in the case of patching and security, boring and routine is really, really helpful. So you should be asking your teams, are we patching? How often are we patching? And did we audit the module constraints as well? Don't just patch Drupal core, patch the modules that you're using and patch the dependencies of those modules as frequently as you can. The next thing that everyone should be looking at is a content delivery network. A content delivery network, if you haven't heard the expression before or the term before, is a global caching network that will receive requests for your site before your server does. And it will determine if it has a local cached copy. If it does, it will send it from that local server to wherever the user is. So for example, if I wanted to access a client site back in Australia, the first time I hit that from Prague, I might get a caching node in Germany or France or something like that. If that caching node has a copy, I get the local copy. That has two advantages. One, the response is much, much faster. Two, the work on my web server is much, much lower. And that means a lower hosting bill. I'm not so excited about lower hosting bills, but I've heard some people are, particularly our clients. So CDNs are not built as security suites. They're built to improve performance and they do that absolutely. But having that global network absorbs attacks. If somebody takes advantage of a botnet or a large network of automated compromise machines to attack your server, if you've got a CDN in front of it and no one knows where your actual server is, that attack is distributed globally. And that can have a really positive impact. CDNs used to be very, very expensive. They used to be in the realm of thousands and thousands of euros a month. But over the last 10 years, the market has really become commoditized. I've just got an example here of three that you can effectively get up and running for nothing. That is Cloudflare, who's probably one of the largest, if not the largest content delivery network provider in the world. And you can configure your site with Cloudflare at no cost. And the others, if you're on AWS or you're on Microsoft Azure, then you can use their CDN products and they will charge you, but they will charge you based on volume. So if you've got a small site, you're not gonna pay very much. And even if you've got a large site, you're probably gonna be paying less than 50 euro a month unless you're talking about really serious traffic volumes. So CDNs are a relatively easy thing to configure and you can configure them for free. So, and you get the advantage that it's gonna improve performance and probably your conversion rate and lower your bounce rate. The next thing is the two-factor authentication, which again, this is something that a lot of people didn't used to really know about or use. And I think five, 10 years ago, if you went to your Drupal user and you said, right, I've turned on 2FA a fair few of them ago, you did what? I don't understand. Now, everybody knows 2FA, if they've got an Apple iPhone, they know 2FA. If they've got a Google account, they know 2FA. And it is incredibly useful. If any of these things are a silver bullet, it's two-factor authentication. You will prevent brute force attacks against usernames and passwords. You will prevent attacks where somebody reuses the same username and password with your Drupal site on another site and that site's database is stolen. There is, yeah, this is easy. There are multiple free modules for it. You should be asking your team, do we have two-factor authentication turned on? And if you don't, this is probably one of the first things you should be looking at doing. It's easy and it's incredibly effective. The final thing that's on the easy list and on the free list is email security records. And these work a great deal like the browser headers that we were talking about before, except that they are advertised in your domain name to advise other mail servers what to do if they see email that looks like it comes from you. You'll list the mail servers that you think are trustworthy, that you know that you will send from and it will tell them if you see mail coming from somebody else or that isn't authenticated in this way, this is what I want you to do with it. I want you to put it in spam or I want you to reject it or I want you to allow it anyway for some reason. I don't know why you would do that. And you can also configure it to say I want you to email me reports about it. And there are tools you can use to analyze these reports but you can discover if someone's phishing from your domain, from your email address using these tools, whereas previously you wouldn't be able to. This is slightly more, I find that teams are slightly less aware of how to configure these records so it takes a little bit more work and you need to be a little bit more cautious because if you get it wrong, you might not know that it's not working for weeks. If you screw up something with your website you generally know about it right away. So you can go ahead and fix it really quickly. But if you get your email policies slightly wrong you might not know that all your email is getting junked until finally somebody says oh I've been trying to email you for months and that's obviously not ideal. So this is well and truly worth looking at. This is free as well and this will help with more sophisticated attacks that work on impersonating you. Things like sending a password email reset and making it look like it came from your Drupal site when in reality it didn't and the link goes to something else. So that's the list of free things and they're really, really easy to do and I think I've hopped on this for long enough. They're free, I'm sure I mentioned that. The next things to look at are these worthwhile endeavors. These are the features that will increase the security of your Drupal site but they take a little bit more work to implement or they have a cost associated with them. They're not gonna be applicable for everyone. I know at the beginning of this I said not every tool and not every solution is the right tool for all of us. Those five things I just talked about they're the right tool for all of us. That's the sort of exception. You should have all of those. This next set depends on your circumstances, depends on your budget. The first one is a web application firewall. Most of these are an add-on for a content delivery network so if you go ahead and deploy a content delivery network on your site like we talked about, you will find that you've probably already got a turnkey solution to turn on a web application firewall. A web application firewall will receive the incoming requests for your website, decrypt them, and analyze them for non-malicious requests. It will identify if this is coming from a network that's known to be suspicious or coming from a device or a user agent that's known to be suspicious. It will identify, for example, when Drupal Get In 2 came out, a lot of the CDN providers and the WAF providers very quickly added a rule to the incoming, sorry, to their web application firewalls for that attack. So even if you didn't have a patch server, or patch site, you would find that the web application firewall would stop it from ever reaching you anyway. So we should be asking our teams, do we have a WAF in place? Do we program specific rules for our site? And most importantly, do we monitor WAF alerts? Do you know if someone's trying to break into your site? Because that can be very, very important to be aware of, because that might change how you respond. If you see suspicious traffic, you may be able to shore up defenses somewhere else before they're able to find a way in when you can know about those just sort of exploratory queries that are coming in that are generally less sophisticated and likely to be less successful. Cloudflare has a WAF product that's about 200 euro a month. I don't know about Azure, but AWS CloudFront has a WAF extension that's pretty inexpensive, just like everything AWS, you pay for what you use. So if your site's relatively small, it's relatively cheap. If your site's large, the cost scales with your site, so it's generally quite manageable. So the next is, and I promise this is not a plug, the next is to use specialist Drupal hosting. The story that I talked about before was a hosting provider that didn't specialize in Drupal and didn't have a knowledge of Drupal, and part of what makes Drupal really successful and really powerful is that it is really easy to get up and running. It's easy to start hosting a Drupal site, but that also creates the impression that that's all you need to do. You get that up and running, you can walk away. When you work with specialized hosts, like us, like Platform, like Amaze, like Acquire and Pantheon, they, you are working with someone who has years and years experience and large teams that are specialized in hosting these applications and securing these applications. They will constantly be evolving their security posture and their security functionality. A lot of the sites that we see that are self-hosted are sort of built, a lot of them are government tenders that are built at the beginning of the tender, and they're left running for the five years, three or five years that the tender exists, and they receive very limited maintenance, but in that period of time, security threats are evolving, attackers are becoming more sophisticated, and what was secure three or five years ago no longer is suitable, whereas these specialist providers that work with Drupal are always countering these attacks. That's hard at Drupal. So this is something that is important to be talking to our teams about, does our host understand Drupal? If there was a major Drupal vulnerability that was discovered, can our host respond to it in a way that assists us if we, for example, can't patch it right away? And can that host help us scale? So I think that's a very important thing, but obviously shifting host is no small effort. Single sign-on, a lot of you would probably already have single sign-on for your organizations. Most companies now will have Octor or Microsoft or Azure, sorry, Azure AD or Paying or Google Workspace or something that's providing single sign-on for their organization. I've seen a lot of sites where a developer or a project manager or someone is onboarded onto the Drupal site, they work on it for three or six months, sometimes longer, and then they rotate off to a different project or they leave the organization. Maybe there's five sites, maybe there's a dozen sites, maybe there's much more. No one's going through and auditing those accounts, so that person retains their access and they retain it indefinitely. If you don't have two-factor authentication and their password gets leaked because they've used it in a different site, suddenly someone's got to weigh in to your website. Similarly to this, you should be centrally managing the roles that they have. I see a lot of sites that everyone just has administrated a role when they really don't need that. So if you've already got a single sign-on solution, this is probably free in terms of cost because you're already paying for single sign-on and I don't think you'll have a single sign-on provider that's gonna charge you for integrating with Drupal, with your Drupal sites. But the effort to install and configure can be quite difficult, so that's why this is sort of in the moderate pile. But if you already have single sign-on, there's no real reason why you shouldn't be integrating it with your Drupal site and taking advantage of that centralization. So very finally, we're gonna talk about the things that are hard to do or have slightly less benefit for smaller sites. And this is the stuff that if you know that you're going to be under attack or you know that you work in a sector that's gonna have people coming by trying to take you offline or break in, these are the things that you should be looking at, but they can be quite expensive and they can be quite difficult to maintain. The first is automating security scans for your site. There's two types of this. There's dynamic application security testing and there's static application security testing. On the static side, we use tools that analyze our code base and look for known vulnerabilities and the things that are in our Drupal site or the modules that we use in our Drupal site and will alert us generally when we first commit that code into our repositories and say, hey, you've just installed this module which depends on this module which depends on this module and that module that it depends on has a vulnerability and you should update it. That can be very, very useful for obvious reasons, but it only works on the code base as it's deployed. The other side of that is, sorry, as it's in the static state when it's inside your repository. Dynamic testing will test a, sorry, here's an example, I've messed up my slides here. Here's an example of static application security scanning. I didn't have an example for Node.js ready, sorry, for Drupal ready, but I had an example here for Node.js and you can kind of see you can get a sense of what's high, what's medium. Some of these are noise and not terribly important. When we turned static scanning on for one of our internal projects, we had 80,000 vulnerabilities that it flagged and obviously I don't think anyone has the resources to individually go through 80,000 vulnerabilities, but nearly all of those were just noise. So don't panic if you deploy this the first time you see your numbers, if they're astronomical. You will probably find that there's quite a large number of false positives in it. But what's really great about this is that anytime somebody goes through and commits new code, we can put in barriers to say, all right, if you get a vulnerability in this new code, don't allow it to go into production. Don't allow it to be merged until it's been reviewed and has been fixed or for other reasons has had an exception added into it. The dynamic scanning will work with the deployed copy of your Drupal site. You will give it a username and password so that it can log in as a user in your Drupal site and it will go around and visit every page and interact with as many forms and everything else that it can in order to try and find vulnerabilities. I am not aware of a dynamic application scanning tool that is very aware of Drupal. There are ones that are very aware of PHP and they provide a good level of detail. But if you happen to know of one that is very aware of Drupal and Drupal specific threats, please, please, please do let me know. But this example that I've got here is from Intruder.io and you can see that it's throwing up errors here telling me I've got some security headers that I'm missing or I'm not configuring properly. That, you can check that really easily but what's good about this is that you can set this up to happen routinely. So it will tell you on a, say, weekly basis, however often you configure it to run. If somebody goes in and makes a change that wasn't documented or wasn't captured for whatever reason and they remove these settings or they turn on something else that creates a vulnerability, this will catch it and that will give you the ability to go, right, okay, we've just introduced a vulnerability, let's go and fix that right away rather than finding out three or six months down the track. So we should be asking our teams, are we scanning our code for vulnerabilities? This is hard to do and it can be quite costly. Some of the tools can be quite costly but there are also a lot of really good open source and free tools out there. How often that scanning takes place is quite relevant. We do our scanning on a nightly basis. That requires a fair bit of effort but even just weekly or monthly is a wonderful starting point. And finally, what happens if a vulnerability is detected? Make sure that the right people are getting notifications when this happens. If you're the non-technical decision maker, you might not necessarily be aware of the full detail of the alert but you should get it so that you get that notice to go to your team and say, right, what does this mean? How are we going to address this? The next thing to look at is workstation security. There's a type of attack or if you could call it an attack called a data spill, which is where for some reason, data that should have been living inside a secure environment is now outside of that secure environment. And one of the most common things that you'll read about is a laptop being left somewhere and that laptop not being encrypted. And this is stuff that I've been seeing in the news for 20 years and I still see it in the news even for really large organizations, really large multinational companies that have some poor fellow's laptop at an airport that he just walked away from and his encryption was turned off. And that data ends up on the dark web or whatever you want to call it, for sale for the highest bidder or it just gets leaked to the press for fun, I guess. If that's your idea of fun. So we've just gone through this exercise of implementing workstation security as part of a government compliance framework that we have to work with in Australia. It is very costly, it is very time consuming. I think that workstation security is harder than server security. However, it's slightly less urgent than obviously if your server's insecure, it's out there on the web, that's a bad part of town, you don't want that happening. But workstation security is something that very few organizations really takes as seriously as they should. And this is something that is worth looking at if you want to build that culture over time of security within your organization and within your teams. So we should be asking, what's the risk if a laptop is lost or stolen? Are those laptops encrypted? Is there any really sensitive data in those laptops? Everyone's very connected now, the cloud is there. There's some data that you just don't need to pull down to your laptops that you used to. So it's probably worthwhile just not having that on there and not creating that exposure. And do we know if vulnerable software is installed on our workstations? If somebody goes and downloads something off the web that's got a virus in it, do you have virus scanning? I have heard quite a few people say, I've got a Mac, I don't need a virus scanner. That is wrong. I've heard some people say, I've got Linux, I don't need a virus scanner. That is wrong. You need a virus scanner. And if you don't have one, you should be looking at getting one. Unfortunately, the free ones aren't very good. However, that's something to look at. And finally, this isn't expensive, it's free, but it is less effective, it's less urgent. And it can be a little bit of work to set up and mature within your team. That's sanitizing database exports and it fits into the whole workstation security thing. If you've got a developer who is pulling down your production database onto their local workstation, or maybe they're kind of breaking the rules a little bit and they want to run a special operating system, they want to run Linux, but they don't have that with their work computer so they use their own computer and they pull the code down and they work from there without the organization knowing about it. I have seen this happen. And that data from the production environment contains personal information, it may contain medical information or classified information and as soon as that leaves that secure enclave inside the hosting environment, all bets are off. And that sort of feeds into that whole data spill and workstation security thing. There is a free tool built into Drush for Drupal which is a command line utility that will let you configure database sanitization whenever somebody exports a database from a production or a non-production environment and you can tell it which fields should just be scrambled, which email addresses, people's names, credit card details, please don't be storing those in your database, but if you are, you can identify that these fields are sensitive and if anyone's downloading the database to their local system, that information should be scrambled. So as a quick review, we've got the things that are cheap and require minimal effort, those first five things strongly, strongly recommend it. I see some people taking photos, that is fantastic. Moving down, we've got the things that are moderate, but they have some associated cost. The actual cost may vary based on your particular use requirements. And finally, we've got the things that are harder to do. There's a lot more that's hard to do than I've captured in this list. None of this is exhaustive. If you think, again, if you think you're at significant risk, you should be talking to a security expert who can help you in building a response that's specific to your organization and to your threats. So that's it for everything I've prepared on slides. I, if you have a moment and you wanna follow that URL, I've got a quick little Google Form survey. I would love your feedback. I really enjoyed doing these presentations after the fact. I hate having to do them before the fact and I always tell my friends and my colleagues, next year, if I put in for a talk, don't let me. And I hate it up until this moment and now it feels great. I love doing this. But if you've got some feedback for me or something that I could do better, please, please, please follow that link. Let me know. Otherwise, you've all been great. Thank you very much. I know it's the end of the day. Any questions? Oh, sorry, just really quickly. Are there questions in the app? Yes. Okay. How do I get the line going? I don't know. Okay. I'll just talk really loud then. So there's a question from Pedro in here. Is any channel valid for MFA? For example, WhatsApp messages. I would also add SMS and hardware tokens at least. What do you think about that? Great question. So just to provide a little bit of extra context, the channel here is when you do MFA, you can authenticate using a mobile app, which is the most common mechanism and you've probably all got something like Google Authenticator or Microsoft's version that you can use for those tokens. That provides a good level of security because generally you need the phone and you need your phone's pin or your face ID or fingerprint or whatever it is to unlock the phone in order to get to that token. Some organizations will prefer to send you an SMS. Some will prefer to send you an email. They are generally less secure because they aren't necessarily bound to something that you physically have. So if somebody breaks into your email and they can go to a website and say, I wanna do an email recovery. So they send you the email password and then they authenticate you with, sorry, they do your MFA authentication via email as well. Then suddenly that attack has got the only one thing they need to break through both of those mechanisms. So an Authenticator application is the second best. The best is a hardware token, much harder to set up but you can have a hardware token that has to be plugged into the device and pressed at the time of authentication and that provides encryption between the server and the token. So the server will only accept an authentication request from that token. That can be a little bit more difficult, especially if you've got a large number of users who are non-technical, that can be more work. But I would say personally, hardware token, MFA, virtual MFA application or a physical MFA application and then probably SMS and email sort of at the same rank. So thanks for the question, Pedro. We have another question here from Andrew. Capture, recapture, honeypot dead ends or can they still help? They can help. Security is, it's a defense in depth strategy. This is for preventing things like someone trying to brute force their way into your website. You can use things like recapture or honeypot or other techniques to try and prevent them from just being able to constantly hit that login page and be able to do it. So you've seen recapture if you've surfed the web and you've gone, I am not a robot, that's recapture. Those tools are very useful. They're not infallible, they're not flawless. They can be compromised by very, they can be bypassed by very sophisticated attackers and recaptures now I think in its third version and that is because the attackers continue to become more and more sophisticated. Those things are useful. I wouldn't rely just on those things. I would combine them with something like MFA and single sign-on and if you do that then you're gonna have the best protection. Okay. Oh, it does work. Oh, hey. Yeah, do we have any other questions? Over here, all right. Thank you for your session. When you were talking about the database, export sanitization, I think one thing we need to know here in Europe is that we have GDPR and you have to declare such treatments and I strongly recommend everyone here to think about it because it's a GDPR violation and we have to deal with it in all of our projects. Excellent point, thank you. Yes, sorry, one question on your right. Hi, thanks for the presentation. You mentioned you highly recommend MFA, which I agree with. However, the Drupal modules you mentioned don't have stable releases for Drupal 9. Do you still recommend those? I do still recommend them on the basis that they're very heavily used. So for some of them there are a lot of installations. I know, I can't remember exactly which one it was, but one of the people that we have in the Drupal community in Australia is the maintainer of one-time password and I know that the TFA module is used in the Australian government's GOVCMS framework, which is I think about 500 Drupal websites for Australian government and it falls into that very stringent control that the Australian government has. I wish any one of these, some of these have not been patched, it's not been updated in two years and I would consider them stable just based on the fact that they've got thousands upon thousands of installations, but like a lot of Drupal modules that are stable, they're not marked as stable. But I would consider them in lieu of a better choice to be perfectly fine to use. But doesn't it worry you that they're not covered by the Drupal security team? It does, but I'm not personally aware of one that is stable in that space, so like I said. Isn't it maybe they cannot get stable because they implement authentication mechanism which would not be accepted by the Drupal security team? It could be, I'm not personally aware of it, but I think, again, given at the very high level and again this is for looking at your Drupal site in a way of what can I do to improve my security very, very quickly, if your choice is using a quote unquote unstable module or a module that isn't covered by the Drupal security team versus not having two-factor authentication, I personally would install two-factor authentication with any of those modules that I mentioned because I think that that not having it is the greater risk than having one that might not be covered. Okay, thanks. Thanks for the question. Was there anybody else? Thank you. Regarding the workstation security, sometimes the option to not allow any installation from non-known security, some non-known providers could be an option, but then you have some developer tools are free and they are not from any kind of this provider. How would you act? How would you do, what would you suggest? So we had to do, we had to jump through a few hoops with this. So our team builds software in Go and in Node.js. We aren't ourselves PHP developers. For Node.js, it was relatively simple to just add, we've got, let me take a step back, we've got two levels of protection here. One is that we only allow applications to be installed through sort of a self-service portal that we use. So if you wanted to install something like Terraform, for example, to manage infrastructure, it has to come from our self-service module. We can't use something like Chocolatey or Homebrew to install packages as much as we used to and wish we could. There's too much capability there for someone to install something that hasn't gone through that vetting process. So that's sort of the part one of it. Part two of it is that we've got a process that will watch for anything that tries to execute on the workstation and prevent it if its signature doesn't match and allow list. This gets really irritating when we do things like updating the language server that Go uses, which happens a couple of times a month. Every time it gets updated per employee, the signature changes and it has to go through change management. And this is why I sort of say workstation security is an absolute pain, but very, very valuable to have. So a lot of what we did, we moved into Docker. So we would, for example, if we were doing Terraform changes, we would now do that inside the container environment and the container doesn't get filtered by what is the application runtime process on the host and the container doesn't automatically have access to the host's file system, which is sort of where you get that gap of like, okay, well, if we do it in Docker, if it is malicious, it doesn't have access to the host or it shouldn't have access to the host. Whereas if we ran that locally, we have that risk. But it has frankly been a real pain. It has slowed us down significantly. The rate that we could churn out work was much higher before we started implementing these controls. But things like homebrew, if you're talking about like government-level security compliance, things like homebrew are just out. You just can't have them. And that's, yeah, that sucks. Yeah. All right. Thank you. And thanks, everyone. I'm very grateful for you all coming along and I hope you enjoy the rest of your DrupalCon.