Josh Sokol: Architecting for Security in the Cloud

thank you all for joining me uh welcome uh to beautiful austin texas or i guess you guys are all in calgary or around that area um i was originally planning on being out there for my talk uh earlier this year and i'm super bummed that i couldn't join you all um you know there it's uh something like 22 degrees celsius something like that uh here it's like almost uh 26 degrees about 78 degrees fahrenheit so it's warm and sunny and we don't have any snow um but i still miss it i miss the fact that i can't be there with you guys in person um so i'm sorry about that maybe next year but in the meantime we're gonna go ahead

and do the best that we can with this virtual presentation on architecting for security in the cloud um so let's do this let me see if i can find my there we go um let's start out and i'll tell you a little bit about myself i'm josh sokol i used to be on the owass foundation global board of directors i left probably about four years or so ago i used to run the information security program at national instruments but the real reason why you want to see this talk is because i'm the founder ceo and cesa of simple risk and i did a lot of interesting things when i first started semperus when i first got

off the ground um and we built an entirely cloud cloud-native infrastructure for all of our customers so that's really the intent of this talk is to talk about how that happened now when i talk about the cloud it really depends on the shoes that you're walking in if you're a customer this is synonymous with software as a service but if you're a hosting provider that usually just means somebody else's data set right you don't have to keep the servers in your data center and have the network and things like that you're just leasing space from somebody else and so the challenge that i really ran into here is that my application simpleris was originally built as an on-premise

internal use application at national instruments the company that i work for and later on it was open source and released publicly so that people could run it and the business of simper's hosting uh came about because we had users who didn't want to host it themselves and so in that case the cloud was really leveraged for agility we wanted to be able to do this we wanted to be able to spin servers up really quickly we didn't want to have to buy hardware and things like that but because of the risk and the compliance data that's being hosted in our simplest cloud security ended up being a very big concern so let's take a moment and talk uh real

quickly about our symphorous architecture because that's kind of important here um so simparus is based on uh using whatever web server really you want you can do apache nginx iis it doesn't really matter and the code uh for simplest is written in php so um all the all the stuff there's some java and some things like that um but most of the code is written in php and then it uses a mysql database as the back end now i know what you're thinking you're thinking well the code is written in php so it's completely insecure right we're at a security conference and that's automatically what people think when they hear php so let me tell you a little bit about

that um what uh white hat security very well known in the dynamic application security testing space they do this annual report and they had an interesting quote from the 2015 version i've kind of followed it over the course of time but this basically said at present time we can say that all these aforementioned items language industry organizational size the development process don't matter much and if they do it's only slightly under under very specific conditions so really what they're trying to tell us is that the the things that are affecting the security of a program is really just it's not dependent on the language and white source which is an organization which does kind of

open source analytics and things like that they did a survey uh last year uh where they took the nvd database the national vulnerability database they looked at security advisories github issues um popular open source project issue trackers and what they figured out was that of the 200 plus languages that that database covered um they focused just on open source security vulnerabilities in the seven top languages uh over the past ten years and their goal was to figure out which programming programming languages are the most secure which vulnerabilities are most common in each language and why and a really interesting quote came out of that they said while the game of my programming language is safer than yours

is certainly a fun way to pass time finding the answer will probably not help you create the most innovative or secure software out there so really what they're trying to tell us here is hey it really doesn't matter which language you're using um there's no really one programming language that's better than another it all just bases on the use case what you're trying to do what's your familiarity with a given language things like that and so for me when i started out and was working with php there were a few reasons why i decided to go with php to begin with um the first is because the same code works across lots of different platforms

yeah i showed you that you can use uh apache or nginx or iis it's because php is horrible it works on any of those different platforms and installation is relatively simple uh there's lots of instructions out there in terms of how to install php it's very well supported um and there's lots of documentation for when things aren't that simple so when you do run to issues you know php why doesn't x do y and boom you have a nice list of google results for all the other people who ran into this issue before us and it's pretty simple to to fix and uh probably the biggest reason why i decided php is because frankly i knew php better

