 Thanks so much, Amy June and welcome everyone appreciate you making out to the session and the rest of bad camp 2020 It's an exciting week and as Amy Jean was talking just now this is the last day so it's kind of we can we can kind of go out in style I guess So today we're going to talk about that's all about For the agenda today, we're going to cover what's security first. What does that mean when you hear that security in the Drupal community. A little bit about the organization OWASP and their top 10 web vulnerabilities and then dive into what I think is really interesting and that's Drupal best practices and solutions. And then we'll have time for some Q&A. I would say I'm watching the chat. So if there's questions that crop up I will try to keep my eye on that as well and we can probably stop to ask if there's any questions or just check in periodically as we go through each section. So we can kind of cover it there. So my name is Mark Shropshire. I go by Shrop that may be how you know me if you do know me, but you can call me Mark or Shrop it's fine. And I am a senior director of development at media current. I live in North Carolina about 15 miles northeast of Charlotte, North Carolina. And I've been a technical team leader for a while, and I'm really into mentorship and leading teams. I do enjoy music, listening to music and performing music, recording music and all that stuff. And just a few of the skills that I'm into right now. So media current, a little bit about media currently start off. Media current is an open source expansion partner, meaning we leverage open source technology to help tie in all kinds of systems. And of course, Drupal is a big part of that into an ecosystem within enterprises. And our mission, it's all about bringing together the best and talented team members out there and building the best solutions for the web and applications. Okay, so let's jump into what's security first. And Adrian hello, I see, see your mention there in the chat. So security first. This is really all about going beyond beyond just compliance beyond waiting till the end of when a project is about to launch. It's about thinking about security all the way through your project and even into maintenance cycles following. I would just say security is hard. It's always challenging. The implementation is really high level and you can spend years getting better and knowing more about security, but things change just like the rest of technology and technology world. So it's hard. It's simple to say that. But I did want to jump in as promised on the abstract for the session. They want to jump into some planning items that you may want to cover and think about when you're thinking from a security first standpoint. So the first thing that I think is important is to really be proactive and get get with your stakeholders. I like to ask stakeholders and they may maybe they're in the marketing team. Maybe that's our key stakeholders there in marketing, maybe a chief marketing officer and team. I like to find out group who's your you know who who's the security team who's leading that maybe a different area. And I definitely like to ask about that so that I can go ahead and start building a relationship with those folks build trust. So they know that you know that I take security seriously and the team and that we want to go ahead and start understanding their their security concerns and maybe get copies of their policies and expectations. So a layered defense that means that while we're talking Drupal and everything's about Drupal. You know overall it's back at least the core to a lot of our systems layer defense means you want to have security throughout your hosting infrastructure. You know and all the way through the application so it's not it's not just one thing there's also just security aspects to think about with. You know are your developers on encrypted hard drives on their laptops and things like that so there's a lot to cover. You also want to think about security through architecture reviews that's a good place to go ahead and talk to the security team with your stakeholders and have them review architecture with you and your plans. There's some kind of continuous development processes that are always good code reviews, I believe are critical that's a great way to find security issues, reviewing code. So, I like to require code reviews of all code going into a project, and then also automated testing that's another way to discover some security issues and I've got a just a brief example of that a little bit later. Of course just continuous improvement so just thinking about hey we've done maybe we've accomplished and solve some other security issues or prevented some you know we've got some defenses set up. What are other things always be thinking about as a team what are other things that you can do. And then I'm always interested in security audits. These can be one offs just to see where the current project is currently at from a security stance and then and then some type of ongoing auditing I think is great. A number of our clients at media current have systems and I'm sure maybe you've run into this to where they you know they've they've hired a firm or a service to actually handle the security audits which is I think fantastic it gives us a lot of information. And then documentation is really key. I know that you could say that goes without being said but I think it has to be said always documentation can really help in security just like everything else in your project so that others know what's going on and why decisions were made. So this is just an illustration of some of the steps throughout you know building a website building a web application. You know you've got discovery where you're trying to understand the project this would be more for a new build. All the way through support which which would be kind of more maintenance cycles and so just showing you that you know you should be thinking about security all the way through all these steps. It's a good way to approach whatever steps you visualize in your process or have in your processes. Maybe apply this is kind of how we think of projects but at media current but I would I would say that you know think about how you would apply and where you would look at security through each of those steps through a project. Alright let's jump into a little bit on security and the Drupal community overall. First of all can't this is so critical I think to have to mention this we have something that maybe some folks take for granted because they're not familiar with other open source projects but we really have something special in the group of volunteers that make up the Drupal security team. And I just want to these are the folks that are behind all the security advisories that come out on Wednesdays usually they provide assistance they write documentation. They also help with the Drupal dot org infrastructure and keeping that secure. And there's a link here and I'll get the slides out after the presentation today but there's lots of links in here. So don't worry about writing all those down or copy pasting or something but. But just want to thank you send a thank you out to the Drupal security team. Not every open source project has something like this. Lots of corporations have security teams internal but they're paying those folks to do those jobs. And we have a very accomplished team and next time you you meet somebody in person virtually. You know from the security team you know to say thank you for all you do. I wanted to mention garter this is a project that I helped maintain and we've got some examples from garter but this is a security distribution. And it's really built around meeting enterprise security requirements and it's got a lot of best practices baked into it we're always working to improve it love to have your contributions for that as well. But that is a project that I really have a heart for and enjoy working on. And so just want to mention that but you'll see an example of that in just a bit today. So I'll stop there how much x if we have any questions I see some hellos and OK I don't see any questions yet but feel free to drop them in the chat I'm keeping an eye out on those. I'm going to jump in next to a wasp top 10 web vulnerabilities. And you don't have to Google that you can you'll find it a wasp is an organization. That actually has a lot of great security resources out there. And the link there is actually to this top 10 and it is worth a it is really worth every developer reading. And even if you're not a developer any developer out there every developer should probably read this and understand what these these risks mean. And there's there's there's pages on the wasp site about documentation around examples of security risks and even more than this. This is just some of the top 10 and they update this every number every few years. But you know there's a there's a few that we'll cover today a little bit. But you know it's there's just it's a it's a wide gamut of things frankly. You know you hear about sequel injection is a is a thing that you got to watch out for in development where you don't want someone else to be able to put sequel commands in a URL and access a web page and have it maybe drop a table or that's a real common one that comes up as an example or maybe insert data or read data. But you know, even things as simple as sensitive data exposure which can happen just by misconfiguring Drupal, you know and exposing allowing access to content that shouldn't be accessed by a certain user role or maybe the anonymous user. And then insecure deserialization that's come up on Drupal core with Jason API. So I really encourage checking out this site there's a lot of great resources there again and it's and it's worth checking out for sure. All right, so, so this is the fun part I wanted to get through all of that is a kind of intro talk about security first talk about Drupal community contributions and things like that that are out there but want to jump in now to Drupal best practices and solutions. So we've got a few slides and then we're going to go into an actual running Drupal site and kind of step through some real examples and you know look at some modules can help your Drupal site. Just a taste of that but it's a there's a there's a lot of modules out there on Drupal dot org that help you enhance security for your site. So this is just kind of a taste of that. So the first thing I want to cover a little bit that comes up is module selection. I think this is this is really a key piece of Drupal probably applies to things like WordPress plugins and libraries you may want to include in other frameworks, but specifically for Drupal things that we like to look at. And I've got a link to a guide there, which is a blog post on my module evaluation but these are some things that that that I think are really good you want to look at it does the module have a good amount of views. A good amount of usage is the issue queue active. You know, as other, you know, was it how long has it been since the last issue, the maintainer actually responded in the issue queue. If it's a module that hasn't had a lot of doesn't need a lot of change it's okay that it may be a while. But if there's a lot of issues and there's not a lot of answers and fixes and looks like a lot of problems it's something to consider. But that's not doesn't necessarily mean that's bad either you kind of kind of you have to weigh all these things together. And then like what is is other stable releases is there's usually note on the project page that will indicate whether or not it's covered by the Drupal security team. That's something to consider. And, and again, I'm not saying if, you know, you have to judge for yourself based on these and your own criteria and probably write, you know, policies that your clients may have. So I've had some clients that if drew, if the module doesn't have a stable release they won't use it and it's not really a Drupal thing it's more of a that's just their approach for everything and it makes a lot of sense. It becomes really challenging sometimes using Drupal contrib. And we have to have conversations about that. Sometimes to work through that and and explain that the module may be stable and it just may not have a stable release yet. But this is even more of a reason to as maintainers to get stable releases out. It really helps the usage of those modules. You know, are there, what kind of testing is being done on the module or their tests written for the module. You know release status like hot, you know, stable releases often a release is happening or they're at least releases into the dev branch. And then, you know, that plays into commits, what kind of codes changing the frequency of that. So overall read the project information are the good documentation pages on the project that you do have an understanding of how to use it from that. And then overall between risk assessment benefit it really comes down to, you know, this to me a great example in this area here is if if I need a module to do something, and maybe the module does 100 things but I only really need two things that the module does. It may be that that module by adding it has a lot of extra code that I don't need to meet that is going to be running at some point. And it's better for me to maybe just write that code custom, or maybe borrow some of the code from the module, since it is open source and you can do that. So those are considerations that are out there just just understanding though when every bit of custom custom code you write doesn't get reviewed by a community either. So you lose that advantage. But the last mention here I'll say is that when it comes to module selection, you know, just understand that every contrib module that you accept into a project in Drupal and use. That's another module you have to maintain you have to keep up with security advisories on you have to be willing to work in the open source community and keep up with those things to whatever extent is required but that does increase the attack surface which is a security aspect, you know, just because a module looks handy and you install it and maybe you forget about it and it's enabled still. You know that can later become a security issue if there was a advisory or an unknown security problem with it. And so you want to keep that attack surface down which just means in the Drupal sense one aspect is to have less code you can do that by having fewer contrib modules, which is challenging sometimes but it's still something to consider. Okay, so when as developers, if you're a developer and you're writing code, or if you work with developers on a Drupal team and there's code being written. This is a good one to make sure of encoder views it's a good one to make sure of is the team as a team talking about this aspect but use the Drupal APIs. So, I can kind of reverse this a bit. If you don't use Drupal APIs to do things like work with data against a database, like with my SQL, it's, it's a much higher chance that you might write code, whether you use it in contrib or in your own custom code for the project. There's a higher chance that you'll write code that has security issues in it. And part of that's because the Drupal APIs have been nurtured by the community over the years. And many, there's a lot of protections built in to help prevent things like database security problems doesn't guarantee you can't misuse an API, you can still do that. I always, when I'm looking for an, I know I need to do something in code. It's always good to go into the API documentation, which is linked here and and see is there is there already some APIs to handle that. If there's not, that's okay, you can write PHP. But that's something to consider. I also added a link here, which is is always really good for writing secure code for Drupal. That's the reference guide on Drupal.org. And I find that to be very helpful. Okay, so I mentioned that the Drupal security team is awesome. I already covered that. I think we can all agree and give nice applause because that's what a job and I really appreciate them. So one of the things that they do is release security visories and got to link their Drupal.org slash security. That's where really all of this information lies. But just some highlights for that you'll you'll see security visories for Drupal core for the contrib projects that don't come with core, but many of us work on in the community. Also, public service announcements, which sometimes are PSAs just to say, you know, hey, don't maybe don't let anonymous users upload files to your website, unless you've really figured out some other ways to protect those the problems that come up with that. I think that's an example actually happened a couple years back. That page slash security also has information on how to receive notifications. This is really good. So, signing up for email RSS feeds. If you follow RSS have an RSS reader and the Twitter account at Drupal security posts notifications as well. So that's a that's a good one to follow. I find that email to be pretty helpful also RSS another thing to maybe check out is if you use something like Slack or some other communication tool for chat. Usually you can leverage that RSS feed right into Slack or those other communications chat apps and and they'll just appear, which is really handy. I kind of do both because I don't want to miss something. You can get busy on Wednesdays and you know in the back of your mind that there could be, you know, a contrived security release. And so it's nice to have that coming in from a couple of places. And so as far as another another place to communicate is in Drupal Slack, there's is a security questions channel. And I don't usually have to ask the question because somebody in the community will. Are there going to be any releases today and then somebody else will ask questions about the release and I usually find someone's already beat me to the question. I'll just read the answers. But but other folks may ask security questions there as well. One thing to be careful of is don't talk about security. If you think there really is a security problem on a modular and Drupal core or something like that. There is a process. So make sure to go to the security team link on the previous slide and follow their instructions on submitting security issues. You don't really want to talk about that in public until at least the security teams had a chance to vet that issue. But I would say overall, read the security advisory documentation that's there and make sure that you understand how to read a security advisory and what that means and and practice that you know work on understanding how to read it and assess how important is it that they right away. Some of those answers are given in triple slack at times but you can hear input from others but you need to feel good about that you're making the right decisions and does it apply to your site and how severe is it. Those are really what you're looking for. So I mentioned earlier that I was going to talk a little bit about automated testing and some things like that. These are some things that we have in our Bitbucket pipelines at media current. We actually have all of our all of our PRs at least will run Drush PM security, which is nice. It's a good reminder if there's maybe there's a module that is reporting requiring an update has a security update. So we do run those. We're already checking that other places and other times but I still like to have that there is just a catch all the security review module, which we'll talk about here shortly that that module is there that project on Drupal or we run that and it's all in runs through Bitbucket pipelines and you get the output right there in text so you don't just to note that there's there's Drush commands for security review so you don't have to use the UI but I'll show the UI in a bit. We also run the OWASP zap baseline scan which is a mouthful to say but but we do use that and that is a what's called a passive scanner. It means it's not actively trying to attack the site or you know, try to, you know, do cross site scripting against it or SQL injection or things like that. It's really looking for hints of, you know, maybe problems with the site. And I find it really handy and it does find stuff. We've had it find things and then that leads to discussions because maybe the developer that sees it first they don't even really have yet understanding of what that finding really means. And then in our security channel at media currently we have discussions then the follow up with advisement for that team on here's here's all right here's how to handle that one or here's what we think and we'll talk through it as a team so it's real important to do that. And have that team to do and if you're not if you don't have if you're not on a team it's okay that Drupal Slack security questions is a good place just to talk about those things. All right, so I'm going to switch to do some demos here. And let's see if I can change my screen share. Effectively, I think I can. All right. All right, so I'm going to drop this current screen share. And I'm going to share my browser. Okay, that looks like that's working well. All right, before we jump into this little section here, which will take up the remainder of the time. Any questions about anything we talked about so far. All right, so you see a couple of questions here. Gerard is asking about trying to move to Postgres and some modules tend to be DB specific. Do security measures address these instances? Are there preferred DBs? I imagine there's some other folks here on this session. Looks like we've got at least 34 folks who may also have opinions on this. I'll tell you what my thoughts are is overall Drupal tends to work best with MySQL if because there are modules that just specifically support MySQL, there has been goes over the years to make modules in core certainly to work with Postgres. And I think it usually comes in to play a lot with contrived modules that may not support it properly. So I'm not an expert on that. I do Postgres. I do really like that database has a lot of nice features. I've used it in other places but not Drupal. So if other folks have input there, please in the chat help out Gerard. Matt has a question, how do you install and execute OWASP's baseline scan? And that is exactly, Matt, you found it. Fantastic. So yeah, we use the Docker image and Bitbucket Pipelines actually uses Docker. So we have a separate pipeline step where we fire off Docker. And the link that's in my slides to the MediaCurrent Pipelines, that's open source. So when I share the slides a little bit later, you'll actually see how we implement it. And if you have any questions, Matt, feel free to reach out to me. I'll be glad that we want to get that out in the community and want people to know how to use tools like that. All right. So let's jump in a little bit here. We talked about, sure thing, Matt, thanks for asking that. We were talking a little earlier about looking at modules and how to evaluate modules for usage or Drupal projects. This is, I didn't want to pick on anybody else. So I picked on one of my real simple little modules. And this one is, and you can decide for yourself, this one's got some interesting twists, because you can misuse this module and actually create security problems, which is why we have this notice right here. But this is one that I maintain. It really just allows you to extend the time of the password reset timeout. And even though Drupal Core allows you to do this up to a year, that is really a problem. It's one thing if somebody extends it from 24 hours to maybe two days or something, three days, I don't know. Use your judgment, but just note that that password link reset link will still work, as long as you, to whatever time you extend it. So that's the warning on that one. But if I was to look at this module, let's say I needed this because I wanted the setting in the UI and I didn't want to set it in settings PHP. I wanted it to be user friendly or something. I would look at this and see that there's a number of sites that use it. It's not the most popular, but it's not like three sites use it kind of thing. So that's something. We've got stable releases for seven, eight and nine. That's good. There's only one issue. I'll just, I'll fess up. There's a test written. So that's a ding on shop. So I'd like to have some tests written. If you've got any, if you're into writing tests and want to do that, love to have some input on that here. But without getting into the issues, I'll just say that. So, so that those are some things to look at. You can look at the response rate of the maintainers here. You can dig into how much it's used per, you know, based between Drupal seven, Drupal eight and nine now. And because it's stable, it is covered. So the Drupal security team would definitely release a security advisory for this if it had a security issue in the future. And it was, and they were notified. So that's just a quick kind of preview on how, you know, kind of how you might want to look at modules and consider them and that sort of thing. And it's really, it's there's not really a science to it. These are just, you know, those list of concerns we went over. There's a link to the blog post if you want to dig into that more from the slides, but it's something you want to practice and get better at. And you'll probably never be perfect. You know, you'll make mistakes on picking modules at times and realize it later. But at least from a security standpoint, I think we can make good assessments of modules and things like that. And but I can think of reasons like this not to use this module, even though I wrote it. So it's, it's pretty ironic. So and that's, I think that's pretty real. So I want to jump in next to looking at a security advisory example and some things I think about with these. Now, this is the, this is linked right off the slash security page directly to a security visor. I picked a handpicked a security visory that seemed interesting to talk about. And this is one of the contributed projects, advisories. And this is so this is for views bulk operations. It's a pretty popular module. It's been around for a long time for different versions of Drupal. And it's really handy. This one is moderately critical. And one of the things that I mentioned about getting to know more and read the documentation on reading these are really important one is I encourage everybody to go and read up on the risk levels. Click to this link when you get a chance, just some homework and read into the security risk levels and understand what they mean because they are custom set specifically by the Drupal security team. And they're really, they're really important in how you read these. And it being moderately critical, that's kind of, you know, in the middle of things, it's not, it's not, it may not be, you know, the worst security thing. It's certainly not a low security concern, but you get some idea that's moderately critical. And there's also links to help explain those levels. So definitely read those. That's real important. We see here, first thing I read access bypass vulnerability. Well, that does not sound good to me. As a first read, I'm going, I don't like the idea that some of you if I'm using this module that someone can bypass any access controls we have on the site so that that's that's kind of a flag. And then so the module contains access bypass vulnerability that might allow users to execute views and actions they should not have access to that sounds rough to me. But now the next line is really important. And this is always look for if the advisory has anything says anything about mitigation or is mitigated by meaning that meaning that it may not be the same severity for every site or every application in Drupal. And this is an example where it only occurs in cases where you've got a customized action access by means of a particular hook. So if you haven't, if you you or contrib modules or any other developers have not written any hooks and you could search your whole code base for this. And your modules folders. But as long as you're not using hook action info alter looks like we're okay. So that's good. That's good. So that's what you want to check next on the site. You also want to check in which version are you running if it's previous to these versions you want to prepare to upgrade. My recommendation generally is, you know, this is one of those cases where it may not be you may look at and say hey I don't use that hook I think we're okay. So we're not going to worry about rushing out a release, you know this evening kind of thing and get it done right away. But I would generally say, well, we still want to update it and keep it up to date. So, so we roll it into the current sprint or the next sprint and make sure it gets done. I don't don't still want to patch these things. But those are your decisions to make. And if you have questions definitely, you know, work with your teams, asking Drupal slack, things like that for people's opinions and how they approach it but that's and a Drupal security team will not. And please don't ask them because they always have to explain they can't, but they won't tell you, you know, any more specifics and what's in here. Because that can that could leak information that would allow hackers and others to, you know, exploit this in the wild more than it may already be and we definitely don't want that as a community. And also has nice links to folks who have assisted, you know, assisted with it gives them credit, basically, but I think it's great. Credit is well deserved. On that. So I've got a we've got a question here I'm going to pause since I'm kind of done with this section here and we'll jump into a site example. Jeff has asked a question inherited a site that has a URL injection hack the site is out of date with Drupal 758 needs to go to 773 so that's pretty behind and it's currently running PHP 53 which is also not supported. I'm adding that text Jeff didn't say that but that's and it's being moved to seven so that's good. So Jeff's looking if anybody's willing to spend a few minutes with some questions it'd be greatly appreciated so since we don't have time to dig into that. But I think there's plenty of people back camp that could help with that. Please please see Jeff and Jeff that'd be a good one to also post in the main event. Channel as well. And definitely don't, you know, don't post the URL like you did you didn't do here which is great you know you don't want to let a bunch of people know what what site is vulnerable and you're working with but yeah I think there'd be there's some talented security folks at this conference and and experienced developers and others so definitely post that and I think that's a great question I don't think that's an uncommon thing I think we run into this from time to time and that's why we audit sites. Jeff we're asking that's why we audit Drupal sites because people have you inherit these sites and they're out of date and they're way behind and they create and of course it stresses all of us out I'm sure Jeff's you know got a little bit of an increased stress level but we'll see in that and so that'd be great to work on that. Alright so let's jump into a few of the security things that we can do with Drupal so I have a. Okay, ooh, here's the first thing so this is a install of garter for d8 and first thing I noticed I was logged in earlier you've been logged out due to inactivity. So I'm using the automated garter comes with automated log out module, which which banks and a lot of enterprises require they don't want is it's a loss of convenience, but they definitely want to have security teams just they don't want sites to just persist you know like the default settings in Drupal and a lot of web applications frankly where you're just logged in. And by the way you can you can often and we had a cross site scripting issue here we'll get to that in a minute. But you know we as developers won't always agree with the policies of security teams I'll just say that up front. Some of them are outdated like changing policy changing passwords all the time and things like that. But sometimes you know it doesn't really matter if that's if that's your you've got a client you can explain that hey there's this other side to it but sometimes you know that decision has been made and you just have to go along with it but we do have tools to cover either way. It's always good to talk through the and educate I think stakeholders on on security and implications because the security world's always changing. So let's look at first we look at broken access control and I'm going to show the permissions page. So if I go under people. And I go to permissions. This makes this this might seem obvious but this is so critical and I've seen like very talented developers like make mistakes here so that's why I won't call it out. It's not fun but one of the things that that I will make sure teams do before launch is review every permission and it's not it's not a fun task I don't even like doing it but review every permission. Understanding what we want expect of the roles and review every permission and make sure that they're right and maybe you had somebody review with you on a screen share. Not the not the most fun it's not like writing code or exciting things but it really should be done and here's just an example so easy to accidentally check a box. And here's one example so wow this is a flag like anonymous users can create articles. And view published contents find for anonymous let's say that we're trusting authenticated users and that's okay for now we can say that but. And I think I put another one in here maybe. I thought I did. That one's good view comments. Sorry I'm scrolling so fast but I'm trying to remember which one I checked. Maybe I didn't. Well if we're so this is an example if we don't if authenticated users not trusted in this way at least. And it probably shouldn't be because you may have content editors that are authenticated users. This is bypassing all access content access control. I generally am not going to trust all authenticated users to this and that that's probably an architecture problem if you are having to give that out and that's why there's the warning here so. But just an example that if this was said accidentally or maybe set by somebody that didn't understand implications of these permissions. You literally that's like as bad as having like code that's got problems so that you know that's just so access control broken access controls a thing. You can also have broken access control and code though where maybe you are working with the access control. API is in triple and maybe implementing them incorrectly or just you have bugs in there that can cause problems. Alright so you kind of saw a preview to the next one I was going to show and that's cross site scripting. If I go back to the homepage here. Notice that this comes up user supplied cross site scripting error so I had to pop up the JavaScript alert. And it'll do this again but this is an example I posted this as the administrator the administrator just by default had access to do this but I could have gone further and set it up so that. I accidentally configured text formats and and that would have done it so if I allowed full HTML for like authenticated user. That's an example where a user can go in here and if I look at the source. If I can run this so this is a form of cross site scripting there's other examples. This is a real the most simple one but if there's if I can run this JavaScript here I can basically call remote script I can I can do other things. I can run other JavaScript have a whole script in here anytime the user hits that page it'll run in their browser and execute and do all kinds of stuff so. That's one to study up on and keep a lookout for you can also have cross site scripting via code and sometimes we have advisories that talk about that you'll see. Where modules need updates so all right jump it ahead insufficient logging and monitoring so garter adds a couple of things but I think just thinking about logging what what I like to have as far as logs is important. So the first one show is one that garter adds login history this one's really handy so this shows that today I've logged in twice to here is admin. And so it would show this this simple module is just going to create this extra report list and it would show all of the. It would show all the logins you know with with the stuff is on the page you know your user agent IP address that sort of thing it's it's really handy to have as much additional login as possible. We've got another example and that's the built in core recent log messages. So this has a lot of information in it and one thing garter does is it sets DB log which is this which is this watchdog it's also called watchdog but this is the Drupal. Main logging system. Garter sets entries to keep entries at one million you can change that but it's the highest setting Drupal allows and we set it to one million what can happen on Drupal site especially in development and in some production Drupal sites you'll find when you audit. There's a lot of PHP notices and things that just eat up all of your logging. Which creates another issue for your you know frankly that's another security issue if the log is too noisy and you can't see what's going on. Then it's probably not very valuable because you're not going to catch a problem is easy. Now larger enterprises usually turn this system in Drupal off and point it to like a Linux sys log and then they may even use tools to aggregate all of their logs where they can search and do a lot of other fancier things so. So that's but just want to mention there's a there's a number of modules on Drupal.org that help with logging and you know if you ever need to have additional logging for your modules or custom things. It's really easy to add those log entries even to the built in. Long messaging system here so that's something to check out. We're gonna jump to password policies. So. Garter comes with a password policy module. This is not the only password policy type module that's out there. This is probably the one that's been around a long time and has been rewritten for Drupal 8. It's just called password policy so the one I'm probably more familiar with. And one of the things you'll find it a lot of and I've got a policy set up here to show but one of the things you'll notice. Some security teams require password changes ever so many days maybe 3060 90 or something like that. And what really what we really found and this was a this came out of US government. In IST report was that what's really important is long passwords and having people change passwords least of them posting it you know where someone can find it and things like that so. But this is just an example so I don't think you need I think the important things have really good long passwords that are not easily guessable. But that can that can all be debated as well and what's important to factor authentication is also something that is important to do and you can add to your Drupal side as well to enhance this highly recommend it. But in this example I just set up a 30 day password reset which would definitely drive users crazy. And so I'm not necessarily saying that's recommended. But just to show some of the capabilities. You can do things. There's a number of plugins and you can add your own plugins but you can definitely adjust like how long is the password. Let's let's say the minimum has to be 20 characters. And you can't use the username in your password and cannot repeat passwords. You can adjust how often they could repeat maybe every 10 times they can repeat it but to me what's the point like always have a new password it's not that's not too bad. I wouldn't sweat that. All right so security misconfigurations. This one is allowing this is a good example for this is allowing anonymous file uploads with the article content type so I'm going to jump over to another tab here where I've got. I'm logged out so notice I've got to log in here so I'm logged out but by accident or just somebody didn't realize what they were doing they've allowed me to add or a user coming along to the site to add content. So I you know the person sees that and oh I guess I can't come to why is that Oh I know why it was cached for page. I think we want article all right so there we go. So I'm still anonymous and I can create an article and this this is this is really dangerous for number reasons obviously you can put cross like scripting in here and. And load up other things that are allowed possibly if it's not limited although it looks like JavaScript is limited here because of the text formats. But if I can upload a file into public file store which is what set up by default. That means you basically become a file host to the site is now a file host if it was not on my local machine for any other malicious needs out there and. And there there's a you know bad folks out there looking for the that so so that's an example. And the last one I wanted to mention was using components with no vulnerabilities so jumping back here and and it's where 446 so I want to respect the race time just about to the end. So this was the last one I wanted to highlight this this wouldn't seem so simple but it's so easy to forget and not have processes around it. So I purposely installed that VBO version that was how to security release and right here and available updates I can see that wow I'm really running. There was a security update on February 4 I'm pretty behind that's that's rough. So that is that's something to watch for and you really want to make sure that you're up to date. I want to dig in a little bit on things like like for instance jQuery because Drupal Drupal also backports fixes for jQuery and maybe some scanning tools will report that you've got a security problem on jQuery but in reality it's the fixes have been back ported and so you have to kind of pull up those security advisories and and talk about that with security teams so they can verify it with you. And so the very last bit here. And I'll double check. Yeah, Jay I've seen two people want anonymous uploads the web forms and it you can do it you have to implement other security measures but it's definitely it's definitely something I think that stakeholders don't realize really what they're asking for sometimes, but I agree. So we got through the demos didn't want to mention there's a link in the slides here. This is what says CMOs guide to open source security there's some great information in here even about automated testing and processes also include some WordPress things so that's that's cool to and security incident response report so we were given that away because I want people to be able to have this and their system and their setup without having to go out and create it from scratch. But it's something that's asked for by a lot of our clients. And any any questions we can kind of go to that we were running out of time so what maple hit looks like maybe the last one is Jeff how much of a security concern is having CK editor text format with no security filters. When content editors are a handful of known people. That's a that's a great question that's the kind of question Jeff it comes up. I think on our teams a lot because you're kind of way in that it's something that I would have a discussion with the site owners about and and my gut is I would still try to limit and make sure they could only do what they should do because what I've seen this is the problem let's say that we really really trust those editors. The problem is people like to go on the internet and copy paste things and I have seen where people will paste code and and yes thank you Michael. That's it that's the answer they will paste directly from other sources and they think oh it's great look I've got this JavaScript running and so that's a that's one to watch for.