 It's weird to have a microphone that amplifies your voice after all these years of talking into headsets that cancel your voice out and you can't hear yourself talk when you're on Zoom calls. Thank you all for coming. It's great to be back in person. Let's get started so that we can all get through this and get to the Drees Note here, which comes up afterwards. So I'll try and make it as interesting and as fun as I can. I don't have any wonky Zoom backgrounds to do for this so that you're stuck with the plain wall behind me, but we'll see what we can do. This is building secure and compliant hosting. So if that's the session you were hoping to attend, you're in the right spot. If that was not the session you were hoping to attend, that's okay, you're in for, but we'll hopefully be a good time anyway. I'll try and make it as exciting as I can. Thank you all for making it out bright and early, 8.30 a.m. I think this is the earliest a Drupalcon has started with sessions in years past, at least for all of the years that I've been going over the past 10 years or so if we take out the time zone difference from the virtual Drupalcons. So you're all here, you're all awake. I am awake, I have plenty of water and stuff like that, so let's get rolling. By way of introduction, my name is Brian Thompson. That's a picture of me if you couldn't see my face. I am system administrator in cybersecurity, turned Drupal developer because that's what you do when you host sites that on servers that run Drupal and somebody says, do you know what the Drupal is? And now I run a 70 plus person engineering team based throughout the United States at a company called Mind Grub. I am AWS solution architect professional, so I have paid to prove that I know what I'm talking about. I past life included building computer networks from the ground up and sort of protecting them from people from various government agencies in the DC area or surrounding companies. So that was fun. In the less serious sense, I'm a big theme park nerd, so my Zoom backgrounds have been theme parks for the past two and a half years and you're always on those client calls and they do the introductions of, tell us a little bit about yourself and I thought telling you that I'm the AVP of engineering just doesn't have the same ring of it. So I normally tell people that it has a plug or a battery or if it looks like it might have a plug or a battery or it smells like it might have a plug or a battery, it's probably something either I've dealt with or my team is responsible for and so you're in the right spot. So today's agenda we've already done number one which was the introductions, there's only one of me. I wanted to make sure we cover what this talk is and what it is not so that we kind of lay that baseline. We'll do an overview of the different compliance frameworks that you see frequently mentioned on various companies security pages or websites that they try and tout for what it is they're good. We'll talk about how to determine what compliance frameworks apply to you and then if you are sort of rolling your own hosting, you're working on a cloud provider, you're working with a client who wants to host in-house on their own servers, yeah. We'll talk about what to do there to sort of get that configuration right to ensure some compliance and then we'll do Q and A at the end. So that's the plan, everybody good? Awesome, I'll take silence as acceptance. So what this talk is and what it isn't. This talk is designed to be about an overview of security and compliance frameworks. There are a lot of them and they are all very similar and they're all very different in their own unique way and so we're not gonna dive too deep into any of them in particular but we'll talk about what they mean, what they are focused on as part of my regular day job. I deal with these on a daily basis. They're super exciting and fun and I love talking to auditors who like to try and understand what it is that we're doing and how that applies. And we'll talk about how to improve the security of your own hosting if you choose not to use a managed Drupal hosting provider, what you can do to help. But more specifically what this talk is not is the one and only way to make sure that your hosting environment is secure. There are lots of different ways to go about doing that. This is my take on things, this is what I've used that works with my auditors and the risk profile for my clients and what they're looking to do but everybody's situation is different in the way a lot of these frameworks are written is very abstract so as to give you a little bit of latitude in how you go about doing things. So this is not the one and only way it is a way that works for me and hopefully I think it will work for you. The other thing and I wanna try and be very careful about this like I am not here to pitch you on any one hosting provider or tell you one is better than the other. There are a lot of great hosting providers in the exhibit hall, go talk to them. They'll all be happy to talk to you about security. There are a lot of great hosting providers on mine who aren't here who have their own security programs. I'm gonna try and keep this as hosting provider agnostic as I can so that it applies to everybody across the board. There's one slide in here where I mentioned a hosting provider specifically and it was by happenstance because I needed a website as an example and so take that for what it's worth. Of course I certainly have my opinions one that I'm happy to talk afterwards if you're interested in more specifics but it's not meant to be a sales pitch for any one particular hosting provider. So let's get into an overview of compliance frameworks. If you pull up, I said we're not gonna talk about hosting providers and of course two slides later I have a screenshot of some of the biggest cloud providers in their compliance pages. You can see that there's a lot of compliance frameworks and it's a little intimidating and even the one in the middle which has the biggest icons and seems to have the most digestible thing. What you can't see is that at the bottom of the image there they've actually got six pages of them. I just didn't screenshot each of the six pages so left and right put them all on one page and these super little itty bitty tiny lists the one in the middle likes to paginate them the one on the left goes on and on and that can be really intimidating because most of us don't know what these compliance frameworks mean in the first place or what they're trying to achieve and all we see is that there's a lot and so you have to figure out what applies where and how things are important to you. And so here are some of the six biggest ones listed in my opinion in order of importance or at least in the order of that I work through them. The first one is SOC or as I like to call it SOC. You will see this most commonly across all of them. For me, SOC means System One Chip. That's my techy nerdy background and so I call it SOC. My auditors remind me every time that it's SOC but there's a variety of different types there and we'll dive into them in a little bit. Then there is FedRAMP. Many of you are probably familiar with if you work with a variety of federal or state governments or local they like to pull the FedRAMP card on you. Not necessarily new but overview of CSA, the Cloud Security Alliance. There's a large number of industry specific compliance frameworks depending on what industry you're working in you're probably very familiar with PCI compliance. If you've talked to any of the vendors out in the exhibit hall who do e-commerce transactions or payment processing but then there's also FINRA and HIPAA and FERPA and those are just the ones that I listed on the slide here. There's the ISO which is one of my favorite sets and also one of the older ones in there in the 27xx category and then maybe the most fun one for those of us who are in the compliance world is CMMC because it's new and nobody knows exactly what it means yet but we'll give a brief overview of that. So starting off with SOC there are three to four different variations depending on how you look into it. The first one that you'll see primarily mentioned on company webpages is SOC-1 which sounds very exciting until you realize that everything about SOC-1 is financial based. So these are auditors going through looking at the company's sort of financial background making sure they're financially stable. Certainly a good idea it's good to make sure that they are doing things from that perspective from those of us from the technology side of things. I tend not to be very interested in the financial side of the vendors that I use. All I care about is that they exist and they have enough money and I'm paying them as reasonably as possible so I tend not to look at that one. Then you get into SOC-2. This is the big boy of all of the different compliance frameworks and the one that you hear mentioned most often that companies work with. SOC-2 comes in two types. Ironically called SOC-2 type one and SOC-2 type two. SOC-2 type one is telling you what it is that you're going to do. And so a company that's trying to achieve an SOC compliance starts with a type one audit where an auditor goes through and looks to make sure that their controls match the set of requirements that are laid out. And all they do is they issue a report that says yes, this company has controls that we believe meet the requirements. There's no evaluation of whether they meet, actually you're doing that or not. It's just whether they have those controls in place. Once they have those in place, then companies get into the SOC-2 type two. And that's where the auditors actually come in and make sure you're doing what you said you were going to do. And so if you have a policy that you have access removed for employees who leave within a certain period of time, they will go through and check to make sure all of their access was revoked. The SOC type two type two report is very widely accepted. A number of different companies out there will use it in place of other compliance frameworks that we're going to talk about here. And it is really common. Because it is so detailed, excuse me, the SOC-2 type two normally requires an NDA. If you're trying to download it from any of the major cloud providers or software as a service providers, there is a 99.99% chance that they're gonna have you sign some sort of non-disclosure agreement because it details in normally a couple hundred pages exactly how their systems work and how they get out into how they procure hardware, how they implement things, the underlying services they use. And so they like to have a non-disclosure agreement in place for that. Because auditors realize that not everybody wants to sign an NDA to get things in place, they created what is called the SOC-3, which is a redacted version of the SOC-2 type two that you normally don't need to sign an NDA for. So our company, my company will send you a SOC-3 report if you want. It's practically on our website if you have the right link to download it. But the SOC-2 type two report, we do require an NDA for and that's pretty common across all of the different vendors that we use. The other thing with the SOC-2 is the scope of it. It's based on five principles, security, availability, processing integrity, confidentiality, and privacy. In order to get a SOC-2 type two report issued for our company though, you only need to do one of those. So there is no requirement that you actually meet all five principles. Companies generally start with one or two based on what their business is and then expand as they need to do more year over year. The larger the company, the higher the likelihood that they probably have all five if you go with one of the larger cloud hosting providers but it varies based on the service they provide. Something like a authentication provider is gonna be much more focused around security and confidentiality to start with versus a hosting provider who's focused around availability. So if you are reading through SOC-2 reports or you're talking to your vendors about if they are SOC-2 certified, make sure you understand what of the five principles they are actually certified for and it'll be listed within the first couple pages of the report. All right, next up is FedRAMP. Everybody's favorite if they work in the government space. It has been around for ages and stands for the Federal Risk and Authorization Management Program. It was originally derived from NIST, the National Institute of Standards and Technology. Their official document 800-53. And it, like SOC, has two different levels to it. And so the basic level is issued at the agency level. That would be a specific government organization that has evaluated a particular service provider. And then there's also a level that's issued more globally, which they call the P-ATO, which is for everybody. Why does this matter? Because different government agencies have different levels of risk profiles that they're willing to tolerate. Some people have more important information than others or more classified information than others. And so because FedRAMP is purely a set of standards there's no definition on how to implement them. It's up to each provider to determine how to do that and assign a risk rating to that. You might have one particular agency that decides that it is perfectly acceptable for them to use. And another agency who says based on those security controls it's not acceptable for us. So if you see somebody who has a P-ATO or authority to operate, that's what the ATO stands for, then that means they have achieved the highest level possible because they were evaluated by the federal government as a whole to make sure it works for all of their different agencies. If it's just at the agency level then it might not be applicable for another agency you're working with. But the nice thing about FedRAMP, unlike SOC, is that there's a centralized place where you can look up all of the different companies that have FedRAMP sort of authorizations. That's at the marketplace.fedramp.gov there. It's got an actually decent search. You can also do it alphabetically. So if you know the name of the company it's easy to kind of find and jump through. And you can see all of the different agencies that have approved it. All right, getting into the next one, the CSA. Not to be confused with the government agencies we were just talking about. The CSA is a nonprofit. They were originally formed back in the early 2000s. The Cloud Security Alliance designed to provide a sort of standardized framework. And they have what they call the STAR framework which is for security, trust, assurance, and risk. While it has been around for a while I have not seen it very often come up from clients but I'm starting to see it more and more. higher ed in particular is starting to use it and asking for people to dig into it and have that particular level of compliance or certification for their vendors that they're using for higher ed hosting. Again, these are all interchangeable so a lot of companies are getting by by saying we have SOC or we have this or we have that but if you're working in the higher ed space that is really the one that I've seen come up most in questionnaires. The other nice thing about CSA is that they have two levels and the first level is a self attestation. So even you as a Drupal service provider if you provide a particular service can actually just go add yourself to the STAR registry online and complete the questionnaire and say what you're doing and not doing and that can be enough to get you on level one which normally will get you past the requirements of the particular customer that you're working with. As part of that self attestation you say what you're doing, what you're not doing and then any remediation plans to correct things that you're not compliant with and put a timeline to them. So that can be an easy way to get going there. All right, moving down to line two trying to get through this and get to the exciting DIY hosting parts but these are the industry specific options. By a show of hands, how many people have heard of PCI? That's pretty much everybody, that's great. So PCI around the payment transactions make sure that you keep in mind that PCI technically says that you can't even have the data passed through your network without being, otherwise you have to be fully compliant and so I know there have been some customers I've worked with in the past who haven't necessarily liked the payment provider widget that Stripe or any of the other payment providers use they wanna do their own thing to get it to fit in their flow and then have it, Drupal make the curl request in the background out to the payment provider. Even that even though you're not storing payment information does mean that you need to be PCI compliance at the highest level which means going through a very rigorous audit. So keep in mind that if anything even comes close to what you're hosting then you're on the hook for that. You get into ones like FINRA in the financial industry very heavily regulated. HIPAA in the health space which we'll talk about more in a moment here and then FERPA we could go on and on and on about all of these practically every industry at this point has their own particular framework and not all of them are necessarily willing to accept others and so like I mentioned where the cloud security alliance you can normally get by if you have SOC or go back and forth these tend to be very specific and HIPAA in particular is unrelenting. If you do work in the medical space where you're required to be sort of HIPAA compliant keep in mind that chain of custody matters what does that mean? That means that you should execute what they call a business associate agreement or a BAA with all of your vendors and your clients will or should execute one with you. What this does is it passes risk and responsibilities one to each party on its way down. You don't wanna be the one who's stuck holding the bag if you didn't execute a business associate agreement with your hosting provider because the HIPAA fines are not great. Just a few years ago the fine was something like 2.5 million for a small company that managed to lose a couple hundred thousand records. I don't wanna lose 2.5 million any day of the week let alone because of a security breach by one of my vendors and so business associate agreements are how you get past that. A lot of different cloud providers out there have pre-written ones available where you just have to check the box and say and digitally assign to execute it with them smaller companies you might need to go back and forth with their particular security teams or with their legal teams. In this case there's a lot of risk there's a lot of money on the line I would certainly recommend talking to legal counsel about what goes in your business associate agreements but they are pretty templatized you can find someone lying that normally gets you most of the way there. All right the ISO, the international organization for standardization always trips me up why the letters are backwards from what they stand for in the word but I did double check my sources again for this to make sure I had it right. They have a whole series of different documents all around cloud security it's the 27,000 series in particular the one that you want to pay attention to is the ISO 27,001 that outlines the requirements for cloud security in particular. 27,000 even I believe is definitions and terms and there's a lot you can spend a whole month of evening reading putting yourself to sleep trying to go through them but 27,001 is kind of the meat of things. Similar to the cloud security alliance they have a couple different stages where stage one is just a sort of informal review self attestation that you're meeting all of the requirements. Stage two is when you start to get auditors involved and then I put it particularly here for these but it applies to all of them that even once you have one of these things you do get audited annually if not more frequently and so any of your customers who are sorry any of your vendors who have these are going through this one at least an annual basis if not more frequently. All right the last one on the compliance framework side of things here the CMMC or the cyber security maturity model certification. How many people have heard of CMMC? A couple, one or two. CMMC is really quite new. It is in some ways the successor to FedRAMP in other ways it's kind of floundering and they're not really sure what to do with it. It was originally designed to be the successor to FedRAMP to kind of bring FedRAMP which was done in the late 90s I believe into the modern day for how cloud truly works but thanks to a lot of debate over the different policies it's still not fully rolled out. It applies specifically to the defense space in the United States and there have been a number of different movements to require all of the vendors to the Department of Defense to be compliant with this framework even though the framework isn't actually defined and so that leads to a lot of confusion between procurement departments and vendors and everybody else where they're including line items in their RFPs or what they're looking for their vendors to do to be compliant with this and vendors are going we don't really know how to go about doing that because you don't have a firm list of requirements. On top of that the auditors for CMMC are also new. Last time I looked there was one company that could audit and that was it. So normally once you have a conversation with the right folks and you can point towards SOC or other sort of compliance options everybody's been getting by so far for the most part this is something that over the next probably two to three years will start to become very popular in the defense industry and the defense space. All right, well that was all very exciting and hopefully it looks like I still have everybody awake this early in the morning after going through such exciting topics. So what of this applies to you? Which with all of these different frameworks in place what should you care about? I kind of alluded to this but the key thing is looking at who is your client? Who is it that you are working with? SOC, CSA, ISO are the most general and of those three pretty much SOC is the primary one there. FedRAMP, Vindore, CMMC are pretty much near-definites for government projects and that includes state and local level. They like to jump and piggyback on the FedRAMP side of things. If you're doing anything industry specific even if it wasn't one of the ones listed there I would definitely do a quick Google search around that industry and how they apply. We could spend hours and hours talking through industry specific ones but PCI, FINRA, HIPAA, big ones there we've talked about. Now keep in mind that as part of this oftentimes your vendors are using other vendors to fulfill what it is that they are doing which means I talked about that chain of custody for the HIPAA and the business associate agreement that applies to all of the different compliance frameworks. Every vendor is part of their or every company is part of their compliance is required to certify the companies that they use. And so what that means is that because my company is SOC certified that means we've gone through all of the vendors that we use and made sure that they have valid inappropriate SOC certifications as well. And they have gone through all of the vendors that they use and it kind of trickles down. So you don't have to go down that rabbit hole you only have to go the first level but do keep in mind like as you're looking through these that they should have gone through them and if they don't call that out in their report or they call out that they're using somebody but they didn't review them or you just haven't heard of them it can sometimes be worth a cursory Google search just to see what's going on or what the company is. I know I've read a couple of reports where I'm like huh that's an interesting name like I haven't heard of that company that provides blank like what do they do? And then I pull them up and look through their security page and see all of their details. And the other piece is all of these different frameworks have what they call complimentary user entity controls. Or because we're in technology and that's way too much to say we call them Kuix, CUECs. What those are are things that you have to do to actually make the compliance valid. And so this is actually an example from my SOC report where I state that user organizations are responsible for managing their password change frequency and ensuring password changes occur. In order for us to be compliant our customers have to take that on themselves. Some companies have very, very long lists of things that you need to do. Other companies have very short lists of things that you need to do. It really varies company by company but this is why you should go beyond just the sort of security page that says they have a particular compliance certification and actually talk to them, get the report, read through. It's always in the table of contents where this is. It's normally about two thirds of the way through. And they put it in table form you can see here like this is just a screenshot of part of the table of controls in place. To make sure that you know what you're on the hook for as well. All right, that's enough about compliance frameworks. Let's get into sort of hosting security for the DIYers. This could be anybody who is doing it self hosting. This could be using a cloud provider who has given you some sort of virtual private server or physical server of the sort really kind of varies. So first recommendation I have that comes from a lot of these different compliance frameworks is making sure you know your traffic and leveraging firewall rules to only allow the services that you need. There are a lot of servers out there on the internet that have SSH open on port 22. And I don't know how many people are aware or can use it but there is this website out there called shodan.io. I recommend it. It actually scans the internet and all of the IP address space to find what services are running on every IP address. And you can then search about that for free. And so this URL here is a search for how many servers out there have SSH open on the web. You can see that as of a few days ago there were 21 and a half million. So that's just a few open SSH ports on there. The other thing I know it's a little blurry in the screenshot I didn't wanna make it super readable but you can certainly go find this yourself is that a lot of times they include the version of SSH that's running. Now we all follow the Drupal security releases and every Wednesday we're patching our sites but how often have you gone in and patched all of the other packages on your server? Open SSH, the most popular SSH server client has had its fair share of vulnerabilities over the years and people tend to forget to patch things. And so with this I can even drill in on the left hand side through the filters here into specific versions. And so I could find all of the old versions of open SSH running on the web if I were somebody who was trying to do something less than ideal. And then on top of that if you really wanna take things to the next level this is not necessarily required by the compliance frameworks but I like to use it to add increased security to my environments is restricting your outbound firewall rules. Everybody focuses on what traffic their server is bringing in but you have to work under the assumption that at some point there is going to be a risk to your system where your site might be compromised or your server might be compromised. One of the first things that attackers like to do once they get into one of their systems is put something in place so that it can phone home back to the mothership if you will or sort of the control center to receive commands and report in that it exists. If you block all of your outbound traffic besides ports 50,000 plus that are going to your particular load balancer to wherever your outbound traffic should be going even if they can get in then they can't get back out to tell them that things are going on and that can buy you extra time. It is a bit of a hassle to set up these outbound security rules. You need to definitely make sure that you understand what your traffic profile looks like because inbound ports are not the same as outbound ports. If I SSH into a server even though I'm connecting on port 22 when they inbound the outbound traffic is not going over port 22 so do be careful but something that can really improve your security posture and help you through different scenarios and lock your systems down. On that same note, the next sort of piece is protecting your origin. It's very easy to look up what the IP address of a particular site is and figure out where that is hosted and then throw that into Shodan. I showed the URL there for searching by service but I can also search by IP address and so if I know that this particular site that I'm trying to target is hosted on this IP address then I can start scanning that and you can see it really is quite simple to do. Now I'm not encouraging you to do this. You'll note that there is a I am authorized checkbox here but looking for an example website I just took the Oregon Convention Center website because that's where we are. Did an NS look up for it on my command line to get an IP address. I can tell you just by looking at it because it starts with five two that's an Amazon IP address. I know their address space very well and this is just a quick Google search the first result for network scanning tool was this pentesttools.com. Now it's based on an open source tool called Nmap that I could have downloaded and run on my computer but that's nowhere near as fancy and graphical to put in a presentation like this and so you can just take that IP address and put it in the free service here and it will immediately tell you which ports are open on that particular server and so if I was somebody who was attacking the Oregon Convention Center and trying to take over their website now I know here is the particular Amazon server that they're using with the IP address and not only can I connect to it over port 80 and port 443 but there's SSH running open SSH 7.2 patch level two I think the current patch level is 16 for 7.2 so just kind of reinforces that point there's no reason for SSH to be open to everybody in the world it makes it much easier and if you ever read through your security logs you'll see that port 22 is frequently and commonly hit by attackers. All right next up read only file systems if you came to the Drupal security talk on Monday by the security team they talked about this a little bit but all of the different compliance frameworks require that you know what code is running in production and you have to verify that any change is tracked. Now we might think that that's pretty easy we have version control and so I always store my code in version control and then deploy from there but if your code is writable on the particular web server then that requires you to manually go in and periodically audit and do a get diff or get status to see what those changes are that have been made to the production website. On top of that I know there's this very large urge to set file permissions when things aren't working and I'm just as guilty of it as others where I don't understand why the web server can't read the file that I need so let me just make the permissions very broad or even I have the sites default files directory where I want users to be able to upload files to and I need that to be writable so I change it to 777. Keep in mind that one of those digits is for being able to execute files. There's really no reason somebody needs to execute an uploaded file to your Drupal website. Maybe they need to write it, maybe they need to read it, read it but making sure that your code is running in production in an immutable state, not changeable increases the security of your site and also helps you with the compliance side of things. There are a couple of great Drupal modules out there from the Drupal 6, Drupal 7 days. How many people remember the PHP module? That was fun, right? Good show of hands there. There's the views raw SQL module which allows you to inject raw SQL into your views queries rather than try and point and click through the interface and then there's the views custom conditions module which is very, very similar. Luckily, number two and three don't have Drupal 8 or Drupal 9 versions when I looked so we're getting better but the PHP module still exists for those. Besides just being a general bad idea and bad for performance, they're also really bad for security so let's not use those anymore. Make sure if those are on your site you take them out of there leverage all of the great security innovations through Twig and everything else. All right, backups. How many people take backups of their website? Hopefully everybody raises their hand, excellent. How many people test their backups to make sure that they work? That's good, that's about 60, 70% of you. You never wanna be in a situation where you have to use your backups and you find that they're not working for you so depending on your level of risk, think about where are your backups stored? A lot of compliance frameworks wanna make sure you have redundancy to handle geographic failure and so if the East Coast of the United States where your data center is goes offline and your backups are stored on the East Coast then what good are your backups? Make sure they're kind of split up. Then on top of that can they be changed once they are created? So if you remember the, what was that, the 2014 SA005, the Big MySQL vulnerability in Drupal back in the day or SQL injection vulnerability, a lot of attackers were patching websites so that once they had broken in and compromised them that nobody else could break in and take over the website from the attacker who had taken it over. I see the same thing a lot with backups where people who are really interested in attacking your systems will go through and also update all of your backups to have their compromised files in it so that even when you restore from backup you haven't really fixed the problem. So make sure your backups are immutable or you have a version that once they've been created they can't be rewritten or overwritten. Make sure you're retaining them for an adequate period of time. You know a lot of organizations follow something along the lines of daily backups stored for a week, weekly backups for a month, monthly backups for a year but make sure you talk to your customers and understand what it is that they are looking to do and what they are looking to achieve. The likelihood that you're gonna use a backup from three months ago, probably pretty slim. You know it's a good idea to keep backups around just in case of disaster but truth be told if there was some sort of issue you're probably only going back a few days at most. So a lot of this is comfort for a true disaster. And then we talked about testing them. A lot of you do test them so that is great. We'll skip the part where we do the test your backup pledge when you get home. For those watching the recording, if you haven't tested your backup go ahead and pause the recording now, give it a test and then continue. You'll thank us later. And then finally I mentioned access earlier and sort of knowing who has access to your system but we use SSH keys a lot. And I know especially in the agency world it's easy as you get new developers or you're bringing contractors on to take their SSH key and add it to a particular server so that they have access even if it's a dev system or something that's not in production. Here's just one of my servers. I went through for this talk where I pulled the list of SSH keys on it and there's close to a dozen. And that was a reminder that there are people who no longer work for me who are on this list. SSH key management can be a big deal and a big component and just because it's not a production system doesn't mean that it is immune from things. I've seen a number of attackers who try and break into development systems because the security is weaker and do use that to understand how the application is working and then craft their attacks against a production system in a more strategic way. So definitely make sure that you sort of look through your SSH key, set a calendar reminder every couple weeks, every month or two, maybe as you're testing your backups go through and make sure that your SSH keys are set. Also make sure that if you're taking backups and they have sensitive information in such as this that they are still appropriate. I've seen a number of organizations who have restored from server image backups and inadvertently given people access again because the backups had SSH keys of past users in them. So fun times there. All right, with that, we've got about nine minutes left I think. For questions, if you missed my introduction, I'm Brian Thompson, I'm on Twitter. If you have questions, I'll also be around for the rest of the conference. Please stop me, chat with me, I'll take questions here, but always happy to talk security and compliance. Thank you so much. Unlike past years, there is no audience, Mike, so if you have questions, feel free to just raise your hand, shout it out and I'll repeat it back for everybody. Yes. Yeah, most certainly. The question was how do we help combat people who think just because they're hosting on a specific hosting provider like Amazon and Amazon is compliant that they inherit that compliance along the way. It is a big problem, I see it a lot. A number of customers believe just because they're using one of the big three cloud providers that they are then good to go or safe. It's tough to convince people of that. I've always tried to have security teams actually read through the documentation. Amazon and Google and Microsoft are all pretty good about being clear. Here's what is in scope for our compliance and here's what is out of scope. They call it the shared responsibility model of what they take ownership of and what you have to take ownership of and that ends at the infrastructure they provide and so somebody who provides a virtual server has no level of compliance over the software you run on it be it Drupal, Apache or anything else or how you configure it. And pointing out the complimentary user entity controls that they list which spells that out pretty clearly or pointing them towards sort of the shared responsibility model. Even if it's not for the hosting provider that they use, I tend to use a lot of Amazon documentation regardless of hosting provider my clients are hosting with because it is pretty thorough on the security side of things and it applies across the board. All right, if there are no other questions then I'll see everybody at the address note.