than any other language i had done web development using php before that and php for me um was something that i was very familiar with i could write code much much faster and get to the thing that i wanted to do much faster since i knew it so when we're talking about programming languages you know and the things that we're doing really it comes down to generic coding best practices regardless of the language that you're using if you're using c plus plus or java or python or ruby whatever your language of choice is there are some very basic coding best practices that we need to adhere to and so if you look at oauths for example

they have the os top 10. some of the things that start to come out of there are things like input validation making sure that when somebody is entering data especially if it's a user an end user uh that we are validating the inputs and verifying that they are what we expect them to be um you should put a quote in a field that's supposed to represent a zip code or an address right um things like output encoding to prevent cross-site scripting making sure that we're taking that little uh less than character the greater than character and encoding that into ampersand lt semicolon right and then uh hash and salt data used only for comparison so this is

speaking specifically about passwords we want to make sure that when we're doing passwords for our application you know that we are not storing the actual passwords in the database we're hashing the password uh along with assault and then we don't have to actually store the password when somebody goes and logs in we just do that same thing with what they logged in with and say does this match what we expect um using things like industry standard crypto algorithms and not rolling your own and then always checking for authentication and authorization so symporus had the benefit of starting from nothing and obviously not everybody has that luxury but even with that advantage we're still continually evolving

and we're still constantly finding newer and better ways of doing things but in this presentation really what we're going to do is we're going to build our defenses from the inside out so picture that green field that everybody wants and we get to start from there so in our case where we start with is our secure web application and so we've done the things that we expected to do in order to write the secure code um and now our first challenge is really ensuring that we stay up to date with the latest code and that we avoid number nine on the os top 10 which is using components with known vulnerabilities so how do we keep the application update

and really the answer here for us is twofold the first is we want to keep the application in a github repo uh you can use any sort of source code versioning system it doesn't have to be github but in our case that's what we use um and there's a few reasons for that the first is because you have access control over who can push out changes right only certain people can check code into that repository and even better if somebody does check something into there we're able to audit who did it and what they did as well as when and worst case scenario of what they did was bad we can roll back those changes very

very easily we just you know right click and roll back and boom that that thing was undone so using that kind of source code versioning the source code repository makes it really easy to keep that application updated and make those changes if you need to the second piece is really around the deployment and that's using automation tools to check for updates and deploy in our case we use chef but if you want to use salt stack or puppet or whatever it doesn't matter right there's all these different tools to do it um and the idea here is that your servers will know when new code is made available and that code automatically gets rolled out to

the servers and having that kind of infrastructure as code automation process to roll those changes out means that our deployment mistakes the risk of having deployment mistakes are minimized any time that you start to have individuals who are working off a checklist or things like that things will get missed and it will not be consistent but code is consistent code says every time i do this deploy this is what i do this is where i get the code from this is where i write it to and so on uh it also ensures that server configurations are consistent so we can use shaft or whatever to update our configurations and make sure those are right and you can even have different dev test

prod environments and different configurations depending on where you're operating so at this point we've kind of revised our architecture our architecture looks something like this we've got still got that secure web application in my case simple risk uh we've got our github repo which is where the code gets pulled from and then we now have an orchestration server uh which is the thing that's kind of making all the automated things happen so now we have uh servers right and at that point we have to start thinking about okay how do we secure our servers how do we make this work and so when it comes to hardening the servers there's some basic things that we need to follow

um one is you can look at the cis guidelines center for internet security there's lots of guidelines that they have their baselines for secure systems and things like that but some of the basics come down to patching making sure that you are routinely patching the operating system in applications uh and if you're in the aws cloud they have a really cool feature called uh system manager patch manager which will help you to identify um patches that are missing on systems it will help you to apply those patches and push them out in a consistent fashion if you don't you can use that automation tool you can use your shaft for puppet and you can automatically do

updates via that tool as well um obviously turning off unnecessary services things that you don't need you know we've heard for years and years that hey you shouldn't have telnet writing on a server or you know she shouldn't be hosting uh email server on a server that's running a web server whatever things like that we want to make sure that we only have the services necessary for our application and then the last thing here is really you know how do we kind of shore up the system and that's enabling the host space firewall with default deny rules so we're basically saying hey i'm gonna i realize there's probably network-based firewalls those fires firewalls are saying hey you can only

