 Good afternoon, everyone. And who is ready for another security talk? So we are just d-dosing you with all security talks. So you wake up tomorrow like Neo and it's like, I know security. So let's get into it. So my name is Jana. I'm from Brisbane. I started Drupal full-time maybe about five, six years ago when I quit my full-time day job as a React developer and just joined the Drupal herd. It's cool so far. And why do we need to talk about security? I think it was raised so many times today that it's even if we are just doing CMS and it's only public information that's available, you still have your reputation on the line and the intruder can insert their code, they can insert their malware, they can put in some malicious forms, for example, with Twitter hack when Elon Musk or Joe Biden or even ex-President Obama, I would pay by my cryptocurrency here, which was a hack which now there is a court case in America. $800,000 were stolen from people who said, oh, if Obama says cryptocurrency, I'm going there. So yeah, protect. And to disclaim my presentation, the cybersecurity is there on all sorts of levels. We've got infrastructure, networking, systems, application, human. We've talked about the human security today as well. This talk will be focusing on application-level security and application-level concepts, although they do sometimes interlace. So we've got on systems, we need to have antivirus, but on application security for Drupal, you have to install the module to enable this virus scanner to run on the files that people upload and your users or content editors upload. So for the agenda, what is Secure by Design? And we'll look at the Secure by Design project. We'll look at the enhancing development practices quickly and there will be an action list for you to follow up for the next six months. Prepare. Secure by Design has been defined in American publication. I'll come back to that publication as a security is a core business requirement, not just something that someone comes back with penetration testing and saying, hey, fix all those issues that you can do it later on. You can do it at the design phase so that making sure that you follow all the guidelines that have been produced. And the government has been slow in the past, but since we had so many horrible data leaks recently, they've been actually pretty good, releasing a couple of guidelines recently. So this one is not very recent. This is Australian Cyber Security Center securing your CMS, which specifically was designed for even GAP CMS installations. You can find it here. I'm not going to read those. The most recent one and the most interesting one because this is how optos got hacked, the guidelines for software development practices. It was released on 2nd of March, which was pretty much after the optos shenanigans. And to go back to the essential aid, if you search for development or software engineering or anything in essential aid that doesn't deal with the development environment or software engineers, because everyone has software engineers, software developers. So it's more for your users, but they're like, our developers wouldn't want to deal with them. They're too hard. Let them build their VMs and do whatever poke holes. So this one, the guidelines for software development from essential aid. And from the Americans, from the United States, Cyber Security and Infrastructure Security Agency, from NSA, FBI and six countries including Australia and New Zealand, Secure by Design, Secure by Default Publication and the whole website. So those are the guidelines that I'm basing on the Secure by Design presentation. Have a look at those publications. Also, OWASP, yeah, there is Top 10, blah, blah, blah, but there is more interesting publications than OWASP. It's the Security Testing Guide, which actually is a huge document of the penetration testing, a guide for the penetration testing. Pick and choose those specific items for the developers that you might implement specifically to fix those pen test issues that will come up later. And the cheat sheets from OWASP. So that's also a lot of different publications that deal with different security topics that you can just follow those practices to make sure that your website will pass the penetration test and it's deployed the most secure. So based on all those guidelines and all those publications, I created the, let's create a Secure by Design project. So I would say, oh, we need to create a project so let's start from day one. We care about security. We have those guidelines. Let's just put all the tasks based on those guidelines into that Secure project. So that into that Secure by Design security first project. So I based it on GitLab. That's those little tasks that just screenshots from the GitLab. So all of the guidelines now do SAS test. So let's put those into tasks. Also OWASP says you have to have your secret management. It costs money, it costs time. So let's put it into tasks. How do you manage your tasks? Your secrets, how do you know that developers don't commit those secrets into your GitLab? Maybe you should install a pre-commit hook that checks it. So there is a Git Guardian for that. All those tasks, it does take time and money to implement. So it has to be there. It has to be included in your project. Next, we're moving into vulnerability disclosure program. So all of those government publications do talk about it. So we'll go back to the clients and say, what's your vulnerability disclosure program? What's the email, who's going to be monitoring it? Things like that. For example, we have security at the XT module that creates that little file that tells all the hackers, white hat hackers, where to go, who to contact if they found something. GavCMS has this by default in their Composer, but they don't implement that for some reason. Then next one is HTTP security. So all the... There is a specific test in the pen test. It talks about making sure that you run all your TLS certificates, all those headers that you need to remove some Drupal headers to make sure that you can't fingerprint your web application. So there is a module for that as well. For the security headers, if you have second or CSP for the fingerprint, it's a remove HTTP headers module. So that's another task to implement to make sure that your Drupal installation will be a bit more secure. Authentication. There is 10 different tests in a WASP pen test guide for the authentication. There is seven different modules you can install on Drupal that are not core modules that you can actually configure and make your authentication to harden your authentication to pass the pen test. So try to estimate how long that will take to implement. It's not just five minutes, obviously. So it needs to be included in the project. And if you have partially decoupled or if you have APIs, that's a new level of complexity, a new level of ways to expose your data really easily. So make sure, let's add the configure your cores headers. Make sure that cores is configured. Make sure that you have rate limiting on your APIs, monitoring, and there is 10 different, like this API security mega task from all WASPs that you need to make sure you are looking into. So, for example, in this API security example, that's a Drupal partially decoupled somewhere in Australia. What's wrong with this picture? Revision logs message in API to unauthenticated user to see. It doesn't have, it's not supposed to be public. And this company doesn't have vulnerability disclosure. So, hey, contact, please fix your API. It shows some things that's not supposed to be there. And another level is a production readiness as well. This is a mega task that actually from the both Australian publications about the security of CMS and the guide. And they do specify this that development testing production environments are to be segregated, no more C panel. And they do say that make sure you disable everything that's not supposed to be running on production. There's a module for that, like config ready, so don't do your modifications on production whatsoever, according to the government's publication guidelines. Also, you've got hide your public files, like change log, upgrade TXT, things like that. They always come out of the penetration test and saying, oh, those files not supposed to be visible, things like that. So, you can update and add as many more tasks to the production readiness, production ready stage. And this is why this is our secure by design project. So, now nothing has been written, the project hasn't been created. There's probably requirements is still there with BAs somewhere, but you already have 15 tasks to think about the security and try to estimate that. So, try to estimate how long it will take, like 10 days or 20 days to configure all those things, depending on complexity of authentication and API requirements. So, we'll just put ourselves into security mindset. We'll estimate the project better, now we'll already include extra days for the security and we'll prepare ourselves for the penetration testing and we'll be better compliant with government guidelines. So, the next step is enhancing development practices. So, all those publications do talk about using frameworks, templates, handling input and output encoding and SQL parameters and things like that. And we can say, oh, we've got symphony and Twig and we know VASP, so we're okay. Looking back in the five years of Drupal and country modules statistics, they're still there. There's not too many SQL injections, still the biggest one is authentication bypass so that's the one that requires more knowledge, deep knowledge into what's happening with your code. Cross-site scripting is still there. So, yeah. Like the first keynote today was Laura was saying that we have 30 million developers and 1.2 million developers of new developers coming into the industry. They might not know about any of these, they're just fresh devs copying, pasting around things and it's like, oh, it works, cool. There are easy fixes for XSS, for example. The CDNs like Cloudflare will stop XSS just there. It will say, no, you can't do that. You can do quickly scans. Drupal has really good documentation practices for tweaks, like using API functions and DB abstraction layers and things like that. But sometimes it's quite hard to fix. Like, for example, this is an example from access bypass from Drupal security issues. So here we are using symphony HTTP calls, but you have to have deep knowledge of cache control and all the things you can set in your cache to make sure that this particular payload is not being cached on the browser or somewhere on the edge for someone to steal because this payload actually contains API keys. So we can do learn. Just look at the Drupal security advisory issues, find the actual line or commit that fixed that and see what happened, see how they fixed it, see what was the issue. In this case, it's just the XSS filter applied on the input. Or in this case, it's a SQL injection, so see how they fixed it. These are all, like, within a year. This was from 2022. And practice. So pick up a module from a country module and compare it to some very well-known module, like, for example, Cloudflare versus this module. I'll show the example next. Check how it's configured, how the secret's being managed. Can you run configuration? Are there permissions? Are permissions being checked? Are they properly checked? Is there a raw filter on twig template? Don't do those. And so on and so forth. So, for example, Cloudflare, we have a path to admin, configuring the Cloudflare in the admin, and it has the permission administer Cloudflare. And the module X has a path to admin to configure this particular module, and it has permission access control, access content, anything wrong here? It's like, anyone can access it. And action. Well, I have a... Actually, I thought I was running late, but no. Anyway, and for the action, next week, if you haven't subscribed to Drupal Security Advisory, subscribe. There's a lot of other... There's symphony security, NPM security, there's Australian cyber security, newsletter and mail that you can subscribe to, to know about everything that Australian security agency wants to notify you. There's a New Zealand version as well. It's American, so just... That will just lift your awareness of what's going on. They don't spam, they just usually send those emails once there is a moderate or high up vulnerability has been discovered. Just go through those publications quickly. The guideline for software development, security by default tactics and security testing guide from OS. Search a code for raw in Twig. Drupal Core has three... Drupal Core 10 has three mentions of raw and it's specifically where it needs to be used. If you're using it... Some junior developer can just see it and copy paste it around because it's easy to see what's being outputted. It's not a whole array. It's just a value and that can just go downhill quickly. And around dependencies, audit and plan updates or composer audit see what's happening there. For the next three months, brush up on your Drupal and PHP secure coding standards and best practices. I've got all the resources available on the last page. And schedule and house security discussions. So with your teammates, pick up one of the vulnerabilities that were discovered in Drupal in Core or in Contrib and discuss what happened there because those couple of examples there were just one-liners, but there are some that have several files that look into how the access has been circumvented and how to prevent that. So it's like a whole new permission level. And also make your project managers, business analysts aware about how to start the project, secure by design project or security first project so that they'll say, okay, we're estimating this will take three months plus five days or 10 days for the security implementation of all those things that were maybe even more things from the secure by design project. And just review your current projects and see where you have a gap in the security, the definition, the limiting of your APIs or your APIs may be exposing things that are not supposed to be exposing, like can you actually pass the penetration test right now? For the next six months, dive deeply into the OLASP Cheatsheets and the security testing guides. If you're doing GraphQL, they will have lots of GraphQL talks. There is a security cheat sheet for GraphQL, what to do, how to do it. If you're doing Laravel, that's there as well and inputs, SQL injections, authentication, it's a great resource. And then start your next project as a security first, a secure by design. So put all those actionable tasks that will actually help you to estimate your project better and run your project more secure. In the end, you'll have a better security of the project. And try the online security training or start a formal certification qualification. There is a Google cybersecurity certificate available or Portswig of Security Academy or Lara as a keynote was representing Secure Stack. Also a little school for the security. You can become a OLASP member and it's only like 50 bucks and it gives you a secure flag, access to secure flag portal where you can learn, protect your flag or you can capture the flag type of thing, game and learn how to do the security. So, and these are the resources. That's a little project that I've created. You're welcome to contribute to it or ask me any questions. This project has all the tasks and all the modules and all the links to all the Drupal and PHP and JavaScript best practices and a couple of more examples of core contribution and fixes of the security issues. There are just tickets in GitLab issue. I was thinking of just exporting them as CSVs and then if you are creating a brand new project you can import whatever. Yeah, it's that triple. Well, it's pretty much like whatever is Drupal out of the box doing for the default Drupal you would have to do the same for the decoupled. So, you need to make sure that your forms can be forged and that the input is validated on the actual, when you save it so, yeah, consider it the amount of security and estimation additionally and especially it's too easy to expose if you are not writing, if you are just displaying things it's too easy to expose some fields or some items that are not supposed to be visible to the unauthenticated user. So, additional testing 100%. I hope tomorrow you'll wake up as a security specialist at least signing up to the all the security advisories. Is everyone signed up to Drupal security advisory? As a symphony advisory? Australian cybersecurity center or New Zealand cybersecurity center? No, they did send a thing about the log4j and the recent one was about C-Panel.