 It is 11, I'm sorry, oh, you mean I have to talk into this thing? Hi, everybody. It is, I want to say 145 because my computer is in Eastern, but people can do the conversion to 1045. This is a session on updates from the Drupal security team. If you have questions during this, you can go to slido.com and enter code SECTEAM and just put your questions in there and we will address them as we go through this. My name is Michael. I am a member of the security working group, I'm sorry, I don't use the term, but yes. I'm a member of the security working group. Next to me I have David Snowpeck and Cache, there's another David out there. Are there any other, nobody else is wearing their hat, so I can't quickly scan the audience and see. We're members of the Drupal security team. Security team is made up of about 42 people around the world. We are all, we're mostly a group of volunteers who do work to keep Drupal secure. You probably know us most from the emails we send out on Wednesday in the form of security advisories. We come from lots of continents, lots of countries and lots of different types of day jobs. Some of us work for hosting companies, some of us work for the education space, some of us work for Drupal service providers, we've got some non-profits in there. We are a pretty diverse group from our backgrounds. So we do a variety of different things as a security team. We triage reported security issues. That's probably like our primary job of what we do. We help with security related Drupal initiatives which I will show off in a second. We coordinate with other open source security teams. Drupal has a large number of third party dependencies. Go look in the vendor directory. And so we coordinate with those other security teams to help do coordinated disclosure around their security releases. We read and respond to messages that are sent to us either through email or through our issue tracker and we track the trends of hacked sites. So we don't actually help with hacked sites but we like to hear about how sites are getting compromised because it helps us with some metrics around that. There's a couple things that we don't do. We do not proactively find vulnerabilities. Now that's not to say there aren't members of the security team who don't go out and try to proactively find vulnerabilities. Sam is not here but he is one of the more prolific people who go out and actually look for vulnerabilities in code. But as a team we don't go out and proactively find vulnerabilities. If you want to, you don't have to. You don't have to. We don't review maintainers code and we don't help fixed hacked sites. Joining us is XJM and she is a security team member and I introduced everybody. And a release manager for Drupal 8. An overview of the flow chart of how work happens within the team is we'll get a vulnerability reported to us. There will be some initial triage that's done to make sure it's a valid vulnerability. Once we've confirmed it's a valid vulnerability, we'll actually include the maintainers of the responsible code. So if it's a contrib module, the maintainers of the contrib module, if it's a part of core, the appropriate subsystem maintainers. And then there's kind of, it doesn't show it on that chart, but there's kind of a loop in fixing the vulnerability. We'll get a patch ready to go. Once there's a patch ready to go and signed off on, we'll coordinate on drafting the email, the security advisor that goes out on Wednesday. We'll choose a Wednesday to handle that release. And we then send that out to the community and hopefully people update their sites. We release security updates on Wednesday. Our window starts at about 4pm, I'm sorry, noon Eastern, 4pm UTC, and goes until about 5pm Eastern. With security advisories, we encourage maintainers and in core, we make sure that the advisories contain the minimum amount needed to fix the release. We don't want to actually fix bugs in a security advisory. We want to make these easy to update your sites with as least dependencies as required and as least. And to minimize the chance that one of those bug fixes will actually accidentally break your site, which would then disincentivize you from updating to the security release. We want you to update to the security release all the time immediately. You can follow us, that's very loud and feeding back on me. You can follow us. The best way to follow us is on your Drupal.org profile. Click the edit page and under newsletters click the security release. There's also Twitter, there's also RSS feeds. There is also Slack. The security team is involved with a large number of other Drupal ecosystem programs. The Drupal 7 extended support program, Drupal Stewart, the automatic updates initiative and Drupal 6 long-term support. If you're interested in joining the security team, if you go to security.drupal.org, forward slash join, it'll actually give you another link to click on that is much too long to put on the bottom of a slide and these are some of the requirements in joining. As some of you may be aware, Drupal 7 is reaching end of life. Once Drupal 7 reaches end of life, the security team will no longer be providing security advisories for it. There will be no more core patches made on the core repo and it will no longer be supported by the community at large. There are some solutions for this though. Drupal 7 extended support vendors will be, Drupal 7 extended support will be provided by vendors. If you're interested in becoming a vendor, here is a link you can go to and as of now, we luckily have two vendors who have already been approved. That's my Drop Wizard and Tag 1. Okay, we're doing great on time. One of the things I want to talk about briefly are some security best practices. There's a large number of sessions here at Drupal Con that go over this material, but I'm going to quickly go over these and I'm going to use a metaphor to do these in just a quick show of hands. How many people brushed their teeth in the last 24 hours? How many people would just out of curiosity think it would be okay to just brush their teeth like once a month or once a year? No one? Oh, maybe I should put my hand down. Brushing your teeth is a best practice. We all agree this. We all brush our teeth for a variety of reasons. It prevents bad breath. It prevents cavities. It's good hygiene. We would never think it would be okay to occasionally brush our teeth. Security isn't a checklist. You can't just check the box and be done. You have to continually work at security. It should be part of your weekly, monthly process. When you deploy new code, when you make changes to your system, you are potentially changing your site's risk factor. As a result, you should evaluate what that change is. Within my day job, I have security auditors that knock on my door, I don't know, maybe once every nine months or so. They ask questions and I answer them, but if all I did was pay attention to them once every nine months, I'd probably have a lot more sites compromised than I do. Automatic updates is upcoming. There is an initiative on that. If you're interested in automatic updates, please join us on Friday. We will be sprinting on automatic updates in core. There was a session yesterday on that that was recorded, I think it was recorded. Covering that, I'm not going to go into too much details on that now. Drupal Stewart is a new service from the Drupal Association and the security team. I'm going to briefly go through what Drupal Stewart is, and then I'd like to just turn this over to questions for everybody to ask. It's really the point of the session is to ask questions of us. Drupal Stewart is a web application firewall that protects sites from certain vulnerabilities before the vulnerability is disclosed and the update is released. There's often this gap. The security team publishes a fix, say 1 p.m. eastern on a Wednesday, but 1 p.m. eastern in your local time zone is 3 a.m. And so either you have to wake up and patch your site, or you have to take the risk and wait till 9 a.m. the next morning to patch your site. Drupal Stewart attempts to solve some of that with a web application firewall. A web application firewall works by filtering requests before they hit your server. So you have the internet, people making requests to your website, which is kind of where cash is sitting. And as the request comes through, the web application firewall in the middle looks at those requests and decides whether or not they should pass or not pass. Maybe if they should pass it lets them through and if they shouldn't pass, it basically blocks the request and sends a message back to the user. This doing this in this way lets us prevent sites from having to be on Red Alert for like waiting for that patch, as I mentioned earlier. There's unfortunately a couple limitations with this. This only is going to apply to highly critical core vulnerabilities at least to start with. There are some types of vulnerabilities that actually cannot be mitigated with a WAF. And so this won't actually help them. So how does this work? And before I get into this, please do not take pictures of this panel without asking first. And well, actually let me just rephrase that. Please do not take pictures of this panel. The slides will be posted on the session note at the end of the session today. So how does this work? Security team identifies that a reported vulnerability is a highly critical and mass exploitable. It has to meet both of those requirements. For example, SA core 2018-002 was highly critical and mass exploitable. The security team determines whether or not this vulnerability can be mitigated by a WAF as not all vulnerabilities can be. And it could have been mitigated by a WAF in this instance. And the security team will release a PSA, which we typically do for all highly critical mass exploitable vulnerabilities, and it will indicate on the PSA whether or not the vulnerability will be covered by Drupal Stewart. The Drupal Stewart WAF rules will be communicated to our vendor partners and put into monitor only mode. And so what that will mean is that it won't actually block any traffic, but we'll get hits on what would have been blocked that helps us refine our understanding of vulnerability but also make sure that the rules that we're going to push out don't break sites because that would be bad. Security team and the partners review these rules. We make refinements and prior to the release the WAF rules get switched into an enforcing mode so that we will actually start enforcing those rules as they come through. And the security team and partners then push that out. The pricing on this is broken down into three tiers. These three tiers will likely be renamed. There is a community tier where we're targeting between 100 and 250 a year. This is for smaller sites. There's a standard tier, which is for non-enterprise hosted sites that will be available through a trusted partner. And then there's the enterprise tier, which are for your hosting companies. They're all a little bit different. The enterprise tier actually can do a little bit more than a typical WAF because they're hosting companies. They can actually inspect the PHP request. They can do other things with the vulnerability itself. Why isn't this free? This is a great question we get. Code is free and always will be free. Drupal is licensed under the GPL. Code is free. But this is not code. This is a service that's provided by vendors. And there's costs to running this service. The patch is always the best way to mitigate all risk. Drupal Stewart is kind of a, I am feedbacking a little bit, Drupal Stewart is a stopgap mechanism. It's better than nothing, but it is not a complete mitigation. The patch is. Why can't we share this with everybody? Well, unfortunately, the nature of those WAF rules actually might disclose exploit paths on the vulnerability, which is why we can't just share the rule with everyone. However, once this starts to get mass exploited and is publicly reported, we absolutely can share it with other people. And probably through, there's a, I'm not quite sure how to pronounce that, S-I-W-E-C-O-S is a hosting platform that is designed to share, among other things, firewall rules for known vulnerabilities. If you wanted to be a partner, there are some requirements in this. There is a URL to get more information on this. And if you'd like to be added to the potential partner list, there's a list there to be emailed. But I'd like to take the last 15 minutes of the session and see if there's any questions from the audience. You're free to submit these through the Slido platform, as well as just come up to the microphone and ask questions, of course. Since I was pressured into coming and sitting up here, I thought I would add one update that Michael did not include in his presentation. Another thing that the Drupal security team has improved in the past year is that minor releases for Drupal 8 core now receive a full year of security coverage instead of only six months. So if any of you have had a Drupal 8 site for a couple of years now, you might have encountered a problem where on some random date, like October 4th, Drupal 8.4 is scheduled to be released, and you know that Drupal 8.3 is going to lose security coverage almost as soon as this comes out. So suddenly you have to scramble to get your site updated, and then maybe there were things in Drupal 8.4 that were disruptive and breaking. I'm using that as an example because we actually broke Drush with that release. So after our experiences with that, we changed the policy so that there's two minors that have security coverage at the same time. There's the actively supported bug fix minor release, which right now is Drupal 8.6, and then we're also at the same time providing security releases for Drupal 8.5. So you have a, instead of it being like you have to get your update done on a specific date, you now have six months in which your business can plan ahead and schedule, okay, we're going to do our minor version update for Drupal core. And this time we know that makes sense in our businesses. Practices, our university schedule, whatever. And so I encourage you if you're doing your update to Drupal 8.7, coming up on May 1st, just keep in mind also that you can continue to run Drupal 8.6 safely until December 2020, and just plan to do the Drupal 8.7 update at some time that works for you between now and then, so. Thank you. Yeah, hi. Question about the Drupal Stewart. How is the traffic routing handled that you are protected by the WAF? I'm still kind of confused by that point. So we are looking, we've currently sat on RFPs on that to determine what the community tier is and the individual tier, but you will likely route your traffic through a CDN provider. And so that CDN provider will take care of it. For the hosting companies who become the enterprise partners, they will direct you on how to route their traffic, where they may just take care of it for you as I look over to one of those. So it'll be, it'll be, you know, it'll be fine in that way. So the idea would be you'd go with one of these companies. If you're part of Drupal Stewart, you'd stay with this company and continually have your traffic passing and then, okay, gotcha. Thank you. You could route your traffic when the PSA comes out and stop routing it afterwards, but that's a lot of work to do potentially. Sure. Okay, thank you, I cleared it up. We did get a question through Slido. There's a lot of questions through Slido. I just wanted to say to you and the team, you are awesome, nice work. Thank you. So appreciate the security team, sets Drupal apart security. What, I'm assuming this is what security module should we all be using? TFA is one of them. There's a security review module that comes to mind. There's the content security policy module that helps protect against cross-site scripting, set kit, paranoia in Drupal 7 is a great module, not really needed as much in Drupal 8 because we removed the ability to run PHP code in Drupal 8. Thank you to whoever did that. How does a contrib module maintainer get security coverage? That is a great question. There is an outdated project application queue mechanism that is there. It actually is still being reviewed. There are still people who follow that queue. If you feel your project though has stalled for now, you can email the security team and we can help bump that project along. Our long-term goal is to replace that with a more interactive format such as code examples and a quiz and it's an automated process as opposed to what's there now. How does the security team work when there's a vulnerability on softwares that are powering Drupal like PHP and Apache and third-party tools? Security team doesn't really get into the scope of what you're running on your web server. I've got another slide that I didn't give here that if hosting is not really your business, you shouldn't be hosting your own site. I realize that might be a somewhat controversial thing to say, but we all choose our lines of work and for most of us, we are not hosting providers and so if you are trying to host your own site, you have to worry about maintaining the security status of your servers, you have to worry about the updates of all that software availability and it's most oftentimes more economical to find someone to host that site for you. I will say though sometimes when there is a particular kind of vulnerability that's discovered in PHP and the whole PHP community has to respond to it, we have done security releases in those situations to add support to Drupal that protects Drupal from the kind of exploit that's there that's happened a couple times in the past and I think there was also a question about third-party tools there. That could have been referring to third-party dependencies. So for example, Drupal 7 depends on jQuery, Drupal 8 depends on a lot of stuff including symphony, jQuery, guzzle, there's lots of Zen framework components and stuff that we have dependencies on. So when upstream projects have a security release, if the security release is directly exploitable in Drupal, then we will try to do a coordinated release with them and do a new release of Drupal Core at the same time that updates to the fixed version of the dependency. If the dependency does not, is not directly exploitable in Drupal, then we don't do a Drupal Core update for it. So I'm not sure, in case that was the question, I just want to make sure we get the answer for that too. Thanks. Quick question about modules that are covered by security advisory and that aren't. So I know that stable releases are covered, but often there are cases where an alpha release is there or a dev release and has patches that are working. I guess my question is, how frequently are those modules checked to see, okay, now it's covered or is it just kind of semantic versioning to say, okay, this version works, we scanned it and now it's covered by the policy? How does that work and what is not covered? So the security team doesn't proactively review modules. The project application queue was an attempt to somewhat do that as it flowed through. But for the most part, when you click on the report security vulnerability link on the side of project pages, we direct you where you should post that vulnerability based on both is the project covered and is there a stable release? There's probably some improvements we could do around there. We also don't allow projects to opt into coverage if there's an open tag release or an open tag issue with a security flag on it. It's really a question of whether something goes through the security team's process or just happens in the public, right? That's really the only thing that's different. But if you don't find any... It's on the module maintainer to just mark a stable release. I think that's exactly. So someone has to actively say, wait a minute, we're not really vulnerable. Here's exactly. And at that point, well, they may or may not have security vulnerabilities, but by tagging their stable release, if they've been eligible or to and opted into security coverage, at that point, all of their stuff will be considered a security issue if it's reported and handled in private according to our process. Yeah. Something saying that it's covered by the security team does not mean that it doesn't have vulnerabilities. I think it's probably safe to make the complete opposite assumption that every module has security vulnerability rights. Like, if you just look at the vulnerabilities that the team publishes, we're publishing vulnerabilities primarily for the most commonly used things, right? Like, you know, you could say, like, well, views has been around forever and tons of people have looked at that code and everyone depends on it. But like, we're still going to keep finding security vulnerabilities and views, right? But so I guess the question is, I understand in court, you're going to actively monitor it. But for those other modules, you said, you don't actively. You know, unless a vulnerability is reported, you won't actively audit those other modules. So that's not the job of the security team. Our job is to maintain this process. Other people in the community are constantly checking, contriving, core, and looking for security vulnerabilities. And when they find them, they come to us and then it goes through the process. Great. Thank you. While you're coming over to the microphone, is there a good method for assessing the vulnerabilities of custom modules? There are some tools that try to automate this process. But honestly, the best method is to do a code review. Find someone to help you do a code review. Read over your own code. I typically will do the thing where I'll go through and explain my module to a fictitious person who's not in the room and just walk through what I'm doing out loud and why I'm doing it. And I will often find a lot of things that way. But doing a code review, especially doing a code review of code you didn't personally write, is really the best way to find security vulnerabilities. Peter and I just got done with a session that did not get recorded, but the slides are available entitled Cracking Herple that shows a lot of the common patterns that introduce security vulnerabilities. And so that's a great place to start. I think I'll just throw in there, if you're not familiar with a coder module, it has some rules for PHP's code sniffer. And it will help find some of the very, very basic security vulnerabilities which are more just misuse of the API. So I would consider it a very, very low bar, but you can run it against your code just to kind of get started. I'm going to add a little bit more to the gray area of what your charge is, in addition to what he was saying was that when Drupal 8 was first released, the encrypt module was actually really far from actually being ready. It remained in beta I think for almost about a year and stuff like that. For my organization, which has to remain strictly HIPAA compliant, we had a lot of problems actually trying to use it. And there was a lot of questions whether Drupal was secure and secure between people who are not familiar with open source learning community. It just seems to me, I understand this is probably gray area for many of us to understand and you guys are very clear what your charge is. But it also seems to me that you have actually have a great deal of influence. So actually make sure that these things are actually maybe up to snuff, or at least for release. I would point out that there are tens of thousands of contributed modules for Drupal Core and we have a volunteer team of 30 some people. Like the scope of work is enormous. I guess the question is, are you, we try to, I think that we try to influence by communicating best practices and sharing with the community what things are. But any, so is your concern about this specific module, which was a security improvement that was important? Well, it's an encrypt module which is used for security and security of data. But also at the same time, it wasn't necessarily ready. I understand kind of what's in there. That's on those project maintenance really. That's a very big gray area for a lot of people to understand. But it would actually make things actually a lot more assuring for a lot of people. I think the best thing to do in that situation is to get involved in that project queue, find out. From the maintainer, just simply ask the question, what's holding you back from creating a triple aid version of this module? And then if it's something that's important to your organization, see if there's a way you can help them. Do they need money? Do they need developer time? What kind of support do they need? Contributed module authors, they're volunteers, a lot of the time doing things in their spare time. And the best thing to do is find out if you can help. I want to use this module in Drupal 8, what will it take? OK. Then just a quick follow, are you guys involved also with from security aspect of the release of Drupal 9? Well, so Drupal 9 is going to be basically exactly the same as Drupal 8 with deprecated cold layers removed. Starting with Drupal 8, we've adopted a process called the continuous upgrade path, which is a concept and practice that we have borrowed from, learned from, symphony. In essentially, Drupal 9 is not a complete rewrite of code. Drupal 9 is Drupal 8 with deprecated code removed and updates to core dependencies. And I will say that the Drupal core product, like new code, we do try to, we take into account security when we add new code and features to the module. It's not to say that there's not vulnerabilities. There always will be. But it's an ongoing process to find and report them. But it's not going to be something or it's going to be like Drupal 9 is an entirely new thing. In fact, Drupal 9 is probably going to be the safest release of Drupal 8 because it will have no new features in it. It will be exactly the same as Drupal 8, 9, with just accept that APIs that were deprecated will be gone. And so hopefully, we'll also have less of the problem that you described, where a module you needed was not available at first in the Drupal 7 to 8 update because of this continuous upgrade path deprecation process. It makes it a lot easier for modular developers to write code that's compatible with both Drupal 8 and 9 at the same time. And so that means it's less work for them to be compatible with the next branch of Drupal. They can do the work at a time that works for them in their lives and their schedules rather than having to be, oh no, Drupal 9 is going to be released now. Let's all rush. And I have to find time for this volunteer thing that I posted on the internet a while ago. Get it upgraded to Drupal 9. And it should be a lot easier for them too. So hopefully, we'll see less of that with this release. Thank you. I think the stat is that 40 something percent of top X modules are currently Drupal 9 compatible already as of a week ago when that stat was run. Can I add something to the first part of your question? Sure. Just like about the sort of conception or misconception of what the security team does. The security of Drupal is the responsibility of the whole Drupal community because it's an open source project. In order to do the sort of coordinated disclosure that we want to do for Drupal, which improves the security, some information needs to be kept confidential. And in an open source community, how do you do that? Because the code is available, everything's out in public. And the way that we do that is by making a small security team to handle just the things that need that confidentiality. The majority of security work in Drupal is to be done by the whole community in public. In our job, it's just managing that component that needs to be confidential. If that answers your question. It doesn't. There's other questions that we can go on. I know it's a long discussion, but I'm satisfied with the development. Thanks so much. Thank you. So unfortunately it is, I want to say 215, but it's not 215, it's 1115. And we need to move on because the session is over, but we will be hanging around. The security team typically wears hats that are either white, black, or blue. So if you have a follow-up question, feel free to find one of us. But thank you, everybody. Thanks for the question. Thank you.