talk to this app via port 80 and 443 only http and https but uh we also want to have a host-based firewall and i'll tell you a short story about why this is critically important um we had uh when i worked at ni we had a system that was exposed to the public internet uh accidentally um it was a system that controlled our antivirus handled all this the um deployments and things like that of our antivirus solution and what happened was uh the network team was troubleshooting and they dropped the firewall just to do the troubleshooting and when they dropped the firewall the system got accidentally exposed there was no backup there was no defense

in depth so without that additional host-based firewall that system ended up being compromised somebody was able to figure out it had default credentials they logged into it uh unfortunately they weren't able to figure out what exactly that system was for because have they been able to figure that out they could have deployed code to almost every system in our environment so fortunately we uh we skated past that really really bad thing but it should be a constant reminder to you that you make sure that you employ those defense and depth tactics in terms of administering your servers there's a couple things that you can do here one i highly recommend using a bastion hose bastion hosts are easy you can basically

create a server this is the only server we're going to use to talk to all of our other servers you can use firewalls to restrict the source for all inbound ssh traffic to that server as well as to all the other servers so all of your other servers are the only uh they will only communicate with that bastion host and then that bastion host really ends up being the only publicly accessible administrative airfares so what that allows you to do is to focus your time focus your efforts in terms of security on that system that doesn't mean we can completely ignore the other stuff mind you but when we focus our attention we focus it on that bastion host

and we make sure that's always up to date we're always installing the patches yeah we're monitoring the logs on that server and things like that uh you can further lock that down via vpn so you have to vpn in in order to talk to the vatican host in order to talk to those other systems i you should disable route access you should restrict sudo privileges on there but ultimately you're creating one system as your focus point and you're kind of uh bottlenecking in the traffic to go through that um now this doesn't mean that people can't talk to your application outside that bastion hose that connectivity still exists we're purely talking about the administration side of things

now the other thing that we have here is aws if you're in the amazon cloud you have something called session manager and this is kind of really super cool uh hotness probably within the last year or so um they created this system where they effectively proxy your ssh section sessions through aws and the result of this is you don't have to have publicly accessible interfaces you only connect through session manager on your local system you just install the aws tools you put your uh you install the aws client you install your key into there and then as long as the iam functionality is configured properly if your user has rights it will be able to connect to that system

if it doesn't it won't so now you're able to get to this point where you're able to use identity and access management in order to control access to all of your different systems and you can even take that step further and create groups so certain users have access to certain systems while they don't have access to others really really cool so in any case our architecture at this point uh we've now added this bastion host or aws session manager and that is the ssh access to this system the next piece we really need to talk about because symposium is an application that uses a database is securing the database how do we do that and

there's a few pieces that we kind of fit into here um one is using nav database security so in the case of mysql or really any database for that matter we want to use long random passwords for our database users we want to make sure that these aren't things that could be brute force um also using least privilege for the database and this is something that owasp hammers on and other organizations will talk about quite a bit um you know the idea of least privilege making sure that you have only the permissions that you need in order to do your job and you don't give it any more than that so um when you do a sim course install

as an example we'll use the root account to create a new user that's the simplest user that has only the permissions that semperus needs nothing more than that so we try and get down to that least privileged approach and the other thing that you can do here is you can restrict the host for the user to only the application servers and what this does is it basically restricts that path of connectivity to the database so that only those app servers the ones that are running the sim force application are able to connect to the database on the backend now the other piece here is aws and if you're using aws or azure or whatever um there's usually

some kind of cloud-based security that you can apply here as well and so in that case you have things like security groups and you can create inbound rules that also say only the application servers can communicate with the database now realize there's redundancy here right because we already applied our host based access at the native database level but that's kind of the idea we want to create defense in depth so that there aren't situations where one control fails now the whole system is compromised now the other thing that we want to do here is not have a publicly accessible database um i believe that's the default configuration it won't make it publicly accessible but realize that if you say yes i want

to give this database an ip address and i want it to be public that's exactly what happens which means the attackers on the internet can try and compromise it if you don't have it configured properly things like that bad things can and will happen so our architecture has changed a little bit we now have introduced a database and we have a mysql connectivity between the application server and that database now i want to push the pause button on our architecture for just a moment um because i think we need to talk about a fundamental concept in evaluating our system security and that concept is called attack surface so the attack surface is the sum of the different points or

