>>Hi, everyone.  One more time.  First DEF CON let me see show of hands?
  Wow.  All right.  It is DEF CON 101.  Awesome.  Welcome.  Welcome.  Welcome to all of you first timers.  First off, I am Zack Fasel I'm managing partner over at Urbane 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 Sec Barbie we're Dj-ing at 1:00 a.m. at the party.  It's not going to matter you're not going to remember.  When someone asked 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 Black Hat, RSA all these other Cons of all the things they have done, who they are.  But I steal a tip from a friend of mine, Bruce potter, who, says don't believe anything I or anyone else is going to say.  Bottom line always question everything.  I'm not going to read the whole quote from Buddha up here, challenge everything, don't believe everything, don't ever hesitate to call bullshit that's for all of first timers, what is going on here?
  Call bullshit.  If you hear something you don't agree with.
  First off I like to start the talk, what this talk is about so you don't spend the next 40 minutes or so waiting, I wish I went over to the DC101 panel and snuck in.  We'll talk about the cloud.  I guess we can't drink in here because confiscating beverages those who like to play the drinking game, drink water when I say "Cloud" I guess.  Cloud.
  Obviously we're going to predicate this on the providers being secure.  We spend hours talking about how the cloud is insecure because of its nature but it's not 1999 any more.  It's not -- things have changed where a lot of these infrastructures were actually security in place.  But then it comes down to us to actually config in a secure manner.  We aren't going to ramble how cloud to insecure because of its nature.  We're predicating it obviously like I said, focusing on a business level not on personal because obviously personal is a lot easier to handle than if you have got ten, hundred, thousand, we're not going to deal with hundred thousand that's whole other set of problems.  We try to bring this down to DC101 level.  This is not a talk about, again, rambling 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 is flaw with security or things that should be there and aren't.  Not talking about compliance at all.  Lot of you have to deal with compliance, deal with what is PCI, HIPAA, what does it mean for the cloud.  We're not going to talk about that  because that could be a painful check box discussion.  First off, let's talk about cloud.  This is cloud.
  Good.  Final Fantasy! thank you!
  This is a cloud.  I'm not sure if anyone is confused, are you keeping up?
  Okay.  DEF CON 101.  Make sure.  Kidding.  This is the cloud.  Obviously we become familiar with all these fun little logos, and for those again we're going to start work our way up fast, cloud comes in three different flavors, structure, software, platform.  You provide the virtualization layer, network layer you're responsible for the OS up.  Platform handle the OS gave you a nice little API.  Software layer is pretty much you got a front end that's all you got.  They handle all of it.
  So, we all complain about security, we complain about cloud security when it comes down to why it applies for cloud focusing on, cloud wasn't designed for a cure.  Designed to be external, sharing, designed to be open and easy and hosted by someone else and shared in an environment that can scale.  There's not a word of security in there whatsoever.  It has been tacked on as an after thought.  We obviously with the cloud we have no control of these environments depending on the level, like I said infrastructure, you're responsible from OS up.  Much you have this full trust this other company to handle it fully and securely in the way they see fit, right?
  In less you're coming with the trace Comas you can't go in there go, I would like to -- what you're actually doing.  Like I said, shared tendency it scales.  We're stuck with it.  It's not going anywhere.  It's here to stay.  We can fight the battle against it but it's going to stay there.
  Assuming everything is fully secured on their side, after going through all these different cloud platforms all these different people using it, these are kind of the top things that I have seen as mistakes people make.  From the user side and the admin side… We're going to split that.  User side, obviously you don't really have as much control as what you're users in the wild are going to be doing you have to basically let them roam free and put some controls on them hope it's all good.  On administration side we have a little more control.  To be able to actually control the environment and determine how it's going to be secured how are we going to handle the environment that's where you'll see the list, the majority of the -- going to show up on the sign.
  Majority of the fuck-ups happen.  Yes.  On the board.  We're going to break down through these real fast.  On the user auth management side this goes without saying everyone notice that there's a lack of two separate -- two factor called services.  It's difficult to implement in these cloud environments.  And having these users across all these different platforms all these different environments because, yes, sure, some providers offer everything under the sun.  You typically diversify.  So, having it so you can have unique log in so it doesn't have that ability to spread, is great.  But it's hard for people to manage.  There's too many credentials across all those services to manage and distribute across like I said user base of 10,000, so on so forth.  Another big thing is how long these sections valid once they actually get their session and able to use it.  The it is it valid for the lifetime because they have API key or is it valid for 30-minute window.  It varies from platform to platform.  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 have their own audit trailings.  But they don't provide any visibility to the administrators, security teams, whoever may be, as to seeing what actions are actually being performed so you can determine if it's an anomaly or someone just hope that it -- so a lot of these activity logs that some providers are starting to offer, we'll go into more as to few of them.  Some of them focus only on basic actions.  Well, given valid session, that session could probably be migrated to any I.P. anywhere in the world.  How do you detect this activity?
  It's what level of log in, what information are they giving with it and who is going to look at a webpage that's going to show, here is the last log in.  We need way for these cloud services to be able to look at through automated method through some kind of API or Webhook that is able to provide with that information.
  I need water first.  I'm just going to leave that up for a second.
  If a tree falls -- that's my water break slide.  So, when it comes to the admin side, obviously we've seen a lot of issues, if people using shared accounts across multiple people, using password managers I'll touch on that, setting reset questions that are obviously guessable or easy or shared or known.  And not willing two factor if it's a shared account how are you going to do a share two factor across -- ten people.  Then obviously if you do have unique accounts for each person making sure they're disabled for everyone when they're terminated or patrol changed.  When two factors doesn't do anything, so, in a case of, I'll talk about -- tool chain.  Once you log in use two factor you are logged in until you log out.  So, great.  You use two factor on first log in, but given that single log it could be used forever, basically equivalent of not having two factor for any action.
  Back to the admin side.  I know start the debate with this because I love talking about this.  I hate password managers, I know that's an unpopular opinion.  But frankly I am not a fan because you have just put all of your keys to the kingdom into a single place.  Now I'm not saying all password managers are bad I'm saying ones that are shared across -- everyone with a flat file or implementations like last password, where you share, all your passwords at once, they're not monitored and they can be monitored but they're not.
  I'm for one see this as a big problem happening all the time is that we put all these shared keys of the kingdom within password manager, and given one person accessing this, they have access to everything.  Now the argument could be made if you could access to the password eventually but at lot of these accounts you don't use every day.  These are you're back up admin accounts, break glass, break fix is accounts having them in single password that is unlocked all the time being used constantly, kind of introduces a huge risk.
  Password ran over, we can argue about over drinks afterwards.  That would be hours of arguments, so when it comes to API keys.  One of the big things we see is, not locking down the API keys enough.  They end up in repoes, in your code repoes that are internally hosted or even just on developer's work stations because of this whole DevOps movement.  Everyone needs access to production because we’re faster and being more agile. The majority of APIs they offer some level of restrictions, but again depending upon the cloud service it requires review as to what level of restrictions the API keys have whether or not you have access to everything or have access to this subset of services we're offering.  Again, various based provider we'll talk about that in a minute.
  Back to talking about the user monitoring and the admin side.  Monitoring for actions and activity.  When there's changes to user accounts, changes to critical services or SSH keys.  It's really something that without being told through some kind of notification you have no idea.  Unless you log in 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 infrastructure side as I was saying majority of the things is the operating system, making sure that you have a hard operating system then on more of the Saas and Pass, the loosely protected code vaults using voice over I.P. anybody's for two factor authentication, as obviously you're getting token in e-mail.  And general configuration, where is that laundry list of best practices.
  They had this huge level of trust on not just the cloud itself but other cloud services are leveraging other cloud and other third parties that we've kind of taken for granted, I think.  We've taken focused on everything everything that we do as third party provider as their problem.  Then we leverage another third party provider, their problem.  There's a trust between provider one and two.
  And so in all of these cases such as authentication, java script, other files that may be hosted in the environment depending if it's content delivery network or if it's like your chef store, we start trusting all these third party services.  What happens is when one of these are breached it starts the domino effect, it compromise this one side they can leverage the front end which can leverage injection, that can leverage, the password, access to it.  We start having this trust that people don't commonly think of if this one thing on the end is compromised or breached or hacked or whatever you want to call it today, what is the impact all the way down to what matters.
  This is just the fun word of warning, in that whole trust relationships people have really trusted them, that this cloud is secure but there have been cases where people have been -- at least one confirmed case, someone has been hacked out of existence because they put all their backups within your same AWS account which had access to the production environment and when they got access to it they deleted everything.  There goes the backups, same exact place as everything else.
  Quick water break.
  Another big thing is people the sense of encryption.  The idea that we need all our data encrypted, encrypted.  Because that's what we have been told.
  Encryption 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?
  There's still where you're able to log in through a web portal have access to all the data.  How does that encryption actually matter?
  Is it actually going to be encrypted in the browser level or just at desk who cares, right?
  Comes to a sense of, sure, if someone comes in takes hard drive out of the datacenter in the middle of some secure site, well, yes, that's protected.  But how often is that actually happening?
  How often are we seeing someone drive a truck into a datacenter, smash through the wall take all this data out of there.  We're not seeing that.  This encryption on data at rest doesn't really matter in a lot of these cases  in the datacenter with the cloud services because it's been unencrypted across all the cloud systems.  This is for certain services that do encrypted on the host side, but we'll get to that later.  How do we actually -- talked about the laundry list of problems.  This is all the things you commonly see as the big cloud problems.  How do we actually harden it.
  Now, before we continue through like this laundry list of services I have I have want to just preface it with, I did not pick on any specific cloud proffer I like to go through the gamut of the top things people I've seen use, and obviously things change so this might be outdated as of when the slides were finished up so it might be a little outdated but should be relatively accurate on the timeline for everything.
  Starting with the infrastructure side, like I said we're really reliant upon what we're provided with from a cloud service provider.  So, I like to use as example 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 endorsement, please don't all jump on me because I kind of love them.  But obviously Amazon.  They have really done a great work on the web services side of providing obviously this laundry list of having unique models for every person who is administrators.  Having two factor authentication that doesn't require you to have a text message sent to your phone.  Supporting single sign on includes, actually supporting open ideas which is not commonly seen, usually see Sam 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 it was relatively in the last two or three years I believe, someone correct me if I'm wrong.  AWS offers cloud trail, 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 it to your -- and provide them in a flat file that you can download to regular basis to monitor to see what that activity is.
  This is what I'm talking about when it comes to log in providing that kind of transparency to be able to see from that perspective I've seen that this action is normal, normal, normal, normal, what is this API key requesting this from, I've never seen it before.  To be able to make those judgments yourself.  Now, I'm not picking on anyone but on a less secure side, you have like service like Rackspace, I'm not picking on anyone in particular has two factors that requires on SMS the permission modules all that fun stuff.  The platform for to you get that logging data.  You trust that if someone got access to it they should have access it to, you're not able to monitor for that.  Also doesn't support single sign on through SAML or other methods.  To go through the laundry list I won't eat up too much time on all these, I swear.  Just fun information.  Digital ocean, obviously a big one that's been growing.  Has strong permission models, doesn't have single sign on yet, but to support TOTP.  It's off line.  Two factor.  The log has some that they're starting with -- it's not fully robust or as robust of events that you'd want to get.  Soft layer side, another company lot of people are moving to for cloud services, years ago, obviously you have strong permission models but again some kind of log in coming out but how you get these actual events it's not a lot.
  Then finally Join is the other big infrastructure as a service that everyone has been going to, strong to factor, no single sign in.  These are thing you want to look for when you're kind of selecting where you want to send your stuff in the cloud.
  On the services side, we're looking for the same kind of thing but probably more logging because at that level we are fully trusting the platform, fully trusting the software and we need to see what events are actually there not able to implement our own on the operating system level.
  Obvious office 365 like I said not going to read through all of them, one thing I'm point out the log inside they just started offering -- offered for -- exchange, sorry.  For exchange they offered it through Powershell to be able to moderate.  However just recently rolled out this new management activity API back in April.  Now, it's a nice to see them taking step in the right direction of offering these kind of log in events that everyone can take and monitor it was limited release was focused on a lot of these vendors that were offering the cloud solutions you had to request access to it.  I'm not sure the current state much it today but seems like it's rolling forward as they have list of I think 20 or so partners that actually capture this data.  It's good to see you're able to get that traditional log-in data out of there infrastructure that you would normally have yourself.
  On the Google apps side, again, another strong case similar to the Amazon side that they have grown and adapted, strong permission model, strong two factor, having SAML which is great on the log inside, yes, they have the reports, API log in activity.  I'll go through a little bit of that in a minute here we'll get through the rest of these so we don't eat up too much time.  On the Dropbox side, strong model.  Logging is offered through their audit log, API and point.  For some reason people are going to Dropbox, box also offers log in.  They do offer SAML they offer it by request through your account manager.  So, I don't know that there is an additional charge or offer as feature.  But there's no way to automatically enable it to my knowledge.
  They do also offer log in like I said through kind of a more verbose of all the log in platforms through events API able to get a lot of this information in regards to the files were downloaded, uploaded to that level beyond just somebody connected, somebody logged in that gives you that anomaly data to be able to see, I just saw someone download all of this folder, all of this data what is going on here.  And another strong case Salesforce, but we all know about Salesforce probably by now log-in history which is going to be log-in trail.  List goes on of all thee.  I tried to call out the big ones.  These are the key things I think when you're looking for what you're going to host your cloud services, what you need to look for.  Make sure that you can have unique log ins for every person, not having a shared account.  Depending what services able to take in enable or disable people who have their unique accounts.  Being able to tighten up the permissions instead of just, admin, have fun, able to limit to certain level.  They have two factor or two step.  Authentication.  Whether it be through TOTP which is the standard that does base on time, office line.  Or the SMS which again requires live cell connectivity which I hate, by the way.
  Single sign out.  Wi-Fi on planes and to factor does not mix.  It's not fun.  Single sign on using SAML that is standard.  If you're able to roll authentication back to your side 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 to look for to see far they are in their platform is the capabilities they have on the audit trail side.  What they are providing on log-in perspective.  Now, obviously whenever there's a problem, the industry has jumped to it said, I can fix that.
  They have always had this magic security bullet.  By the way, I've noticed, included some silicon valley stuff, how many people have seen the TV show?   Good, it's not lost on everyone.
  If you haven't seen it, I love it, it's fun, I like my TV shows, this times it's silicon valley, last year it was archer.  Sorry for you fans I still love them.  On the magic bullet side of being able to fix everything, they really come in these five flavors.  Transparent proxy or visible proxy.  Some kind of client end point program,  some level of monitoring through an API or Webhook.  Or proxy.  Identity management that's the buzz word for three years.  And obviously leveraging API 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 have started offering these proxies whether it through encryption or on the web level side.  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.  You are limited to using only the web applications, only API endpoints through the limited subset, so really it breaks a lot of functionality when these transparent proxies.  Vendors will argue both ways.  May vary.  Requires leveraging said proxy for access whether it's behind your fire wall which basically defeats the person of having cloud.  Or having it where you have to have an external end point which again is having cloud all over again just a different kind much cloud on the cloud of the cloud.  Doesn't really solve the problems to my mind.
  Then host level encryption mostly comes to file hosting, provides virtual folder that encrypts the file before it even hits.
  So, this could be in and of itself a 20 minute rant but I'll 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 -- to preserve the function of the application you're leveraging it will do some certain things, need to be able to search, need to be able to sort those are the two key features is searching and sorting what good is cloud application if you break it completely because you encrypted everything you're not able to search for things when what is 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 -- every field, everywhere reference that needs to be seeing the exact same way.  So what you effectively create is a substitution cipher which is basically saying, dog is cat.  Instead of using plain English we see it leverages UTF depending on the support of the individual application, you'll see a bunch of Arabic or Mandarin characters or Japanese characters it's using full character set visible and invisible in order to render with 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.  It's a simple substitution cipher that given enough time, given enough review you can figure out what this jumble bunch much characters is.  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 less than B, C, D, so son, so forth.  The length as well has to remain similar in order to be able to take and say this word is shorter than this word when I do the sort, I'm able to know which is less.
  And be able to reference each character.  So what happens is with these function preserving encryption that support sort you have created a dictionary that you can sort in order of all the crypto data go, okay, this is at the top I'm assume this is A, this next letter is maybe a B, figures it out over time because you have this large set of data that you're able to happen map.
  To 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:  I probably will get some flack for it.  There's a little URL if you're interested in reading up on the agriculture of the DMCA take down this certain vendor for looking at it.  Not just -- other ones as well.  Again product side.  I know I'm running short on time I'm going to speed it up here a little bit if I haven't been going fast enough.  So, on the being able to grab the logs that weep were talking about very dependent on what API provides.  Some cases implement a proxy that they're required to go through without encryption feature set to be able to log all the user activity, but then requires you to come from a certain API.  On the identity management side, obviously being able to bring that in they use SAML to connect to existing database -- user data stores, determine, hey, I'm going to connect, can I connect to radius use that as my store and provide these SAML.  Then on the API side obviously leveraging existing APIs you're insecure in these ten configurations I can see that through the web portal if I had to walk through, okay, thank you.  Cool to give me a little score.  I always like to say, sure, use expensive products works great with large number of users.  You don't have the budget to handle this.  I like to always say, build it yourself, fix it yourself.  Figure out how you can take and make the most with what you have for now.  Obviously if you can afford it you can afford it.  Obviously the basic 101, hard net which is obviously simple.  The key thing I want to point out here is, if you're using some kind of tool chain associated with one of these cloud providers, a lot of them will cache the tokens on the system for a long period of time.  Like I was saying on the heroic side, if you don't log out, you have the forever.  Obviously watch where your code repo is especially using some kind of automated continuous integration or leveraging it for something like chef or puppet.  Make sure that that area is hardened and secure not anyone can come in like I said, then impact all the things down the line.
  Modern integrity is interesting side that I don't think when it comes to cloud enough people do.  Infrastructure is not as easy.  Traditional integrity monitoring handles the actual operating system and the host.
  When it comes to the platform side and software side you really have to rely on the platform side you can obviously script your own thing to check if to see if a page is changed or change to something you've referenced or java script you can script that out as I touched on later on in this list is, building your own cron job to moderate see if there is any difference.  Notifying you that there is, hey, I've noticed my homepage has changed.  I've noticed that this java script library now includes another line.  That's externally referenced.  On the SaaS side there's not really anything you can monitor.  It's not like you can monitor the changes of their code because they're changing all the time.  You have to rely on available APIs on the log inside.  Back to the whole authentication side, implementing single sign on is not as hard as everyone tries to make it out to be unless 100,000 users.  When it comes to implementing SAML there is some existing open source tools that are out there that will let you do it.  Glue is a front end Gui package of -- which is java based.  Also Ruby library that all of the identity providers in it. SAML is a talk in and of itself, so I am sorry if I am covering it very high level. On the SAML side there are different roles and you need to provide the different identity role. The key thing is no matter how you implement single sign on, you need to make sure you have some form of multi factor on that single sign on that you protect those certificates and those keys, and see where the support for those single sign on applications are. In a lot of cases you still have to generate per application passwords, which in some cases —- 
  This provides interesting logging aspect to be able to capture all the log innings on your own time.  But obviously not subsequent action logs.  If you're cloud provider, did I just lose signal they lost signal, good.  No more words.  So, back to the API key side.  Again, with it being distributed across everywhere, it's real easy to build API proxy.  It's a few lines ever code to be able to take and there's a sample up on that tiny URL to build a proxy that you can basically write your own API abstraction layer that says here are my internal API keys I'm going to protect these really tight within this little proxy I'm writing.  Then you can write your own level of source limitations, dynamically provisioned really provide a nice little layer in front of whatever the cloud provider is which may have a more rigid kind of key -- OAF key layer.  Or -- sorry.  Another big thing if you're not able to use single sign on you have to use shared accounts when it comes to two factors for the shared accounts make sure it's enabled if they support TOTP being able to take leverage your own factor because TOTP is open RFC standard that you can get online and log in when someone requests.  Again, very easy to script up and there's Ruby and python and pearl, the TOTP stuff.  Then finally since I am running out of time, is audit, audit, audit, log, log, log.  My last talk was about logging all the things, but we need to start monitoring logging our own activities on these service providers -- or software as a service cloud size.  So, again, it's very largely dependent upon -- one of those things as you select cloud service you need to make sure you focus on when it comes office 365 it's very Powershell focused.  Make sure you have something that is Powershell friendly.  Admin events API is brand new except for the exchange side which has existing  structure. But it works.  Dropbox, box, AWS, Google, few others, they're polling based.  When you build this application you have to poll at regular interval or whatever interval to set, not like Webhook or an event that you're able to say, when this event fires send me notification.
  There are a few platforms that offer but majority do not offer that kind of level.  You need to make sure you are able to have some kind of application to poll at a regular basis.  Send them somewhere you actually monitor or general operate poll alert something that you'll see, holding on to them means nothing unless you follow up on them and quick little script up of that tiny URL for script called stormy the cloud.  Which kind of works.  That is it.  I'm going -- I've been told since I was short on time, I'm going to take questions, that's the exit sign?
  I'll be out there this anyone wants to ask any questions and get text talk in here because I took time to cycle through.  Other than that.  There is my contact information.  Welcome to DEF CON.  Have a great week.