 All right, hi everyone. So one more time, first DEF CON. Let me see show of hands because I saw it pop up and down. Wow. All right, it is DEF CON 101. So awesome. So welcome, welcome, welcome to all of your first timers. First off, I am, you need to hit the next slide. I'm Zach Basil. I'm a managing partner over at Urban Security by day that pays the bills for me taking photos of food because I'm that guy. And then Saturday night, if you want to come see me and Zach Barbie again, we're DJing at 1am at the party. So it's not going to matter. You're not going to remember. So when someone asks me what my credentials are, those are my credentials. And the reason I do that is because people like to have their long lists at, you know, black hat or say all these other cons about all the things I've done, who they are. But I steal a tip from a friend of mine, Bruce Potter, who is don't believe anything I or anyone else this week is going to say it. Bottom line is always question everything. I'm not going to read the whole quote from Buddha up here, but just challenge everything. Don't believe anything and don't ever hesitate to call bullshit. And that's for all you first timers here who probably like, Oh, what's going on here? Call bullshit. If you hear something you don't agree with. So first off, I like to start the talks as to what this talk is about. So you don't spend the next 40 minutes or so, waiting in here and go, I wish I went over to the DC 101 panel and snuck in. So we're going to be talking about cloud. And I guess we can't drink in here because they're confiscating beverages. So those who would like to play the drinking game, drink water when I say cloud, I guess. So obviously, we're going to predicate this on the providers being secure. We could spend hours talking about how, you know, the cloud is insecure because of its nature, but it's not 1999 anymore. It's not 2005. Things have changed where a lot of these cloud infrastructures are actually have mature security in place. But then it comes down to us to actually configure it in a secure manner. So we aren't going to be rambling about how cloud is all insecure because of its nature. We're predicating it obviously, like I said, on the providers being secure, we're focusing on a business level, not on personal because obviously personal is a lot easier to handle than if you've got 10, 100,000. We're not going to deal with 100,000. That's a whole other set of problems. And we try to brought this down to a DC 101 level. So this is not a talk about, again, be rambling about how cloud is a bad idea. I think I got that out of the way, maybe. We're not going to talk about every cloud provider out there's flaw with security or all the things that should be there that aren't. And we're not going to be talking about compliance at all. Okay, so a lot of you may have to deal with compliance and deal with what is PCI HIPAA, all the other letters mean and what does it mean for the cloud. We're not going to be talking about that because that could be a painful check box discussion. So first off, let's talk about cloud. This is cloud. Good, final fancy for it. Thank you. This is a cloud. I'm not sure if anyone's confused. Are you keeping up? Okay, DEF CON 101. I just want to make sure. I'm kidding. And this is the cloud. Obviously we've all become familiar with all these fun little logos. And for those again, we're going to start at the bottom and work our way out real fast. Cloud comes in three different flavors. Infrastructure is a service, platform is a service, and software is a service. Infrastructure is basically you provide the virtualization layer or the server layer and the network layer. You're responsible for the OS up. Platform is they handle the OS and they give you a nice little API to handle with some stuff. And the software layer is pretty much you've got a front end that's all you got. They handle all of it. So we all complain about security. We call it complain about cloud security. So when it comes down to why it applies for cloud is focusing on cloud wasn't designed for secure. I mean it was designed to be external. It was designed to be sharing. It was designed to be open and easy and hosted by someone else and shared in an environment that could scale. There's not a word of security in there whatsoever. And it's been tacked on as an aftermath. So we obviously with cloud we have no control of these environments depending on the level. Obviously like I said, infrastructure is possible from OS up. But you have this full trust and this other company to handle it fully and securely in the way they see fit, right? And unless you're, you know, coming with the Trace Coma's club, you can't really go in there and go, hey, I would like to audit this and see what you're actually doing. And like I said, share at Tennessee and then it scales. So we're stuck with it. It's not going to go anywhere. It's here to stay. We can fight the battle against it, but it's going to stay there. So assuming that everything is fully secured on their side, after going through all these different cloud platforms and all these different people using it, these are kind of the top things that I have seen as the mistakes people make, right? So from a user side and them inside, we're kind of going to split that. So on the user side, obviously you don't really have as much control as what, you know, your users in the wild are going to be doing. You have to basically let them roam free and put some controls on them and hope it's all good. On the administration side, obviously we have a little more control. That's how we're going to be able to take and actually, you know, control the environment and determine how it's going to be secured and how we're going to handle the environment. And that's where you'll see the list. The majority of the, this is going to show up on the sign. The majority of the fuckups happen. Kind of a vulgarity on the board. So we're going to kind of break down through these real fast. On the user author management side, again this goes without saying, I think everyone's noticed that there's a lack of 272 factor on a lot of these cloud services and it's difficult to implement in these pod environments. And having these users across all these different platforms, all these different environments because yeah, sure, some providers offer everything under the sun, you typically diversify. So having it so you can have unique logins on each service so it doesn't have that, you know, ability to spread is great but it's hard for people to manage. And there's too many credentials across all those services to manage and distribute across, you know, like I said, user base of 100,000, 10,000, so on and so forth. And another big thing is, you know, how long are these sessions valid once they actually get their session and are able to use it. Is it valid for the lifetime of them being logged in because they have an API key or is it valid for, you know, a 30 minute window? And it varies from platform to platform to platform. And I think the biggest problem we have is monitoring user activity. A lot of these cloud providers have put together these environments that, sure, they're monitoring on their side, they have their own audit trails, but they don't provide any visibility to the administrators, security teams, whoever it may be, as to seeing what actions are actually being performed so you can determine if it's an anomaly or if someone was breached and not just hope that it wasn't. And so a lot of these activity logs that some providers are starting to offer and we'll go into more as to a few of them in a minute. Some of them focus only on basic actions like I saw a user log in. Well, you know, given a valid session, that session could probably be migrated to any IP anywhere in the world. If you can't write a machine, how do you detect that activity? So it's what level of logging are they giving you? What information are they giving with it? And who's going to look at a web page that's going to show here's the last logins? We really need a way for these cloud services to be able to look at it through an automated method through some kind of API or web hook that's able to provide us with information. I need water for a second, so I'll just leave that for a second. So if a tree falls, that's my water break slide, sorry. So when it comes to not on the admin side, obviously we've seen a lot of issues on the admin management side of people using shared accounts across, you know, multiple people using password managers. I'll touch on that in a second. Studying reset password or reset questions that are obviously guessable or easy or shared or known. And not enabling two-factor because if it's a shared account, how are you going to do a shared two-factor across ten people? And then obviously if you do have unique accounts for each person, making sure they're disabled for everyone when they're terminated or they roll change and when two-factor actually doesn't do anything. So in cases of, and I'll touch on the second of like Heroku's tool chain, once you log in and use two-factor, you're logged in until you log out and that could be indefinitely. So great, you use two-factor on your first login, but you know, given that single login it could be used forever and basically equivalent of not having two-factor for any action you perform. So back to the admin side and I know people are going to start the debate with this because I love talking about this. I hate password managers and I know that's an unpopular opinion, but frankly I am not a fan because you've just put all your keys of the kingdom in a single place. Now I'm not saying all password managers are bad. I'm saying ones that are shared across, you know, everyone with a flat file or even these implementations like last password, you share all your passwords at once, they're not monitored and they can might be honored, but they're not. So I'm for one, see this is a big problem happening all the time, is that we put all these shared keys of the kingdom within a password manager and given one person accessing this, you know, they have access to everything. Now the argument could be made that if you get access to a machine you could get access to the password eventually, but a lot of these accounts you don't use every day, right? These are your backup admin accounts, these are your break glass, break fix accounts, and having them in a single password chain that is unlocked all the time and being used constantly, introduces a huge risk. Password ran over, we can argue about it over drinks afterwards, but that would be hours of arguments I've gotten into them. So when it comes to API keys, one of the big things we see is not locking down API keys enough, you know, they end up in GitHub repos, they end up in your code repos that are maybe, you know, internally hosted, or even just on developers workstations because of this whole DevOps movement, this whole idea that everyone needs access to production because, you know, we're fast moving, we're agile. And the majority of API's, you know, they offer some level of restrictions, but you know, again, depending upon the cloud service it requires review as to what level of restrictions the API keys have, whether or not it's, congrats, you have access to everything, or congrats, you have access to this little subset of services we're offering. And again, this very space-wide provider and we'll talk about that in a minute. And back to talking about the user monitoring, now on the AVEN side, monitoring those administration consoles for actions and activity. Detecting when there's changes to user accounts, detecting when there's changes to critical services or SSHQs, is really something that, without being told through some kind of notification, you have no idea. Unless you log in and check it every day, there's no idea that it's been breached or compromised without obviously some level of monitoring. And obviously the traditional issues, as the infrastructure side is saying, the majority of things is your problem from the operating system up. So, you know, making sure that you actually have a hardened operating system. And then on the more of the SAS in the past side, the shared accounts, the loosely protected code vaults, using voice over IP numbers for two-factor authentication, as obviously you're getting a token in email. And generally configurations, which we there's that laundry list of best practices. As people have scaled, they kind of had this huge level of trust on not just the cloud itself, but other cloud services that are leveraging other cloud and other third parties that we've kind of taken for granted, I think. We've taken and focused on having everything that we do is we need this third party provider as it's their problem. And then we leverage another third party provider as their problem. And there's a trust between our provider one and provider two. And so, in a lot of these cases, such as authentication, JavaScript, being injected in pages, and other files that may be hosted in the environment depending on its content delivery network, or if it's, you know, like your chef store. We start trusting all these third party services. And what happens is when one of these are breached, it starts with domino effect. If you compromise this one side, it can leverage, you know, the front end, which can leverage injection, that can leverage into getting a password, that can leverage access to it. So, we start having this trust that people don't commonly think of if this one thing all the way off on the end is compromised or breached or hacked or whatever you want to call it today. What's the impact all the way down to what matters? And this is just the fun word of warning of, in that whole trust relationship, people have really trusted them, you know, that this cloud is secure, but there have been cases where people have been, well, at least one confirmed case. Someone's been hacked out of existence because they put all their backups within their same AWS account which had access to, well, the production environment. And when they got access to it, they deleted everything. You know, and basically, there goes their backups because it was in the same exact place as everything else. Another big thing is people kind of go on this crutch of encryption, right? The idea that, you know, we need all our data encrypted, encrypted, encrypted, encrypted, because that's what we didn't tell them. Encrypted in transit is a good thing, it's needed, it's necessary. But this idea of encryption at rest, there's still access to that data, right? You know, there's still where you're able to log in through a web portal and have access to all the data. How does that encryption actually matter? Is that actually going to be encrypted in the browser level? Or is it just at disk? And if it's on the disk, who cares, right? You know, it comes to the sense of, sure, if someone comes in there and takes a hard drive out of this data center in the middle of, you know, some secure site, well, yes, that's protected. But how often is that actually happening? How often are we actually seeing someone drive a truck into a data center, smash through the wall and take all this data out of there? We're not seeing that. So this encryption on data at rest doesn't really matter in a lot of these cases when it's, you know, in a data center with these cloud services because it's being unencrypted and sent across all the other cloud services and all the cloud systems. Now, obviously there's, there's variances for certain services that do encrypt it on the whole side, but we'll get to that later. So how do we actually, we talked about the laundry list of problems, right? This is all the things we commonly see as the big cloud problems. How do we actually harden it? Now, before we continue through, like, this kind of laundry list of services I have, I want to kind of just preface it with, I do not pick on any specific cloud provider. I kind of like to go through the gamut and the top things people have seen used. And obviously things change. So this might be outdated as of when the slides are finished up. So it might be a little outdated, but it should be relatively accurate on the timeline for everything. So starting in infrastructure side, like I said, we're really reliant upon what we're provided with from a cloud service provider. And so I like to use this example as someone who has kind of led the way of doing it right to provide us the most we can to secure the environment and trust that they're actually securing it. And this is by no means an endorsement. So please don't all jump on me because I kind of love them. But obviously Amazon, they've really done great work on the web services side of providing obviously this laundry list of having unique permission models or models for every person who's an administrator, having two vector authentication that doesn't require you to have a text manager send to your phone. Supporting single sign on includes actually supporting open ID as well, which is not currently seen. You usually see SAML everywhere. And most importantly, supporting logging that we have visibility and access to. For those who are not familiar, AWS offers, I can't remember when they rolled this out, but it was relatively with the last two, three years I believe. Someone correct me if I'm wrong, but AWS offers CloudTrail, which is a nice little service that takes the audit logs from your events from APIs or IAM or S3 or however you're connecting into your services they offer and provide them in a flat file that you can download, do a regular basis to monitor and see what that activity is. And this is what I'm talking about when it comes to logging and providing that kind of transparency is to be able to see from that perspective, okay, I've seen that this action is normal, normal, normal, normal, normal. What does this API key request and this stuff from? I've never seen it before. And be able to make those judgments yourself. Now, I'm not picking on anyone, but on a less secure side, you have like a service like Rackspace, which is growing and changing. And again, I'm not picking on anyone in particular, but you have two factors that relies on SMS has, you know, the unique permission modules and all that fun stuff. But it doesn't really offer an API platform for you to get that logging data out. You kind of trust that if someone got access to it, they should have access to it and you're not able to monitor for that at all. And also don't doesn't support single sign up either SAML or other methods. So to kind of go through the laundry list, I won't eat up too much time on all of these, I swear they're not progress slides, just kind of fun information. Digital ocean obviously is a big one that's kind of been growing has, you know, strong permission models, doesn't have single sign on yet though, but to support TOTP use. So it's offline two factor and the logging they have some that they're starting with in their actions API, but it's not fully robust or as robust as a lot of the events you would want to get. Same thing on the software side. Another company a lot of people are moving to for cloud services. Since I think I'd be in bottom a few years ago. Obviously, you have strong permission models, but again, some kind of logging kind of coming out, but how do you get these actual events since it's not a lot. And then finally a joy into the other big infrastructure as a service that I've always been going to is, you know, strong factor, but no logging, no single sign and these are things you want to look for when you're kind of selecting where you want to send your stuff in the cloud. So on the services side, we're looking for the same kind of thing, but probably more logging because obviously at that level, we need, we're fully trusting the platform, fully trusting the software and we need to see what events are actually there. We're not able to implement our own on the operating system level. So obviously 65, as I like to say, I'm not going to read through all of them, but the one thing I'm going to point out is that the logging side, they've just started offering, they've offered it for a while for Outlook that or exchange, sorry, for exchange you've offered it through PowerShell to be able to monitor it, however, they just recently rolled out this new management activity API back in April. Now, it's nice to see them taking a separate right direction of offering these kind of logging events that everyone can take and monitor, however, it was limited release, it was focused on a lot of these vendors that were offering these cloud SIM solutions, so you had a request access to it. So I'm not sure the current state of it today, but it seems like it's rolling forward as they have a list of I think 20 or so partners that actually will capture this data. So it's good to see that you're able to then get that traditional logging data out of their infrastructure that you would normally have if you had yourself. On the Google App side, again, another strong case kind of similar to the Amazon side that they've grown and adapted, strong permission model, strong two-factor, being able to do it offline, having SAML, which is always great. And on the logging side, yes, they have their reports API login activity. I'll go through a little bit of logging in a minute here, but we'll get through the rest of these so we don't eat up too much time. On the Dropbox side, again, strong model logging is offered through their audit log API endpoint. Box, for some reason people are going to box or box. Box also offers logging and they do offer SAML and this is the interesting one, they offer it by request through your account manager. So I don't know if there's an additional charge or if they offer it as a feature, but there's no way to automatically enable it to my knowledge. And they do also offer logging, like I said, through kind of a more verbose of all the logging platforms I've seen through their events API. So you're able to get a lot of this information in regards to, you know, the files are downloaded, the files are uploaded to that level beyond just somebody connected, somebody logged in. And that kind of gives you that kind of anomaly data as well that you will see. I just saw someone download all of this folder, all of this data, what's going on here. And another strong case Salesforce, but we all know about Salesforce probably by now. They have their login history, which is going to be their login channel. And so the list goes on of all these different service buyers. I try to call out the big ones, but these are the key things I think when you're looking for what you're going to host your cloud services through that you need to look for. You need to make sure that you can have unique admin logins for every person, not have a shared account. So depending upon what services they offer, you're able to take in, you know, enable or disable people who have their unique accounts and be able to tighten up those permissions instead of just their admin have fun, they're able to limit it to a certain level. That they have two factor or two step for those who want to argue it. Authentication, whether it be through TOTP, which is the standard that does it based on time and age back to 95 offline, or the SMS, which again requires live cell connectivity, which I hate on planes, by the way. Single sign on by the Wi-Fi on planes and two factor does not mix. It's not fun. Single sign on using SAML as that's kind of becoming the standard for single sign on as you're able to then take and roll the authentication back to your side and to control the access at a single centralized source instead of across a large number of platforms. And then obviously the key thing I like to think of it to look for to see how far they are in their platform is the capabilities they have on the audit trail side and what they are actually provide on a long perspective. Now, obviously whenever there's a problem the industry has jumped to it and says I can fix that. I have a product that will celebrate. So they've always had this magic security bullet. By the way, I've noticed I've included some Silicon Valley stuff in there. How many people actually have seen the TV show? Good. So it's not lost on everyone. Obviously. So if you haven't seen it I love it. It's fun. I like my TV shows. This time it's Silicon Valley. Last year was Archer. So sorry for your Archer fans. I still love them. But on the magic bullet side of being able to fix everything they really come in these five flavors. Some kind of transparent proxy or visible proxy. Some kind of client endpoint program. Some level of monitoring through an API or through a web hook or proxy. Identity management because that's the buzz words for the last three years. And obviously leveraging APIs to get information in a pretty fancy way. So on the encryption side this is where the proxies really shine. A lot of these cloud security providers are sorry to offering these proxies whether it be on a host level to the encryption or on the web level side. And so on the transparent proxy on the web level side or non-transparent the problem you run into is that it doesn't work with non-web applications. So you're limited to using only the web applications with only API endpoints through the limited subset of things you have. So really it breaks a lot of functionality when you use these kind of transparent proxies. Now vendors will argue both ways. I find it breaks. And obviously your mileage may vary. But it also requires leveraging set proxy for access. So whether it's behind your firewall and you have used traditional VPN to get in, which basically defeats the purpose of having cloud or having it where you have to have an external endpoint, which again is having cloud all over again. Just a different kind of cloud on the cloud of the cloud doesn't really solve the problems to my mind. And then the host level encryption which for when it mostly comes to file hosting provides a virtual folder that encrypts the files before it even hits the sync. So this could be in and of itself a 20 minute ramp. But I want to be fast on this. Certain cloud providers remain nameless have offered function preserving encryption. So this in a lot of cases is not encryption to the standard we think it is. So basically what happens is in order to preserve the function of the application you're leveraging, you need to be able to do some certain things. You need to be able to search and you'll be able to sort. And those are really the two key features they talk about is searching and sorting because what could is a cloud application if you break it completely because you encrypted everything. You're not able to search for things. Well, then what's the point? What happens is in order to make it searchable, you have to make it so this word is the same word across everywhere in every file and every every field, everywhere it's referenced it needs to be seen the exact same way. So what you effectively create is a substitution cipher which is basically saying dog is cat and instead of using plain English that we see, it leverages UTF depending on the support of the individual application. So you'll see a bunch of Arabic or Mandarin characters or Japanese characters because it's using the full character set visible and invisible in order to render it within that field and be compliant with the application. But again, no matter whether it's visible or not to a program, it's still there. And it's a simple substitution cipher that given enough time and given enough review, you can take and figure out what this jumbo bunch of characters is to the other thing. Now on the other side where it comes to sort, you have to be able to preserve the order. So in order to be able to preserve the order, you have to make a greater or less than d, less than c, less than d, so on and so forth. So what you essentially create in the length as well has to remain similar in order to be able to take and say this word is short of this word. So when I do the sort, you know, I'm able to know which one's more and which one's less. And be able to reference each character. So what happens with these function preserving purposes that support sort, you've effectively created a dictionary that you can sort in order of all the crypto data and go, okay, well, this is at the top, so I'm going to assume this letter is a and then this next letter is well, maybe a b and figure it out over time because you have this large set of data that you're able to map to. Now granted, this is only when you use this function preserving encryption. This is not to blast any product completely as a problem, but that feature set that people are being sold on, it's snake oil. I hate to say it and I'll probably we'll get some black for it, but there's a little tiny URL there if you're so interested in reading up on the argument and the DMCA takedown this certain vendor provided against someone for a legand. But it's not just this one vendor, it's a few other ones as well. Again, on the product side, I know I'm running short on time, so I'm going to speed it up here a little bit if I haven't been doing fast enough. So on the auto-trial management side, being able to grab those logs that we're talking about earlier, it's very dependent on what API they provide. And in some cases they implement a proxy that they're required to go through with that encryption feature set to be able to log all the user activity, but then requires you to come from a certain IP. On the identity management side, obviously being able to bring that in, they use SAML OpenID and to connect into existing database or user data stores to be able to determine, hey, I'm going to connect to Active Directory or connect to LDAP or connect to Radius and use that as my store and provide these SAML services to the problem. And then on the API side, obviously leveraging existing APIs, these tools will tell you, okay, well, you're insecure in these 10 configuration ways. Well, I could kind of see that through the web portal if I had to walk through, but okay, thank you. That's cool to give me a little score. So I always like to say, you know, sure, these expensive products work great if you have large numbers of users, but what if it's three of you on a dev team or five of you on a dev team, you don't have the budget to handle it. So I like to always say, build it yourself, fix it yourself, figure out how you can make the boast with what you have for now. Obviously, if you can afford it, you can afford it. So obviously the basic 101, Hardnet, which is obviously simple. The key thing I want to point out here is watcher, if you're using some kind of tool chain associated with one of these cloud providers, a lot of them will patch the tokens on the system for a long period of time. Like I was saying on the Heroku side, if you don't log out, you have it forever. And obviously, watch where your code repo is, especially if you're using some kind of automated continuous integration or leveraging it for something like Chef or Puppet. Make sure that that area is hardened and secured so not anyone can commit to it which then, like I said, in the trust relationship issue can then impact all the things down the line. Monitoring integrity is an interesting side that I don't think when it comes to cloud, enough people do. On the infrastructure side, it's easy. Traditional file integrity monitoring kind of handles the actual operating system in the host level side. When it comes to the platform side and the software side, you really have to rely on the platform side. You can obviously script your own thing to check to see if a page has changed or if there's a change to something you've referenced or some JavaScript. You can script that out as I kind of touch on that later on in this list is building your own cron job to monitor and see if there's any difference in the code. And then we're notifying you that there's, hey, I've noticed my homepage has changed. I've noticed that this JavaScript library now all of a sudden includes it on their line. That's externally referenced. On the staff side, however, there's not really anything you can monitor. I mean, it's not like you can monitor that it changes their code because they're changing it all the time. So you really have to rely on their available APIs and the logging side. Back to the whole authentication side, implementing single sign-on is not as hard as everyone tries to make it out to be unless, again, you have 100,000 users. When it comes to implementing SAML, there's some existing open source tools that are out there that'll let you do it. Glue is a front end GUI package of Shibboleth which is Java based and there's simple SAML PHP which is a PHP based one. There's also Ruby libraries that all have the identity provider side of it. SAML is a whole talk in and of itself so I'm sorry if I'm covering a very high level but on the SAML side, there's different roles and you need the identity provider role. But the key thing is no matter how you implement single sign-on, if you're rolling it yourself, you need to make sure that you have some level of multi-factor on that single sign-on that you protect those certificates and those keys that single sign-on is using and see what the support for the endpoint you're using is for these single sign-on applications. In a lot of cases, you still have to generate per application password which in some cases, defeat the security in the first place. Or at the end of the day, you could just leverage some cloud service or cloud VM demands and cloud of the cloud. But this also provides an interesting logging aspect for you to be able to capture all the logins and all those events on your own side but obviously not subsequent action logs. So if your cloud provider doesn't support it, did I just lose signal? No, they lost signal. Good, no more words. So back to the API key side, again, with it being distributed across everywhere, it's really easy to build your own API proxy. It's a few lines of code to be able to take and there's a sample up on that tiny URL, to be able to take and build a proxy that you can basically write your own API abstraction layer that says, here are my internal API keys and I wanna protect these actual production API keys really tight within this little proxy I'm writing. And then you can write your own level of source IP limitations, dynamic and provision keys and really provide a nice little layer in front of whatever the cloud provider is which may have a more rigid kind of OAuth key or not OAuth key, OAuth key layer. That was a lot, sorry, I was distracted. Again, another big thing is if you're not able to use single sign-on is and you have to use shared accounts when it comes to two factor for these shared accounts, make sure it's enabled and if they support TOTP being able to take and leverage your own two factor because TOTP is actually an open RFC standard that you can get online and logging the use when someone requests one of those. Again, very easy to script up and there's Ruby and Python and Hurl and HP libraries for all of the HMAC TOTP stuff. And then finally, since I'm running out of time, is audit, audit, audit, audit, log, log, log, log, log. I know my last talk was about logging all the things but we need to start monitoring and logging our own activities on these service providers or software as a service cloud size. So again, it's very largely dependent upon whatever cloud servers you're using. So it's one of those things as you select a cloud service you need to make sure you focus on. When it comes like it's an Office 365, it's very PowerShell focused right now so make sure you have something that's PowerShell friendly. And the admin events API is kind of brand new except for the exchange side which has the existing infrastructure there for an audit trail, more of our compliance side but it works. Dropbox, Box, AWS, Google and a few others, they're polling based. So they're actually API calls you have to make. So when you build this application you have to actually pull out a regular interval or whatever interval you want to set. It's not like it's a web hook or an event that you're able to take and say when this event fires, send me a notification. And there are a few platforms that offer it but the majority do not offer that kind of level. So you need to make sure you're able to have some kind of application that's able to pull out a regular base. Send them somewhere you actually monitor or generate email alerts, something you're actually going to see, holding onto them means nothing unless you actually follow up on them. And there's a quick little script up again at that tiny URL for a little script you're called stormy the cloud, which kind of works. So that is it. I mean, I've been told since I was short on time, I'm going to take questions out on, that's the exit side? That's the exit side. So I'm going to go out those notes. So I'll be chilling out there if anyone wants to ask any questions or have any follow ups. So we can get the next talk in here because we took a little time to cycle through. Other than that, here's my contact information. Thank you for coming. Welcome to DefCon for all your first timers and have a great week.