attack vectors where an unauthorized user aka the attacker can try to enter data or extract data from an environment so i like to think about attack surface and i feel like there's no better way to illustrate the attack surface than a castle right you look at a castle and you look at this castle and the question is how secure is this castle and the answer is not very right when i look at this castle i can break a window i can kick in the door i can climb up onto the roof there's probably plenty of places for me to get foothold on this guy um i don't see any cameras out there there's no moats right you guys get the

idea here and our goal with information security should always be to minimize the attack surface how do we shrink that attack surface so that there's as few places that the attacker can attack us as possible so let's take that same castle and let's add some walls right we put some big tall walls around it and we add some towers and we put a gate there with a drawbridge our castle is now slightly more secure right we now have our castle seeing in the middle you could probably still kick in a door or break a window maybe there's still not cameras on it but at least now we have walls around it right we have some additional

mechanism of defense and then we go and we go all right well let's put some dudes at the top of these uh these towers and those guys will be archers they'll have arrows um you know they'll be looking for threats that are coming our way right we've now stepped up our security slightly and then we have boiling oil right we put those at the front gate so that when the guys come to try and kick down our door um we're gonna pour some boiling oil on those guys um and make them suffer right and then we go and we put a moat and you know we have a big thing of water all the way

around our castle gates so that anybody who's trying to get to it they basically have to swim up to it and they're not in a very comfortable position to breach anything at that point and then you know the mode is full of alligators and freaking sharks with freaking laser beams right you guys get the idea the goal here is to minimize the attack surface right all right so now we can push play and resume so the question right now is what is our current attack surface and we've since taken this approach a step further we've laid out things like subnets for public private insensitive um we've got the bastion host which was moved into an isolated vpc

with access into another dedicated vpc environment and we can do things like monitoring for traffic that transcends both of the vpcs so we've taken this quite a bit further than that since i created this initial diagram but you get the idea so when we look at this we have all the stuff that we did before and that's all sitting inside of our virtual private cloud and you can think of vpc as like a dedicated network here and then we have some stuff that's outside of that right our amazon cloud console is not within our vpc and so if somebody can compromise that system if they get my password um if you use mfa if they figure out how to

breach that whatever they can get to my amazon console and then access those systems same thing with github if i'm doing i if i'm grabbing my code and pulling into my application from github now that becomes a attack surface as well if somebody can compromise that they can uh they can create problems for me but our attack surface right now is actually pretty small right it's just those two things and there's some things that we can do to prevent that which we'll talk about more later so our next steps here is really going to be we need to enable access for our customers they need to be able to use the application uh so you know security if it's just inside

of a brick vault or something like that it's not gonna be very useful um and then we also need to enable access for administrators there's gonna be things that they need to do on these systems so with that uh our attack surface widens a little bit right we now have a load balancer that acts as a proxy this allows for our interior architecture so we can actually scale out have multiple different application servers that are communicating with the database uh we still have those same other systems our rds for our amazon database we've got our aws session manager the bachelor host we've got our orchestration server but if you look at the lines that go from

the red into the blue this is effectively our attack surface we have the github thing we have the amazon console and we now have the remote user and the remote user is coming from the internet and we have that http https to the load balancer we still have to worry about that that's a potential attack surface and the ssh access um which hopefully we can cut off using something like vpn or that aws session manager if not we still have to worry about that connectivity to the bastion house so when we think about attack vectors the how somebody would get in we can break this down to a few things the first is insider access which would compromise

our confidentiality our integrity and valuability the second one is an attacker compromising amazon and now they make some configuration changes to the environment maybe they're able to access systems via the console stop systems whatever we have the situation where an attacker can compromise github and they can push malicious code into the environment we have the potential for an attacker to find a vulnerability in the application in order to gain access to the environment that's that ad443 connectivity and then we have the attacker finds a way to access the bastion hosts so because we've narrowed our attack surface we've also narrowed the number of attack vectors and when we have a narrow number of attack vectors now we can actually plan

