 Okay. Good afternoon, everyone. Can everyone hear me okay? Yeah? Okay. So I hope you've been having a good time here at DrupalCon. I know I am. It's my first one, so it's been great. Thank you. So I'm here to talk to you about security by design. Okay. I'm going to give a little bit of context a little bit later, but for you to know security by design was basically a document that we developed and entity data Portugal to help our teams, our developers to have security as a mindset during the projects. Okay. So we give them basic guidelines for them to try and follow during the development. So a little bit about me. As you can see, I had more hair during the during the picture. I'm a Drupal lead engineer and entity to Portugal. Here are a couple of my informations. If you want to connect on LinkedIn, please feel free to also on Drupal.org. I have my colleague here, Paulo, chief architect also at the same company entity to Portugal to help me out doing during the Q&A section. Okay. So talking about security, big topic, right? Sensitive topic. So first of all, let's talk about the dream. I believe everyone has heard of Fort Knox, right? Located in America, Kentucky, if not mistaken, houses the largest gold reserve in the world, both American and other countries. I know Portuguese gold is also there. So we want to keep it safe. And it's supposed to be one of the most or if not the most secure places on earth. It's protect against natural disasters, cyber attacks, even has a small army protecting it. So according to what they say, it's one of the most secure place on earth. And this is actually the dream, right? Want to make our websites and our projects bulletproof. Anything that comes up, we know how to protect it. Well, we came back a little bit to the to earth, let's call it. And actually, we understood that this doesn't happen in most cases. As we can see here, a couple of statistics, for example, around 50% of all CMSs when they were attacked, it had outdated modules. Simple thing, outdated modules. Okay, we also have a statistic here that says also from security, you can follow all the information also here, a couple of footnotes that 70% of infected environments had a backdoor. This one is critical. And even worse, at least from my point of view, on average, every 40 seconds, there's a hack attack. I like this phrase hack attack. So as you can see, although the dream is to have four knocks in our in our sites, this doesn't always happen. Okay, and it starts with us. So our mission, and not what we started entity data was to have security as a natural element in our element in our development, meaning that our developers, once they started a project, they joined a project, whatever that may be, they have to be focused on security. Okay, and it needs to come natural and not to be just, oh, yet the project, let me run a couple of checks that make sure everything is okay. And we developed, like I said, a document with several guidelines to help them out with this. So we took basic secret guidelines, not only from Drupal, but in the world of internet. We took lessons that we learned from past and current projects that we have identity data. And we also went to the beautiful Drupal community and see, okay, what do you guys think? What were your experiences? Okay. And so we developed these guidelines. And I want the first thing I want to know is everything that I say here, take it with a grain of salt. Okay. So it needs to be adapted to each project, each client. Okay, what I'm going to present here as our base configurations that we believe, base guidelines that we believe. Okay, but if you have a project that it's highly intricate, highly difficult, okay, maybe needs a bit more. It was just a simple website, couple of landing pages, which is comments, maybe what we're doing here is a little bit of an overkill. Okay. So first thing first, from the community, Drupal open source, let's see what people with experience on this actually think. So we took a couple modules, five modules and some configurations that we believe from experience from the community and also from our developers at the company that we feel are, okay, at least these five modules should be installed in every single project, as well as their configurations. We started with a simple one, secure to review. I brought here an image of the actual document that we have. And so secure to review for those who don't know, it's a pretty neat module that gives us an easy to use list. Okay. That runs a security check on several items, namely file system permissions, responsible admin permissions. Okay. And so on and so forth. Sorry. Meaning that after it runs that check, it provides us with a pretty list. Okay. This is green. That's okay. If it's red, it needs to be changed. Okay. Attention. And I will leave this disclaimer also for everyone. The security review does not make any changes. Just a check, see the checklist and yourself need to go there and correct it. Okay. It also has a couple of sometimes solutions and so we can easily resolve it. Second one. This is not ideally for any order. I'm just going to call it second one. The security kit. Okay. I believe if most of you have heard of it, if not, please do. Okay. And go search it out because it actually provides us with a security layers against a plethora of potential attacks. Okay. Here we have some configurations. For example, for click jacking. Okay. And in the configuration page, you can see exactly the different type of attacks that we can protect against on click jacking. If we set the X frame options to say margin. Okay. Helps a lot for SSL and TLS. We need to enable the strict transport security and also set the max age to one year. People say it should be 10 months. People say it should be a year and a half. Again, everything with a grain of salt. This is what we considered as default. Okay. For example, one thing I also like to focus on and this may be difficult, especially with clients, we should disable the other complete unlocking forms and registrations. Although it may facilitate the user experience. If for some reason the hacker has access to your physical item, this will become complete because you won't have to do anything. Just open the browser and the computer will do, the other complete will do the work for the hacker. Okay. So sec kit. One thing is that even for sec kit, we have a full configuration page. Okay. The YAML file. We have it by default. So our developers can take it out if it's a new project and use it. Okay. Again, we always tell them question it. Make sure if it makes sense for that project. If you have any questions, come back to us. Let's discuss it. Okay. And this is also what you should do. Password policy. The password policy module allows us to basically put a couple of restrictions on the, well, the password like the name says. Namely some of the restrictions that we feel that should be followed. The password should be resetted after two, three months. Again, if the website is a lot smaller, maybe we can go up to six months. For example, the minimum length should be 12 characters. People are good 12. People are good 10. What we feel is 12. We should of course, probably our grandmothers like to use their own username on the password. We should block this because our grandmothers can be attacked as well. And it should cause force the four character types on the password. Okay. Next, login security. This is actually one of my favorite modules because it has a very neat feature. So the login module allows us to protect and restrict access when it comes to login and registration. The settings that we should follow, we believe, for example, five fail login attempts. And if we're being honest, if we forget our login credentials five times, probably we didn't know them first. But we should be able to let people reset it after 24 hours. Okay. And this is actually the neat item that I was talking about. So this module login security allows us to add a warning log after 10 failed login attempts. This means although a regular user will understand that he cannot log in, if we're trying to be brute force attacked, this will pop up. So an admin can go and check logs and understand, okay, something is happening to the website. Okay. And again, also put the show is be agreed upon with the client. And so worth putting on the project. And last but not least, we have capture those little annoying popups that we always need to fill. And it's true, they are annoying. But they do serve a purpose. So in this case, and I don't know if you've worked with capture module on on Drupal, but we should have it to every form. Okay, especially in the form that are open to anonymous users, we should always turn the case sensitive validation. Okay. And in order to help a little bit with the user experience, we should allow if the user is logged in, at least for the duration of that logged in session, he shouldn't have to repeat the test on that specific form. And the module does allow for that. On here, just wanted to say a lot of people sometimes some Oh, what about honeypot? I don't know if you know about honeypot. We also search honeypot. The thing is, and it basically does similar things, they're both anti spam modules. But honeypot puts a hidden field on the form. And regular users don't see it. But bots do they just input the text thing is if the hacker knows what he's doing, he's going to search your website. And in five seconds, you can find that hidden field. So that's why we we force capture if you tell the client is one of those popups. Okay, honeypot, at least is what we can do. Next, good practices. This is the part where everyone has a different opinion. I can tell that when we're doing this research, we went to went to 50 different websites and each one of them had 50 different answers. I even know I don't know if you check the discussion that happened at noon, I forget was security 101. They even talked about different good practices I'm going to present here. But again, these are the ones that we want to focus because we also don't want to overload people with a lot of information because security sensitive topic. A lot of people don't want to talk about it. So if we start just feeding them a large, large amount of information, we'll just get bored and don't care. So first of all, avoid customer hard coding. We always say this, you always say this, we always do it, you always do it, we need to keep trying to avoid it. Okay, we all know about this. Plus, we all know the saying, don't reinvent the wheel. And if we have a community, if I have this problem, some of you already had a problem. So let's see if I can find something on the community. And if you do have to do custom coding, let's try and do it as general as possible. So they can also be put in a patch in a module. So we can always use free testers in the community to make sure our code works well. Next, Drupal coding standards, you can find them on Drupal.org. If we are Drupal developers, we should follow the Drupal coding standards. Okay, it helps everyone touching on the code. Never hack core. I put this in quotes because it's actually happening in a meeting that I had with a team. I had a one of my colleagues that yelled, never hack core. Because one of the other teammates was trying to hack core, he was trying to touch on Drupal core. And as we know, Drupal touches everything. And every time there's an update, it will be harder to maintain. So we always need to try and avoid avoid that because it can create vulnerabilities. Staying up to date to Drupal security versions, 50% of CMSs had outdated modules. Okay, this should not be a problem. But still, it happens. Okay, it's easy. We get notifications. You can even Drupal even has an mailing list that you receive. Okay, I believe it's sent on Wednesdays. So you can get it up to date every week. Never paste or share sensitive information on public websites. And here I'm not just talking about random repositories or relieving functional users on storages. I'm talking about chat tpt. Okay, I'm talking about co pilot. Although these tools are good, and I myself use them a lot, we should always be careful when we put in a lot of data there. Okay, because they can be stored even though if they tell us they're not, let's be sensitive. Let's see exactly what we're putting there, put it as more general as possible. Okay. Last, we need to use Composer. Or we should use Composer. Okay, I mean, it's, I think it's the most globally accepted way of managing modules. So instead of just trying to be clever and make it different from everyone else, let's stick it with Composer. And last but not least, code commenting. That little annoying part that we all need to do when we finish our code, or while we're doing our code. But that happened to you, right? You write a code six months past, there's a problem, you go to review the code and spend more time reading what yourself wrote and actually solving that issue. Okay, so if we just spent, I don't know how many time you take to write code documentation, but if we just have few lines to explain what we're doing, okay, it's gonna help the next person that comes to check on our code and ourselves, because sometimes I even said myself, stupid you, how can you write this? Okay, and the code sometimes, the code commenting sometimes help. Okay. So this is my presentation for you. Okay, I hope you yourself have your experiences. And if you want to share it, please do. Security should be an ongoing topic of conversation. Okay, I know some people find it boring, but little help tips here and there always help developers. Thank you so much. You've got time for questions. Yeah, I just got one on the chat. So the question is, if you are acquiring Captcha on all forms, how do you ensure they are still accessible example for screen readers? Like I said, Captcha is a big topic that some people don't like to use. I don't really have an answer for that, honestly. What I always said is this should be agreed upon. Okay, because if you're presented to the client and you say, okay, maybe you can use Honeypot. Okay, and this solves the issue. It will be a little bit less secure. Do they want to focus on the accessibility? Do they want to focus on security? So that's what I said. A little bit of more communication between you and whoever is going to use the website. Okay, so if no one else has got any questions, I've got one. Yep. You mentioned turning off auto complete attribute on the login screens, which following on from the previous question, that would be a WCAG failure because that's one of the requirements on 1.3.2 AA. So disabling that would cause further accessibility issues. That's what I said. The more we want to protect the websites, the more restrictions we're going to add to it. So it's going to be a fine line between what you want to do. If you want to focus on the accessibility and I'm forward, that option may be disabled, so you don't say, okay, I do put the login security, but I don't disable the auto complete. But then if it's a site, maybe it's a high confidential website, maybe that's a topic that the client wants to put and then, okay, you're going to tell them, well, you're going to lose this accessibility part. So again, the more restrictive, for example, Fort Knox, it's a lot more restrictive. I cannot go there, even if I want to. So you take one, you get one. Okay, no, I've heard of colleagues talking about it, but I've never experienced it. I'll add it to my list. I found a couple of you, even on the other presentation, find a few that I'd also put it on the back pocket. Because this document that we created, it will purpose this for it not to be strict, not to be defined, so be an ongoing, okay, do we find a better mold and capture? Okay, maybe that's the next one I'm going to use. But thank you. That's it. Everyone's hungry for dinner, that's why. Yeah? Okay, thank you so much.