 Alright, can everyone hear us? I'm not used to, okay, good. I'm not, I'm not good with mics, so my voice just will naturally project some. So, uh, hopefully you guys are here for Death Star Security, if not, and you just want to see a bunch of Star Wars gifts and stuff, uh, stick around, otherwise, um, there's a lot of, uh, other great sessions going on, so, but hopefully you're here to learn more about, uh, security, and, uh, and so we are going to go on a journey together, um, through, um, some very, uh, some of them will be basic concepts for you, and some of them are new concepts that we're proposing to the community. Um, but first off, we want to introduce you, uh, ourselves. My name's Chris Teitzel. I'm the, uh, founder and, uh, CEO of Cellar Door Media and Locker. Um, Cellar Door on, on D.O.T.O. and Techner Teitzel on Twitter, so if you want to heckle me on Twitter, go ahead for it. Um, I do a bunch of Drupal Development, uh, involved in a lot of the encryption, um, and have experience all up and down the stack, um, seven plus years in D.O.T.O., originally starting a lot of, uh, Omega in front end, and then transitioning into a lot of the encryption and security. Uh, and I'm, uh, David Strauss. Um, I'm a co-founder and CTO at Pantheon, and I've been part of the, I think like Drupal lower accounts from like 2006. Uh, so we've been, we've seen the rounds, um, and, um, I've done a lot of work with security across the spectrum, not just in Drupal, uh, for everything from, uh, process management compartmentalization, uh, and a lot of the security architecture that we have at Pantheon for the, uh, the platform itself. So, um, in this case, uh, we, we have to transform the Star Wars narrative a little bit to fit our use case because, uh, we're not the rebels here. Um, uh, we're the empire, and, um, uh, it's actually the rebel scum that is trying to take down your site. Um, unfortunately we have to be kind of the, uh, um, the, uh, hegemonic force here because, uh, um, we are the ones that have, uh, something to protect on the web. Uh, we are the ones that are facing, um, different attacks from different, uh, sources, and really it doesn't matter that it's kind of rebel versus empire so much as the fact that we are the empire and there are a whole bunch of different forces, uh, that are trying to, uh, take down our infrastructure. Um, yes. Um, so, so the idea of Death Star security is reinforcing the edge and trying to build as big of, uh, security around the edge as you can while leaving a, uh, single point of vulnerability that will explode the entire infrastructure. Um, and so as you can see here this, uh, the plans to the Death Star, very intricate, very ornate. Um, okay, real quick, who has not seen Rogue One? Okay. Um, I will, I will try not to do too many spoilers here. Um, but you can see that there is a massive vulnerability and it's just a small thermal exhaust port right below the main port and the shaft leads directly into the reactor system, a precise hit. We'll start a chain reaction that should destroy the entire station. And so, um, don't build this into your systems. As much as you want to have, uh, a strong wall, we have to assume that that strong wall isn't going to hold up. So, uh, when it comes to, um, your systems, um, every one of our systems is, uh, has the kind of edge of the Death Star that we all have these vulnerabilities, um, the, um, but it, what it means is we can't overly focus on that edge. Um, in the case of the Death Star, they were so focused on building this kind of, um, galactic class weapon that could destroy planets, um, and taking this very, um, uh, brute force kind of approach to maintaining the security of the station, um, that they sort of, um, lost track of the fact of like the actual, um, stories around, um, how the system could get compromised. And of course, if everything gets compromised and everything gets torn apart, you're not really accomplishing your original goals. And so, uh, we should never lose sight of the fact that the business value, um, uh, whether it's destroying a planet or like delivering to an e-commerce website, um, is important to maintain and, uh, security has to be part of delivering the business value because, uh, losing the security of our projects just, just kills that off. And, um, we should also not try and just design through convenience, uh, where basically, uh, we, um, uh, we take shortcuts, um, and skip, um, things that we know are problems. Like if you've seen these conversations they've had actually even in Star Wars, they were aware of this vulnerability in their system. Um, they even brought it up that it was possible to exploit through a particular series of actions. Um, and, uh, that's, that's even worse. Like we all have vulnerabilities in our systems, but, um, we should never assume that just a known, a vulnerability is obscure enough, um, or hard to figure out enough that, um, it will not be exploited by, um, public forces. The other thing we want to avoid is, uh, what we call subcurity, security through obscurity. Um, and so, uh, here we have a nice little quote that says, uh, an analysis of the plans found in their insecure github repositories demonstrating the weakness in the battle station. Um, a lot of the times I, I see as I'm auditing modules and looking at various implementations, uh, someone will implement encryption as they call it or, or, um, hashing and they think that that somehow will just magically make the, the value, um, not seen to anyone. Except for they'll take the key to the encryption and set it in a variable right next to where they're doing the encryption, which defeats the entire purpose of it. Um, and I see this all the time. And so one of the things we need to, to look at is, is not just, um, are we doing security, but are we doing it through obscurity and, and are we really taking the steps to mask what we're, what we're wanting to keep secret and do it properly? There really is no right way over time to accomplish security through obscurity. Even if you're perfect in keeping your code base locked down against public access, uh, people will join your team. People will leave your team. Uh, you can't rely on, um, even perfect security for your current team, uh, accomplishing the goal of not having people know about the designs and kind of constants you're putting into your system. So for the sake of the rest of the talk, we have to assume that somebody has just shot some phaser or, uh, lasers through the, uh, exhaust port and your entire system is about to blow up, but we can avoid it, uh, by putting in place enough protections and enough, um, um, isolation in, in the, uh, in the system. So we're hoping to avoid this, but for the sake of this argument, you've already been compromised. And, and one of our favorite quotes, um, from a former director of the FBI, Robert Mueller, is that there's two types of companies, those that know they've been hacked and those that don't know they've been hacked. Um, and it's slowly, uh, merging into those that know they've been hacked and those that know they've been hacked again. Um, so you have to assume that somebody is going to breach your outer walls, somebody will get through into your systems and how do you limit the damage and the capabilities that they have once they're in? So, uh, compromising the edge of the system is rarely the actual goal of an attacker. Uh, mostly they compromise the edge of a system in order to accomplish other things. Um, if you look at, so, the whole history of, say, Drupal vulnerabilities, it's rarely the direct vulnerability, um, that is going to allow someone to accomplish exactly what they want. Instead, usually the vulnerability is something like arbitrary SQL, uh, injection, arbitrary code execution, something like that where the vulnerability itself is just a foot in the door to be able to do other things they want to do. And if you look at all of the things that have happened on, say, um, released over the last decade on the internet, uh, whether it's like WikiLeaks or some other site, almost all of the information was not obtained through a direct attack on the system that contained the information. It was obtained through a, a graduated series of steps that, uh, entered the front door and then it was in the living room and then it made its way to the kitchen and then it made its way to the bedroom of like the systems. Like they didn't just break into the system they wanted to compromise directly. And that's why you see things like a website getting compromised and then the emails being leaked. Um, or a website being compromised and all of the personal information being stolen of the users. Um, it's just not their end goal to, uh, to actually just break in the front door. A thief doesn't break your window to break your window. Um, so keeping this in mind, we need to put ourselves in the shoes of an attacker to think about what are their next goals if they compromise your system. So, OWASP, uh, publishes a top ten and this is the most recent one from, uh, you can go to the GitHub link down here at the bottom. They just released their 2017, um, these are the top ten vulnerabilities of all, um, website applications. Uh, injection, broken authentication, cross site scripting, broken access control, security misconfiguration, sensitive data exposure, insufficient attack protection, cross site request forgeries, uh, using components with known vulnerabilities, unprotected APIs. These are all very, uh, they're the top ten but they're also very basic to protect against. Um, and so we have to look at these as you should be checking these boxes and going through these processes every day as you're launching or developing your code. Um, what we're gonna talk about is a bit deeper into the system and more how do we structure, uh, the site and the, um, in the server configuration so that this doesn't even have a chance to occur. Uh, but, but take a look at the top ten, um, but use this as just a baseline. Uh, don't use it as your end goal. Uh, we should be, we should be striving to get, uh, farther than just these top ten, ten items. So, first thing we're gonna talk about is, uh, authentication security. Um, this is the, the, the big breach, um, or breach point that everyone, uh, attacks first, right? They always try to hack the passwords. Yep. Um, and Drupal's taken some major strides on this, um, especially with, uh, Drupal 7 and 8 in terms of how we handle passwords. I'll talk about the details in a moment. But, um, the, um, uh, some users, uh, a lot of users in most of your sites, especially if you deploy Drupal out of the box, users are going to be authenticated with the user name and password. Um, the, um, out of the box, modern Drupal releases are not gonna have, um, the vulnerabilities of the bad hashes, but if you still have some Drupal 6 sites around, they are using MD5 unsalted hashes for those passwords unless you've done something about it. That means someone can go on there, find any user account, take that hash, they can literally put it into Google and figure out what the password is of that user. Um, it provides basically no security above, uh, plain text storage of the passwords at this point. Um, SHA-1 is, uh, is getting a lot weaker, um, especially if you don't, uh, follow any of this further advice. Um, uh, Drupal itself is using, um, a salt for the passwords. A salt is, uh, in Drupal 7 and 8, a salt is the idea of coming up with a random number that you store with the password in clear text, but it is causing randomization to happen for the hash of the password. And what that means is that, um, uh, the reverse of a hash is called a rainbow table where you can basically take the hash and look up what could create that hash. Uh, and by using salt, you can actually blow up this space of, of rainbow tables, uh, for doing this sort of lookup. And, um, they would have to create a reverse lookup for every single, um, salt that you, that you could potentially have for the password. Because every single one results in a completely random, uh, effect on the hash. Um, uh, Drupal does not use a pepper, but if you're building your own applications, this can be a neat thing to use. Um, a pepper is the idea of, uh, something stored separate from the password that is also used, um, similarly to a salt. And so the idea here is that, um, you have, uh, a password. It's getting doubly kind of, um, randomized before the hash with the salt and the pepper. And then the salt is stored with the password. So someone who downloads your password list would have that. But if they don't also download the pepper, uh, they wouldn't be able to, um, to even start, um, reversing the hashes of the passwords for the site unless they obtain that too. Now, um, that would, you would have to store that somewhere separate from the passwords for that to be useful. Um, now Drupal 7 and later also do password stretching. That's the idea of running the hash sequence many, many times on the password in order to, uh, increase the amount of computation power it takes to do a reversal because it's no big deal for a user to spend 300 milliseconds, uh, computing the hash to their password. But if someone wants to run a dictionary attack and try every word in the dictionary and try to compute, um, whether a password is a match, um, a 300 millisecond hash is going to be much, much harder for them to get through that list with, especially if they have to do it for every individual password because they're salted. The idea behind hashing in, in, um, stronger encryption methods is that what you're basically doing is stretching the amount of computation time that is necessary in order to break, um, the algorithm to near infinity. Um, and the closer and the farther you can get down, uh, that, that pathway, the stronger that hash is. And that's why MD5 is, is no longer, uh, advised and Shaw 1 has technically been broken and is, is starting, um, to show its weaknesses as well and is no longer recommended. It's because, uh, there are ways to shorten that timeline to have a hack happen in real time. Now encryption and, uh, password stretching and all that, we're talking about millennia in terms of computing time that are necessary to, um, brute force it. And, um, this comes down to like, just to kind of show how this all works. Um, basically if you, uh, have a super weak password, um, uh, uh, storage, like just unsalted MD5 like this, you could plug it in a search engine and you basically can just get the password out of it. Um, that means if someone's able to download a copy of your database from where you're storing your backups, uh, maybe one of your developer laptops, uh, it's as good as leaking all the passwords for all of your users. And, uh, it's also important to realize from a human perspective that your users are not just using their pa, uh, unique password on your site. Most users are using the same password on multiple sites. So if they compromise your site, even if you don't have any special information, you may be contributing to compromise of their account elsewhere on the web. Um, so we avoid that. Um, and better password hashing comes down to this, uh, structure here, uh, where what we do is we take the password, we take the salt, we take the pepper, uh, we end, we take a strong, um, hash on it, and we end up with something that's just not gonna be reversible. Um, Drupal does most of this on its own already, but if you're building other systems or integrating with other systems, these are important things to keep in mind. Um, the, uh, uh, Drupal also does, um, password stretching, um, and this is where it does, uh, you'll notice in that little arrow area that it says 100,000 rounds. Um, it literally spends over 100,000 times as much time, um, to come up with the hash, uh, as it would when, um, uh, if you use just a basic high-performance hash for the password. That means a dictionary attack takes 100,000 times as long to do on a single password. And, um, also if you're using passwords, uh, because most users don't really pick good passwords or they reuse passwords extensively, uh, two-factor authentication can be very helpful. Uh, uh, the, um, the password is sort of the something you know, um, and, uh, you can do very good, uh, complexity requirements. Do we still have that slide in here? With the complexity requirements? Okay. Um, so I'll go over some good, uh, some, how to make intelligent complexity requirements for passwords, uh, in a moment. Um, but basically the second factor of two-factor authentication is something that the user doesn't just get to come up with themselves or just something they know. This is not something like security questions that, uh, some, some of the old, like, banking sites would ask. That does not help with, uh, protecting account security. Um, and in fact, uh, if you keep answers to sensitive data security questions for your users, you may be even helping, um, an attacker, uh, compromise, um, them in terms of their identity elsewhere because if you're keeping answers to things like who's your mother's maiden name or what are the last four digits of your social security number, that's the same information they could use to go then, uh, try and get into their bank accounts. So you really don't want to collect that kind of information. You really want to be using two factor in the form of something like Google Authenticator. People talk, people talk things about, like, the insecurity of SMS, but I think SMS second factor is actually pretty strong. Um, in the sense that you would still have to not only know the user's password, but also compromise some of the phone infrastructure. That may be viable for a nation state, but it's not, uh, it's not viable for a normal attacker. Um, and, um, and two factor authentication is important. Um, there was a hack that happened a while back where somebody called into Amazon and was trying to get into the person's Amazon account and Amazon said, oh, you don't have the right information. Can you provide me this? And through some smooth talking and social hacking, they're able to say, well, uh, you mean the account that ends with credit card number one, two, three, four? And they said, yes. And they go, okay, well, sorry, we can't give you access to that. Then they called up Apple and said, hey, I'd like to get access to my account. Sorry, I forgot my password. And Apple goes, well, what's the last part they did to your credit card? And they go, oh, it's one, two, three, four. And then they are, and they go. So even though you think what you're keeping is, is, uh, making your site secure, you could be making other sites and other services less secure by storing that information. And so moving to something that has two factor authentication, something they know and something they are, uh, physically in the real world is going to be much, much better than trying to just have, uh, random, um, questions that they're going to have to answer. Mm-hmm. Yep. So embrace the power of the dark side. Um, the, um, uh, and if you want to be super intense with things like SSH, um, and, um, doing hardware two factor, you can get hardware tokens like Yuba keys, there are multiple manufacturers of these sorts of things. Um, as, uh, support for things like U2F is growing, um, it's a super simple thing for users. They basically take a token, they put it in the computer, um, and they register it with their account. And then any time they want to log into their account, they take one of the registered tokens, which will usually be flashing or something when they need to tap it, tap it, and they're in. And it's basically proven that they have that hardware. And these, these pieces of hardware are designed so that if you try to get the keys off of them, they just, they get destroyed. So, uh, they're, they're really quite safe. Um, and, um, U2F is now deployed, um, on GitHub, on Dropbox, on Google, um, and it seems to be slowly picking up more and more attraction. Uh, it's probably one of the most safe second factor things that you can use because, um, it doesn't involve any communication over, uh, like SMS, it doesn't, and the user cannot copy the token. Like one of the problems with Google Authenticator is you can throw a Google Authenticator token into something like one password and then you're sharing that data in the same place you're tracking your passwords. And if you're, if your second factor is traveling to the same places as your passwords and is unlocked the same way as your passwords, it's not really a second factor anymore. So if you need the most insecurity, uh, most for security, uh, that was an unfortunate thing. Um, the, um, I would go with hardware tokens. Um, they're harder to implement but they can be worth it. So, uh, the other thing that we're gonna talk, um, about now and more in the, in the, uh, next couple of slides is gonna be social and federated logins. And it's the idea that, um, in this concept that why do we, as an individual site owner, have to require our own login? If there is a site or a service that already knows who that user is, we should be able to trust and know that that site, uh, is also protecting, um, the user's information. So using social or federated logins, um, Google, Facebook, uh, if you look, all of the sites that have had the major breaches are not the ones that we use as federated logins. They are, they are storing, um, their passwords securely. They are doing, um, security right and they are protecting their users. And so we can leverage that and by leveraging somebody else's authentication, we can actually, uh, decrease our footprint for attack on our own individual sites. And it prevents the use of passwords in multiple places, which then, if somebody gets one, they get them all. They, they're also doing a lot of implicit two-factor authentication in the sense of, they're looking at the GOIP location of where you are, how fast you could travel, what sort of devices you're using, what sort of your activity is, um, they're using a lot of heuristics on users, um, to identify whether the person is, um, legitimate or not. And then even if the user hasn't manually set up two-factor authentication, often, uh, tools like Facebook and Google will try to basically do something similar to that, where they'll say, this is an unrecognized device, they're not quite trusted, and then they'll make the user go through a couple extra steps to prove who they are, uh, even if they haven't manually opted into any two, uh, formal two- factor things. I mean, how many people have gotten those emails of your MacBook or your laptop just logged in from a location? How many of you have gotten one of those that it's like, who's Bekistan? I have. I get those every once in a while. It's like, log me in, we'll send me something saying, oh, by the way, somebody just tried to access your last pass from North Korea, and I'm like, thank you, North Korea, but you're not getting in. Um, and so, yes, use federated logins, use social logins, um, they have more budget on their login feature than most of us will ever have on all of our sites combined, so, um, let's leverage what they're building and, and make our sites safer. Uh, the other thing, though, is that at the end of the day, it all starts with a strong password. Uh, I get more frustrated and I will actually stop using services if I go to it and it says, please provide a password that's 6 to 10 characters long. I want to use a password that's longer than 10 characters. It won't let me. Um, if I, and I, I use a random password generator for, for every single password. If my random password generator is too strong for your site, your site is too weak for me. And so I'm gonna, I'm not gonna use it. Um, and so, if you are setting up passwords, um, for your site and you are allowing users to set their own passwords and not using something like a federated login, please, please, please make them, um, use strong passwords. Um, length is key. Length is what, um, what, um, defines the entropy of that, that password. Um, it's not the amount of symbols, it's not, there's the old XKCD, um, comic that you can look up of horse battery, staple correct horse battery, correct horse battery, staple fire. Um, and, uh, and, and there is that's no longer a safe password, but it's long enough that, um, it itself in plain English for random words put together is safer than your, you know, kid's name with a couple of exclamation points in there. Um, and so entropy is not only a factor of how many characters and what you're using, but also how long it is. And this sort of password check, uh, will also implicitly prevent most people from using basic dictionary words anyway, because you can't really just use the basic dictionary word and have it meet the length and complexity requirements here. This is Stanford's set for Stanford IT. And I've always really liked this one because it means that if I use a random generator that creates a long but not very weird password, whether it's dictionary words, um, uh, that are chained together on like three or, uh, like four or five dictionary words, uh, or maybe it's a password generator that's just doing alphanumerics, uh, for just like 20 characters of alphanumerics. Uh, it allows you to use those sorts of things and then if you use a shorter password it basically forces you to use more complexity. Uh, this means you can't type in a word, a normal dictionary word, uh, uh, anything up to say 15 characters, uh, and expect it to pass, um, this sort of check. And it doesn't even require testing it against the dictionary issue to have this work for avoiding most, um, bad passwords. So the other thing is, um, if you're running an internet or some sort of site that is, uh, is going to be sitting inside of a safe and secure location or assuming that we've already been breached a not safe and secure location, um, a lot of the times if you just have drupal or wordpress, um, with, you know, regular php exposed to the web, you're exposing your footprint for attack, um, to your entire php, uh, surface area. Whereas if you go and put in some sort of authentication with Apache and Sammel in front of that, they have to authenticate to Apache before Apache ever will touch php, which allows you to mitigate a lot of attacks that will come in, uh, and try to do, um, SQL injection or anything along those lines because if they can't access drupal to, uh, exploit a vulnerability in drupal, then they're not able to get in. As far as the security team for drupal is concerned, this sort of setup makes it so that you don't have what we would call a critical, uh, or, or a very critical issue with drupal because, um, this means that you're not even able to reach drupal until you're already an authenticated user. And one thing to look at is the Panama, uh, papers. That attack happened on both WordPress and drupal. Their front, um, facing consumer website was in WordPress and it was heavily, heavily outdated. And their, um, internal secure file, um, transfer and storage was a drupal site that still had the drupal get in, uh, exploit in it. And so by having some level of, uh, authentication before it, theoretically you could still run, but don't ever. You can still run a site that had the drupal, uh, uh, drupal get an exploit in it and it wouldn't be accessible unless the person had some way of authenticating into your system. And so it would have mitigated, um, that, and I'm sure there's a lot of millionaires and billionaires around the world that wish they were doing this. Uh, the other thing is sensitive data. Um, this is something that, that I preach on, uh, quite a bit. And if you have sensitive data, don't store it. Um, unless you know what you're doing around it. Um, the best thing is if you have to question whether or not you need to store it, the answer is no. Um, and now, I have a curly and striped from the, from the payment providers and MailChimp and Constant Contact and a lot of the, um, the email marketing campaign, um, SaaS products are all allowing you to leverage JavaScript to be able to post or um, actually um, I want to say a curly and brain tree now actually use iFrames for every single input on their credit card forms that post directly to their servers. Their servers are the ones that are taking all of the risk and, and um, compliance for PCI. This allows you to do SAQ AEP which is like the lowest. Oh, you don't even have to do EP for that. Hey, correct. Yeah. So you can do SAQ A. So you can do SAQ A. SAQ AEP is for um, if you have a JavaScript um, direct post. Uh, but either way, even if you're doing SAQ A or SAQ AEP uh, both of them allow you to get by with, with um, a lot less checks that have to happen on your site so if you're building sites for customers then they say, I want PCI compliance. Um, you're gonna be able to come back and say, well because I'm implementing one of these modern um, payment providers or email marketing we're gonna be able to allow you to do a lower level of SAQ which is gonna cost them a lot less money and um, be much easier to maintain. SAQ A is so short. Uh, there's, there's almost no excuse at this point to not kind of implement something in a super simple way with the iframe payment entry and uh, and minimize your risk, minimize your compliance needs and minimize your tax surface. And so how this, uh, how this works is that uh, the, the user agent, uh, in this case it's gonna be a web browser requesting Drupal, uh, they're gonna go out request the web page and bring it back and have the credit card form. They input all of their credit card information into it, but when they hit post it's gonna post to the external service directly. So in this case, say Recurly, it's gonna post directly to Recurly. Recurly is gonna process and store that information. They have the ability to store credit cards according to PCI standards and they're gonna send back a token. That token is then passed back into Drupal and Drupal then goes to Recurly and says, I have this token and I'm supposed to uh, be getting $50. Is that correct? And Recurly comes back and says, yes that token matches to $50. Here's some basic information on that user if you uh, want some information to store in your order. And so by doing that what you've just done is you have eliminated the even in-memory chance of a credit card passing through your servers. And by doing that you have greatly, greatly decreased uh, the footprint for attack for somebody to come in and steal and scrape credit cards from your website. Having a token from a service like Recurly to charge a card is not considered card holder data by PCI uh, because uh, all they have to do is cancel the tokens for your service if everything reaches. They don't have to replace everyone's cards. They don't have to figure out whether there were other fraudulent charges from other vendors uh, and uh, you're pretty safe uh, that way. And the tokens themselves can be stored in your database and they themselves are not are not considered PII. They don't contain any information um, they still have to be combined with uh, API tokens and such to even get into the system elsewhere. So um, tokenize everything implement one of these modern systems and and make your life a lot easier. Um, the next piece here is that um, key management um, shameless plug this is our company's whole purpose for locker in the U.S. um, also runs a KMS system um, Townsend Security has Alliance Key Manager um, Vault by Hashtagorp is a great open source project that you can install and and run on your own servers. And how it works is the idea is that anywhere you're using a key or an encryption key, whether it's an encryption key or it's an API token or an API key, if you have a secret you should not store that secret in the code and the only thing they're gonna do is they're gonna grab a copier database and a copier code so if at any point they're locked out they still have um, something to work from and so if your keys are sitting in the database which I, I implore you to go look in your database and you would be shocked at all the information that's in there. How many people use the SMTP module? SMTP module? No, this is super high-end stuff. I'm not sure how many people can actually access this because, um, it's actually so many people can access and they're stuck in and so so, uh, it definitely helps a lot in today's department because when you copy your absolutely perfect in sanitizing that data before it reaches all those devices. Any information in that database is flowing to all those places and then the attack surface against that data is every single place that you've stored it. Which leads us to physical security. Um we don't recommend turning your laptop into a giant bear trap. Uh but we do recommend encrypting your your uh laptops and your local devices because as David was saying if your database has now been downloaded to everyone's local environment which is standard best practices. Now now you have a copy of your database running around and all over the world in some cases as we have remote workers now. Um your your database and your information are floating around. Laptops are stolen. Laptops are lost. Um use basic encryption and protection to make sure that your uh laptop is safe and not stolen. Yeah I mean how many people in here know someone who's lost their cell phone or uh or laptop? Pretty much everyone. Yeah. And uh also use the um uh find my iPhone. You have to turn it on in a lot of cases. Um I have found iPhones with that. Um I've recovered iPhones from people who mistakenly picked up the wrong iPad in Starbucks. Um it's a great service. It allows you to geolocate, send off alarms, send messages, all that good stuff to your device if it's stolen. Um there's other ones I've seen that actually will take pictures using the webcam uh of the person and email them to you so that you can then have photo evidence of whoever's stolen your laptop to uh to send to the police as well. And and I was mentioning mobile devices because a lot of people don't think about how much data is available through the mobile device. Um a lot of the services you're using allow password reset over email. Most of us have email access on our phone. So access to your phone is equivalent to being able to get access to any account where uh the account is uh is accessible purely through a password reset accessible over email. Um so one thing to also think about is trying to um to uh impose some device security at an organization. If you use something like um Google apps now called G Suite uh you can actually uh force all the devices accessing your Google accounts um to have basic security in place. That means encryption. That means a passcode. That means that it automatically locks the device after a certain amount of time. It doesn't have to be that strong. You can choose exactly what level you want um of that kind of security. But it at least provides a baseline where everyone's email uh access or anything else they can access through a mobile device is uh is locked down a little bit. Alright we're gonna have to cruise through these uh next couple of ones because we have some more exciting um ideas to get to. Anonymize your data. Um just uh Drush has some great uh commands for this. Sanitize all the emails so that your email turns from that into that. Um again it prevents a database that's being walked off. Um you're not leaking everyone's email along with it. Uh do you want to explain black wall APIs real quick? So um this is kind of the case with some things like the recurly and mail champ etc examples. But a lot of people think of access control as the basic level of access is like you have nothing and then you have read only access and then you have read write access. Uh but for a lot of sensitive data you might want to write the systems say for logging or other things in a way where they only provide write access. I call this a black wall API because you can only send information into it but never recover it. At least from the system that's sending the information. So what uh what might happen here is let's say you have your web servers. Let's say they're logging um things that might even be a little moderately sensitive or at least useful for some other attack. Uh those may be going to a log aggregation server. There's no reason your web servers have to have the ability to actually pull old logs down from the log server. Uh it should be that they should only pump the information to them and then that means that if someone compromises your web server all they have access to and information wise is the current information that that box has access to. They can't get access to the old logs. They can't get access to old data. In some cases that may be the right way to handle um data for users for like PII. So um again we've now assumed that the breach is in. Um the attackers are inside your system. How do we keep it from spreading into places we don't want it to be? Uh the first thing is isolate your systems. If you have web facing systems do not keep them in the same environment in the same cluster in the same PPC as everything that is internal. Um that's just like no no number one. Uh so anything that's active directory, HR exchange servers, mail servers, all those keep those in internal systems um that are not openly exposed to the web. Only exposed to the web what you need to expose. Um also uh shared secrets cause issues. Um if an app is trying to access a database um just through a regular password or key and all of a sudden the app itself is compromised. Now that database is also compromised as well and you have two points of attack. So shared secrets um including passwords even though that's what Drupal ships out of the box with um does provide the ability for somebody to attack one surface uh in one place and and uh migrated into another. So in order to prevent this uh what we recommend doing is putting in um a internal PKI that allows you to have uh certificates that sit in every single container and all of these certificates are signed by a certificate authority and they issue the uh not only the uh identity but the authorization of what that uh that container does. So what this allows you to do is allows you to run a solar container and it only runs solar. If for some reason it tries to talk to another system and uh set something in your uh DB for instance you can say no you're solar you just do solar um and this this implicitly can happen through the certificate and as you're creating the uh the SSL or TLS connection between the two services you can check those certificates and and um pull their identity pull the CA that they're from and make sure that they are who you um not only who they say they are but they're doing what they they're supposed to do. I um this is not a particularly easy thing to deploy but uh it does provide what what's called micro segmentation which is the idea that there's not one boundary to cross before you have uh carte blanche access to all the systems. You basically even if you get past this firewall uh you would need uh different identity information to access each of the systems. Um so um uh we uh this is how we do everything at Pantheon uh pretty much every system uh interacts this way. Um and uh there are open source tools for running certificate authorities like there's um one from there's a pretty decent one from Cloudflare that they've open sourced. It runs and go. You can set it up and then as part of provisioning your machines as part of doing your um uh your management through Puppet or Chef or whatever you can provision uh certificates to services. This is increasingly happening as part of a lot of container management tools. Uh Kubernetes is working on implementing it as a part of the foundation. And um Dr Swarm uh integrates a certificate authority as part of the infrastructure as well. Uh the idea being that like we just don't trust nothing. Like even if it's over your private network you can encrypt it. The cost the overhead of encryption is very very low at this point once you negotiate a connection. And you can keep that negotiated connection. Uh most systems automatically do this. When we switched to handling all dynamic requests at Pantheon over clear from the clear over to mutual TLS or MTLS as some people are referring referring to uh referring to it. Uh we saw no uh substantial change in CPU or other utilization of our systems. And one thing to note here is that when you're creating certificates from the certificate authorities um make them short lived. Make them live for 24 hours. You can you can automate to have these certificates created over and over and over again. That way if somebody does get into a singular system they may only have a limited amount of time before that certificate is expired and it's no longer usable and the next certificate is deployed. So oh I was going to say real quick we've got these um uh up here there's going to be code snippets and such. We're going to be posting our slides to um to the the uh website or the for the event. So you'll be able to get all these um don't worry about frantically trying to copy down all this code right away but well. This is just this is uh uh an example of connecting to my SQL. This is an example of connecting to solar with a certificate. This is configuring Tomcat as a as a container for for it to expect a certificate. Um the uh this will all be on the decks that we post online. Um Nginx uh can require a client certificate. Um I mean a lot of people here probably know how to configure the server certificate. But this also um requires that the client provide one to. This is a snippet from a Pantheon's um configuration. And this is uh if you go back this is actually how our service locker works. Um when we terminate the connection the first thing that we check is did you give us a valid certificate and are you uh coming from a place in a location that we know of? If not we don't even let you pass the uh the initial um connection. So this is a very very good way to um isolate your systems and make sure that um you're not letting somebody pass uh the Nginx or the Apache layer and into your application before you stop them because it may be too late at that point. Um and this yeah this is the Tomcat PPI the server side. Um this is uh uh Python making a request on the client side and using a certificate to identify itself to another server. Um and um it's worthwhile. But um really I think so certificates mutual TLS great. Uh but one of the things that excites me most about the direction of security is moving into capabilities. Um capability based security is the idea that you separate out who is doing the action uh which is either a person or system from what uh they are allowed to do in a way that doesn't require constant look ups to things like roles and access controls. Like in Drupal does not use this right now. Uh but we do want to make the case for it. So um we're gonna take the uh um the example here. Um we're blowing up Alderaan and we're gonna say uh set a course for Alderaan and um that uh the helms and the weapons team says alright and Alderaan gets blown up. Um but how it can also fail is if you mistakenly put in set a course for con- uh course con and all of a sudden um they've blown up course con. So um the idea here is that without any sort of um capability awareness and you're just taking in the commands even if the person is authorized to say it in this um in this point somebody's either governor Tarkin or somebody impose- impostering. Uh if they are just uh saying the command and the other the person who's listening says okay whatever you say um without looking and checking um bad things can happen. The the classic way that this attack is manifested on unit systems is that there's a utility called PSSWD to change your password and people have been able to trick it because it has at least in the past to have the ability to do anything as root on the system and it was responsible for um making the right checks about what it was doing but you could trick it into writing to different files in the system or altering a different user's password and as long as you could trick it it would excuse me it would do your bidding. So um the next is going to be um mandatory access controls and that uh goes by you know if I say set a course for Alderaan setting a course and then I check and make sure our is this person allowed to target rebels? Yes okay I will blow them up. Um if they say uh set a course for course it's gone. Gosh I can't say that today. Um and they check and say hey this person can only target rebels uh then we say back no in a very dramatic way like Luke Skywalker likes to do. Um because if we check to make sure that they have just the basic permissions um that's fine and that's kind of where we sit now in a lot of our systems is we we check do they have the ability to do this in a general fashion and if they do we allow it or not. So um a lot of the problem with mandatory access control and people's experiences with SC Linux um is that people do it as an after thought. Um even and I don't mean just an after thought at the level of uh people here installing um a Linux distribution and then setting up a web server. I mean an after thought in the sense that even the people who designed the Linux distribution often try and add it in as something like that. It's like um it's like having a huge area of land um and then saying to people build your houses wherever you want and we'll set up the fences later. Uh that's not a very effective way to to draw these and that's why so many people have frustrating experiences with it because you're trying to set up the fences um when no one took into account the idea that fences were going to be set up in the first place. So um I prefer containers where you start with the fences first. Um you actually say this is the scope that you're working in and then you fill them in uh with systems and that's a much cleaner way to do it. The analog the um the equivalent for houses would be creating plots of land and saying each person gets to build on this plot of land that makes it very easy to have the fences in place and it makes make sure that the boundaries are very sensible and orderly um and you don't really hear people complaining about like oh I don't know um you know this fence is going all the way over here to include logging uh and then um uh and then oh my house is over here like that's just not usually an issue. Um so containers are fun and containers often allow you to just like flip on things like SC Linux uh with very little effort. Um but capability based security is how I think um a lot of the system should go uh in the direction of. Um well where basically what we do here is rather than making it where say helm and weapons have the direct ability to target the weapons at whatever they want, what they have to get is an order that has been authorized like that is verifiably authorized by the right um requesting party. Um so in this case here um what we do is like Governor Tarkin has like a tablet where he can put in what he wants to target and then create an authorization code that he can then go give over to weapon and helm uh weapons and helm uh to uh have them set the course and fire on the target. Uh a random person cannot call uh helm and weapons and create this kind of code. Uh there's a wave uh there would be an implicit system where the only way for helm to actually set the direction they were going would be to put in one of these codes that someone else gave them. Which means that helm and weapons have no authority on their own to go target um uh a planet of their choice. Um it also means they can't be tricked because they don't actually have the direct access to do that in the first place. It also means that let's say we don't allow Governor Tarkin to directly access the helm console uh it means that he alone cannot actually target the weapons either. Um it basically means that two different parties have to be um participating correctly uh with each other for things to work. Um so um and the way this works for a lot of systems is by factoring access controls into um what you can do instead of who you are. Like um we don't just want helm to ask the question of who's asking me to target this planet because it's pretty easy to trick helm in that into that and it's pretty easy to trick a lot of systems into that. So uh what so it basically comes down to separating it out into um stages uh where um establishing ID is where you put in credentials um user password um second factor token something like that. In Drupal this gives you a session. Um Drupal doesn't care how you got your session but your session uh shows who you are. Um if you've ever integrated Drupal with social login or SAML or anything like that you know that there are other ways that you can set up Drupal to get someone to have a session without them having to kind of log into Drupal directly. Um and then what Drupal does is it kind of uh muddles the rest of this uh in a way that I think should be separated better. Uh what it basically does is whenever you try to do something on Drupal um it takes your session it looks at your user object and then says okay let me try and map the roles this user who's asking to do this um uh to the roles of that user to what they're trying to do and then look at the roles that are allowed to do that and then it typically makes the determination all in the same code path of who's allowed to do this um like is this user allowed to do this and do the thing. Um this is why we can run into security issues like uh the patch uh one that recently got uh an essay for uh for core where basically you could um you could trick Drupal into patching um which is altering a node through the REST API um uh an entity on the site even as a an under uh a less privileged user um and that's because um those systems are muddling those things. Um it's better to try and isolate it where what you do is you map the ID to roles and basically then you create a sort of um badge for the user that basically says here are the roles I have and here's like the hologram on it basically that shows that I have these things. It's kind of like a conference badge that shows what you're allowed to do like they don't actually look at my name to see if I can go into the like speaker area like they just look at the fact of this down here um and that makes it a lot simpler to determine it and say having someone sitting at the door looking up every person's name and um uh and then saying whether they can go in because then if I can convince them that I'm someone else uh in terms of giving them a different name uh it's it's easy to trick them. Um the uh uh I often like to compare this to a movie theater where um you buy a ticket from the box office they give you a ticket they don't actually care whether you use that or you give it to someone else and then to go into the theater they tear the ticket and that ticket is basically a capability token. Um but it isolates the concept of um who uh determining who a user is or a system is from uh what roles that user system has from what uh from the actual implementation that allows those roles to do things. And one of the things that uh is necessary in order for this capability based um authentication to occur and and authorization to occur is we're gonna have to change how we do core. Um I've I've kind of termed it containerized core uh where the idea here is is that uh we're we're kind of brainstorming over this is the the thought the thought question is is can Drupal run without the user module? Right now the answer is no. Like you you cannot run Drupal without the user module but what if we wanted to swap SAML uh a SAML based system that we already have existing we already have who the user is where they're at what their roles are all that. Why can't we take user module and and completely toss it and put in our own system that we already have built from an enterprise system that is already there. Right now that enterprise system then maps itself into Drupal and there's some sort of translational look up that has to occur. Um instead if we were to containerize core and have it so that each of these pieces are plug and play where we're kind of doing that now but even doing it more so um it allows us to prevent um uh session being your your uh your base but then also allows that uh SAML system to then also include capability tokens which then can be used throughout the rest of the system. Like what if you could click a single sign on the link and it just says this person has this name and email address and they are an admin on the site um and then it would like right now if we want to implement something like that we basically have to in the background create a user object assign the admin role to that user object set up a session for that user with that user um and um that makes it really hard to integrate Drupal where we do kind of co- deployed things where if you're deploying Drupal with Magento or WordPress or other systems or even just other unrelated things like email and um uh and maybe a wiki um uh it's it's just kind of it's just really difficult that Drupal um insists on owning the user and it has such close coupling of all the code to the kind of user object and roles. And more and more now we're hearing about um the idea of Drupal and insert the blank right Drupal and Magento, Drupal and dare I say like Drupal and WordPress it's someday what if we could run our blogging from WordPress and our entity structure from Drupal uh if you have a containerized core that could actually be possible. You leverage the best of all the different systems and allow Drupal to um kind of mold in it and accept itself into the various systems that it's in without having to create all these translational tables. And primarily in the enterprise and especially in the educational world um if you if you work at a university you've already got a very sophisticated user system in place why are we having to replicate that in Drupal and if you've ever tried to uh use LDAP or or some sort of uh federated login from uh an enterprise or educational um system it's not very easy in Drupal and that that shouldn't be the case we should we should make that the preferred method rather than kind of the bolt on method. So with that there's a lot of kind of heavy things in that last little section. Uh any questions we've got about five minutes for questions. Uh go ahead I think we want to use the microphone because all of this is being recorded for uh YouTube. So uh uh I launched in the enterprise and we're dealing with a pre supplied WAF which is causing havoc with our own sites and I and I'm not the engineer at the table so I'm sort of relating our problems but essentially the security rules. You didn't really talk about that in the sense that I'm part I'm one of many in an enterprise so I can't dictate the WAF but boy it's causing problems. Have you seen that can you speak to that is that relevant to? Um we WAFs directly is WAFs are sort of that front first line of security. It's usually designed to prevent the initial compromise of a site rather than prevent further compromise of the infrastructure. The um but I'm not sure what else to say about a WAF if you have to. Is it by design that it will sort of interact with your forms and and inject and present and so what we're finding is how good the WAF is is how good the rules engines are and this is the pointing finger debate that's going back at the home office which is this isn't a this isn't as modern WAF for our rules engine but that's where all the heavy less you have to that's the where the handshake has to be really good. Like good good right? Well it depends on the type of WAF it is. Um there are sort of whitelist WAFs and blacklist WAFs uh like if you look at the sort of WAF that Cloudflare deploys for example that's sort of a blacklist where they have rules in there to detect com uh to detect known attack patterns for known vulnerabilities. Those types are very easy to use because it's very unlikely that they're ever going to interfere with legitimate uses on your site. In fact the rules are designed specifically to only match something where this is sort of only the behavior an attacker would do like they might have like serialized PHP in like a variable uh like going to the search form or something. Well in Cloudflare um itself will present those challenges before it even allows the user to access the site or access anything internally. So um so those are are the recommended ones to use. But the um there's also the kind of more sophisticated but much more in depth task of doing a whitelist WAF where basically you often have to teach the WAF and you basically go through the exercise of using most of the components of the site um and um it starts to set up kind of heuristic rules about okay well when you're doing a web when you're doing a search that should be a field that is more than zero characters but less than 64 and alpha numerics plus spaces uh something like that. Maybe a few other exceptions but the problem with those sort of heuristic rules is it's very much like what I was talking about in terms of bolting on the security with um uh mandatory access control with SE Linux like if you're trying to add fences where fences had not been and were never intended to be in terms of the design of the system um it can be very hard to precisely set them up like if you do a rule like that and a user puts a plus sign in the search because they want to require that search term that may be entirely legitimate solar even will recognize it but uh the um the WAF may reject it so you may have a high rate of false uh positive matches for attacks so sometimes you still put it in a learning mode for a while even while running the site um so it's it takes a lot of hands on work to maintain a WAF like that and I don't know if you can do it really at like an enterprise wide level at arm's length and still expect good results because it has it has to be tuned to like the application. Thanks for the talk it was really interesting you mentioned in one of the uh slides that we should use uh you you uh you're using random bus generator to generate the password and it should be more uh more secure how do you remember those like do you have us do you recommend safe pass kind of technology? Personally I use one password uh because it's it's hardware based encryption um I I personally anyone's here is from last pass I'm sorry but I don't really like last pass yes it was compromise um because it's it's server based it's already had a couple of uh compromises and such around that and so um I really like one password in that it uh and there are others like it I just I'm a Mac user so it's it's super easy for me um it will randomly generate it it'll store it um I can access it at a later time um I know none of my passwords anymore none of them um and if I ever have to look them up like I had to uh put it into some Facebook login or whatever and I was sitting there for 10 minutes trying to get the whole thing right because it was a 40 character random thing so use some sort of application to store it for you um not just the random password generator. Hi guys uh great presentation just love it um I have a question about uh you mentioned PCI data that the but what about PII or HIPAA is there are there tools providers that we could link to that other than the ones we listed so so for PII and HIPAA you're gonna want to encrypt um the data if you're gonna be storing it so um come talk to me later I can connect you with Locker there's Townsend there's um server level um systems so if you're on Google Cloud they have key managers and encryption services AWS all the rest have them as well um but you're going to want to do that encryption nice thing about HIPAA is that they actually have a safe harbor clause that says if you're doing this right um granted they kind of paint it with a really broad brush and don't tell you what it is they just say do it right um which is encrypt it use a NIST validated solution with external key management and you check all those boxes and you can come back to them and say I'm doing this properly you don't have to notify anybody but the authorities about your breach because what's been lost is considered garbage data so you're not going to be drug through the headlines of um like I'm from Washington state and we had I believe it was Primera Blue Cross at eight million records and all the social security numbers lost um because they weren't properly encrypting that data but it is a lot harder with HIPAA and that that kind of use case because um you can't do quite what you do with um something like um uh like a credit card processing system because you actually need all the data like the reason why you're storing it is because you're using it. Yeah and searches and everything yeah. Like with the credit card case like you don't actually need the card number because you're not directly charging the card yourself. Like you have a provider doing it. Alright uh we're getting pushed out here so um thank you for coming uh make sure you head to the sprints on Friday um what did you think let us know um there's ways to review us online and um I mean of course be with you. Oh and if you want to continue talking security uh pub dog um brewery that's just down the road we're hosting a happy hour for the next two hours free beer free pizza come and enjoy so