our mitigations for each of these different attack factors so in this case let's take the first one the insider threat and let's look at that how can we fix insider threat well the first thing is we can make sure that our insiders are relatively trusted right we can do background checks and make sure that you know there aren't any financial issues that would cause them to be subject to bribery uh we can do things like limiting those who have access i shouldn't give everybody not all of my employees should have access to this environment just the people that i trust just the people where that's their role to do those things in terms of amazon again we should be

limiting those who have access i shouldn't give amazon access to everybody there's no reason my sales and marketing team need access to my amazon console we should have role-based functional authorization so if there are users who need access to a certain set of functionality maybe they're helping to administer servers they probably don't need access to my database they probably don't need access to my dns so we can have kind of role-based access ensuring that we have long and random passwords and setting the requirements in aws to enforce as such and then lastly requiring multi-factor authentication this is a security conference you all know what happens when you don't have mfa on a device um we had a big issue a

while back at ni where um people were getting phished and they would end up getting the password they'd be able to log in see their email things like that that completely stopped as soon as we turned on mfa because now even though they got the password which sucks right you still have to change passwords and things like that they weren't able to access the systems and that's really what mattered to us so rotate the password move on in terms of github same kind of thing we want to limit those who have access we want to ensure long and random password requirements require multi-factor and then the last one here audit changes frequently audit plays a big role in

security not because it's going to stop the compromise but because it's going to help us to detect it so when we're looking we want to look for things that go on understand the changes that are being committed and make sure that they're appropriate and you can do this with things like pull requests as an example where somebody submits a request somebody reviews the code and then says yes that looks good let's go ahead and push that out there before we actually roll things live we also have the web application as an attack factor so this is um you know in my case the simplest application or wherever you guys are running and there's a few things that we can do

here to help the first is https by default um so redirecting our http to https that's obviously going to help to sure up the confidentiality of our connectivity making sure that people aren't going to see things that are going um across like our cookies as an example the next one is securing the https configuration so not all https is the same uh if you're using things like you know tls 1.1 or ssl v2 or whatever those are going to be worse off than if you're using newer versions of tls like 1.2 or 1.3 um so we want to make sure that we're using real ssl certificates not self-signed certificates um those are cheap or free in the case of

let's encrypt um i would also recommend if you're trying to do internal applications um we use something called ssl mate uh it runs about 100 bucks a month for 100 ssl certificates they're let's encrypt certificates they rotate every three days and it's a great way to make sure that you can run those and it uses dns as the authentication mechanism so you can actually have internal uh a domain internal certificates deployed to internal servers using this tool ssl may is what it's called um also we want to make sure that we're using tls 1.2 or um pretty soon it's going to be tls1.3 with strong ciphers enabled and honoring the cipher order so we want

to make sure that we're selecting the better protocols first the more secure protocols first before we have to downgrade to something else making sure that we have things like intrusion prevention or web application firewalls and then just general application security best practices so knowing our oauths top 10 understanding how that factors into our application making sure we're doing the input validations and things like that that i talked about earlier and then the last attack vector here is remote access remote access is basically um you know how somebody is going to get into the environment and so for here we want to use long and random passwords for our ssh users who want to use multi-factor

authentication for the ssh users um key based authentication helps as well so if you have a public private key pair you have to have that key in order to access it that's in that positive um we want to restrict what ip ranges are allowed to talk to our bastion host um or our vpn or whatever so we can kind of narrow in uh narrow that down to just these people are able to access this and then disable ssh unless you're vpn into the vpc or that aws session manager is pretty darn cool in this case because you're able to bypass a lot of this stuff you can still use mfa in it and things like that

but it makes this whole process a lot easier so with that what recommendation recommendations do i have for you guys um the first thing is determine what is or is not in scope right you're gonna have a big application there's gonna be lots of things that kind of follow around it figure out what all the things are that are in scope for your application and the things that are out of scope or at least things that you don't control the security of the next piece is control creating a data flow diagram so all those charts that i showed you along the way where i said this flows into this here's the the protocol that's using

things like that that's a data flow diagram and data flow diagrams are great ways to kind of understand how your application works what are the components of the application how data flows from one thing into the next it's great when you're trying to troubleshoot when systems are down um understanding how those components kind of fit together but it's also great from a threat modeling perspective we want to be able to look at our application and understand what are the things that are working what are the things that aren't working where our threats could come from and then how to mitigate those which goes to the next piece which is identifying the attack surface what are all the places where somebody

could attack that data flow and then what are the threat vectors who is going to attack that and how are they going to attack that attack surface that is available and then the last bit here is planning mitigations to reduce the risk of the threat so anytime we've identified threats to our application we want to make sure that we've actually gone through um and we have mitigations in place in order to reduce uh those risks so with that that is the end of the talk um let me give me a sec so i can flop over to my browser and hopefully i can find you guys in here there we go um so with that let's see

does anybody have questions um i see a couple hellos hey is in the chat i don't see any questions at the moment um let's see i'll give you guys a few seconds to throw stuff out there if you have anything no nothing all right so um if you guys have any questions you're more than welcome to reach out to me on twitter i'm at josh sokol um if you wanna send me an email i'm josh at simplerisk.com um oh we got another question popping up um the blog by the way so if you go to simcourse.com blog i post all sorts of stuff on there usually it's uh relating to risk management things like that

so we got one question here um they say my question is related to multi-factor authentication now sms is not that strong what's the best way um yeah so i kind of interesting note here and this may be what uh what they're referring to um there was a article that i read not too long ago where was talking about um a cryptocurrency and somebody i believe they were in the uk uh they had literally millions of dollars of uh crypto in a wallet their wallet was protected via mfa but they were using sms as the mfa mechanism and an attacker actually figured out um how to clone uh their cell phone so that they could intercept

that text message that they were using for mfa uh and they were actually able to log in and transfer the crypto assets and if you know anything about bitcoin and things like that um you uh once the money's gone it's gone um so in this particular situation there's nothing that they could do about it but to um the the person's point and to their question there's lots of other ways to do multi-factor authentication so ub keys are awesome um if you get a uv key you basically pop it in it's like a hardware token you can push the button um and then it basically puts your password into there it will even do seating and things like that so your

the the token will actually be constantly changing um you can use uh hardware mfa so you can use rsa tokens um those are pretty good and you know in all honesty even putting things on your phone um like a uh google authenticator um i really like the duo uh one um they work really really well uh in terms of doing that mfa and they don't rely on those kind of outside protocols they're seed based so you have a seed that the server has and then that seed is basically what keeps it in sync with it so um any of those kind of tokens um basically bring you away from those issues with sms which is really the

ability to clone it and things like that um and then also you know making sure that you have multiple factors of authentication so having strong passwords and things like that um yeah making sure you have that uh let's see what darcy says here uh strong element phase the classical definition factors mean something only you have are no um and yeah that that uh really goes to the point with sms if i can clone your cell signal if i can be you um then i am you for all intents and purposes and i can uh attack you in that way um anything that doesn't meet strong isn't suitable for valuable assets absolutely right if we consider sms to

not be strong because it can be intact in that fashion um that certainly isn't something that we want to use for for example millions of dollars of cryptocurrency so we should understand when we're doing these things um there's uh there's mfa and then there's strong mfa um and gen generally uh sms messages aren't considered strong mfa um slava asks can you guys have a copy of my presentation absolutely i'm happy to share my presentation um i'll uh i'll get with the organizers actually what i'll do um i will keep this session open i think i can do that and if you give me a couple minutes um i will drop a link to my dropbox

where i have this presentation you guys can download it from there so unless if there are other questions um let's see one last question related vpn if all my it infrastructure is on the cloud do i need a vpn policy is it applicable um so i would say yes um you should have policies for pretty much anything in your environment because policies are basically setting these standards for what you expect from people um you know are there things that you want them to do on the vpn things that you don't want them to do on the vpn um can they use the vpn for non-corporate traffic things like that um so you know always having some sort

of a policy on vpn uh is a great idea um and that goes for you know pretty much anything we should have mfa policies and password policies uh information security policies things like that um so hopefully that answered your question um as i don't know if that relates directly to um the talk or if that was more general question but hopefully that kind of gives you the answer that you're looking for so uh everybody else thank you so much for joining me really appreciate it