Cassandra Young - The Complete Noobs Guide to Cloud Security

[Music]

hello and welcome to the complete noob's guide to cloud security i'm the noob or maybe i'm the person that's going to give you the complete noob a guide to cloud security or maybe i'm going to give you the noob a complete guide to cloud security either way that's me uh so i am currently an o365 an azure assisted man who dabbles in security uh and because i'm a total glutton for punishment i'm also a part-time grad student in computer science which let me tell you great insights no spare time i also moonlight as an organizer for the defcon village blue team village we put on a lot of blue team-related security talks workshops we appeared at defcon

gray hat and a number of other conferences and run small programs as well very active in that community i consider myself a jack of all trades in that i like to dabble in a lot of different things and in some ways i'm a mile wide and an inch deep and in some areas i'm about two miles deep in an inch wide if that makes any sense at all um i have a lot of hobbies most of which involve heavy investments of money that i don't really have quite yet and quarantine has given me a good opportunity to explore a few things like woodworking and jigsaw puzzles and baking and also in my spare time a little side

of cloud security so a little bit of background that i think is relevant to this talk i came from an interesting background i originally dabbled in uh actually in law so i was a legal secretary for a number of years and then kind of accidentally wound up kind of dropping into it as an av person and a help desk support specialist before moving into desktop support as well and then eventually into my current job as a sysadmin so i consider myself security adjacent and being an o365 especially gives me a good perspective on one application of the cloud although we won't be really talking about o365 today so on the slide i've left all my

relevant information i'm stalkable everywhere i've actually now completely doxed myself on the internet uh this is the first time i've mentioned my real name in a talk where i'm using my handle as well so it's kind of a fun first for me so without too much further due i want to talk about some fundamentals of cloud security and i'll be quite honest coming up with this was quite a haul there's a lot to cover and there's a lot of things that could be considered fundamentals but i'm going to break this down into kind of a a couple key things to keep in mind before i go into the actual fundamentals in terms of the technical aspects of in this talk

um so cloud services are not uh i'll say that they're not put together in exactly the same way as the various services and and technical um elements of your normal it infrastructure so i like to think of this as components based and when you move into cloud security you have to change your mindset a bit to actually accommodate the idea that cloud services are components that you can tie together with internal apis uh and that stitching together components is kind of a theme that we'll keep coming back to and they'll pop up in this talk um one major suggestion i have for anyone that's interested in getting into cloud security learn some code so coding is key

because in the cloud infrastructure management and all the these services that you're using to replace on-prem infrastructure they're kind of getting closer to application security in especially since they're using uh apis in that component methodology so inevitably you might wind up having to actually collaborate with your dev team and when that happens it's incredibly helpful to have at least a base understanding and code and that will also later feed into any exploration that you do uh of things like automation and orchestration which is something we'll touch on at the very very end of this talk it's a not necessarily a noobs kind of topic uh and the last thing that i really want to stress

and i will continue to stress that every opportunity is to be flexible um the change the cloud changes all the time and everything that you put in place in the cloud is not a set it or forget it uh thing so when you move to the cloud your infrastructure your applications require constant re-evaluation the cloud will change whether you're ready for it or not so be prepared to lose a little bit of control to adapt your mindset to accommodate new ideas new projects and hit last lastly definitely not least today actually was a great day to to record this talk because we wound up having a pretty massive ews outage um and that was the outage of us east

one impacted a lot of services and key enough uh one person who posted on twitter that was actually not affected by this had a replication in a different region so you kind of have to prepare for the inevitability that things will be outside your control but there are ways that you can actually adapt to them as well so keep that flexibility in mind it's going to be incredibly important so the next thing that i want to talk about is probably the underpinning of any cloud security talk i've kind of jokingly said that you can't have a cloud security talk without talking about the shared responsibility model and this is basically the idea behind this is

in the cloud you have varying levels of accessibility and control so if you want to take your your normal defense and depth approach and apply it to layers you have to have an understanding of the fact that different services uh will give you these differing levels of access and control so your decoupled components in essence are going to create this this new perimeter so if you look at the this graph this is actually microsoft's graph which i actually like better than aws's but don't tell them you can kind of see that the level of access that you have to something the lower it is the more you're relying on the cloud to take care of certain

things for you so your cloud provider may cover the bulk if not almost the entirety of infrastructure you are always responsible for your data whatever data you put in any cloud service is your responsibility to protect in whatever way is accessible to you and again this comes back to that uh having that flexible mindset in that you know when you're approaching a new a new service or resource that you have not used before you need to be prepared to evaluate where in this spectrum it actually falls

so i'm going to give a a little example that i'm going to use a couple times i'm a huge star trek nerd that's my enterprise badge from def con it's really cool it has blinky lights i love star trek so i was trying to come up with some way to actually take some of these concepts and translate them into something that's a little bit more accessible so let's say we have the star trek swag station nine i'm i'm a consumer i love star trek i want to buy some merch so we are here we have a very simple architecture for a web store um and as you can see we have like some user interface

probably should just be like the actual front end of the website but i'll call the user interface here um so i want to take this i'm going to apply it to that shared responsibility model and the um the infrastructure as a service platform as a service software as a service kinds of levels that were described in that shared responsibility model so i'll start with ec2 ec2 is basically a vm um you can actually manage the os of an ec2 instance and you should that is your responsibility so this actually falls in the infrastructure as a service kind of category uh and then the next thing would be these rds databases that's aws's relational database services so

let's say we have a customer database and an hr database so that's kind of platform as a service it's not a service where you need to be concerned about managing the operating system so that's where that falls and then lastly we have a lambda which is a serverless function function as a service wasn't really described in that first shared responsibility um diagram but it kind of falls between software as a service and platform as a service it's kind of how it's described it's a little uh nebulous so you have to keep in mind to be flexible even about how services are labeled but the idea is in a lambda function you manage the code you manage what

libraries you import but you have very limited control over anything else so that's where that falls in that spectrum now the next pretty large area that i'm going to cover is going to be identity and access management and if you know anything about security you'll understand how important this is so in aws and this is somewhat similar to other cloud providers as well i originally would have loved to put in a little quick discussion about um role-based access control in azure but i unfortunately it was just a lot to put in here so i decided to skip it um but essentially the individual element of this is a user or a service um any service like an ec2 instance can

adopt but it kind of can be its own iem user if you will uh so thinking a little bit more big picture i'm going to say that you can use ibm users for quite a large set of functions across an account in aws you should be configuring anyone who has access to your account as an iem user so if you know the the basic idea of you know lock down your root account and throw away the key same thing applies in an aws environment so you want to have iem users be the primary way that you access anything to do with the account billing all the way down to a user who's using or managing you know a subset of

instances for example so you use iam users primarily for access and you want to apply the principle of least privilege so let's take a look at this graph or this little i don't even know what to call it a little happy diagram i'm going to use the um the analogy of wearing a cape that's what those little triangle things are supposed to be i don't have the best online drawing skills so bear with me so essentially in aws a user or a service adopts a role or assumes a role and these roles you can you can let a user assume more than one role sometimes you want multiple roles so that one user has access to a few

different roles but a different user has access to a different subset of those roles and so on and so forth so if a role is a cape there's something attached to it that's called a policy and the policy lays out in pretty pretty good amount of detail what permissions that user has to do anything and you can get very granular with this and you absolutely should so the the policy is attached to the role in this case you know maybe like a permission slip is attached to the cape the user puts on the cape the user assumes the role goes to a service and that service basically determines whether or not that user is supposed to be doing the thing that

they're trying to do so the best example of this is just to look at the code itself and this is json like i mentioned you should be getting used to code you should also be getting used to json and also yaml that's maybe we'll touch on that a little bit more later um but basically this lays out the permissions that whatever user has that they if they assume this role they have these permissions and you also notice there is resource star do not do this this is bad do not do not do it back away zero of ten do not recommend so that's that's a whole other conversation but let's take a look at this how this

actually applies uh to our swag station nine i'm only going to look at a quick subset of this so first off i want to buy a batlift because i'm a star trek nerd let's face it so my ec2 instance is going to assume a role in order to trigger the lambda that processes my payment so it has a role that specifies permissions to do that exact function on that exact resource and then the lambda returns a result great ec2 assumes another role to save the result to the database and there you go that is my that's my purchase and that's what that looks like so let's go back to how star is bad star is always bad

this is like a tentative of cyber security so in theory i'm actually going to just use the role from the ec2 service to access the customer database maybe i want to save my payment information well in practice if i have star and there are no other permissions boundaries set up i can also access the hr database that's obviously a no-go so putting that aside for just a moment well we'll probably come back to that at some point especially the idea of star and all of that um i would do want to touch on networking which is another important topic so aws breaks out uh regions like i mentioned earlier it was the u.s east uh one that went down so you probably

should be using a little bit more segmentation than just region um but essentially you have a region and that is where an environment lives and then after that you have availability zones and this essentially is what it sounds like um it's intended to be somewhat of a failover and also provides a little bit of extra perimeter and then you have a vpc that spans availability zones but is uh limited to your specific region whichever one you're using it and then beyond that you have public and private subnets and i'll talk a little bit more about this those in a second um so one thing i want to point out here is i actually talked to a good friend of

mine who's a network engineer and i was asking him about what problems he sees with uh when people are moving on-prem infrastructure into the cloud and the first thing he said is that simple is better so complexity in the cloud in networking does not necessarily mean it's more secure so if you look at this basic diagram this is kind of the root of of what you want to know to manage uh instances but you there's a lot of other options but you don't want to get too complicated with it especially when you're moving from on-prem to the cloud and the other thing he said is that do not expect to reproduce your on-prem architecture in the cloud

this is software-defined networking it's not going to work exactly the same it's also not going to work the same between aws gcp google cloud compute google cloud platform and azure they all work differently so you use vpcs and accounts as boundaries in our sample architecture this means that by putting our internal hr application in its database in one vpc and our public facing app in a different one we've implemented a little bit of segmentation there which is good and a private subnet is basically set up so that there's no direct route to reach the internet from that whatever resource is in that subnet so in this case our customer database only needs to talk to the other internal

elements for example in this case the web server that is running the rest of the application and then the public subnet contains resources that actually do need to communicate to the outside world so we have a third party payment processing service that our lambda uses and then we have what i call the user interface but realistically it's just the um the end result being returned to the user themselves so another important aspect of vpcs and networking and resource segmentation to understand that's specific to aws is going to be security groups a very very very important concept to keep in mind as well so security groups span all availability zones into vpc so let's say i have multiple resources

in multiple availability zones because i want things to fail over and i want that redundancy i can actually put both of my ec2s in in a security group and then both of my databases in a different security group and this is probably is not the most accurate example here but i i named one db group it's actually the ec2 instances that need to access the database they need to send information so my security group b my where my database actually live are set up to only accept connections from other of those ec2 resources in that security group and that's definitely a solid way to implement uh resource segmentation and a bit of a perimeter as well

and it's also important to note that for vpcs security groups and these resource segmentation tools you can actually use tags and that's something that's highly recommended that you do it's a not only a way to track but also to set conditions and limit what you can do using those policies that you attach to roles so the next section i'm going to talk about is data protection um this is a huge area i mean there is just so much that we could potentially cover in this so i'm going to try to kind of keep it a little bit higher level um essentially you should always encrypt your data you should encrypt your data and transit you should especially pay attention to

encrypting any personally identifiable information um and aws has uh a couple different ways that they let you implement this uh so going back to the idea of um being flexible and thinking of com in components and um looking at things through the shared responsibility model there can be some areas in aws where you're allowed to do more than others so if you notice at the bottom there's the infrastructures of service ec2 accepts both http and https traffic um and defaults to not encrypt not actually to be encrypted these are options that you can set you have a lot more control in this area than you do for example with lambda which actually requires https only traffic

and encrypts its environment variables there's no permanent storage in lambda so there's only ram storage and that's why that's noted there so this is a specific example uh for s3 buckets um i could probably go off on a little rampage about s3 buckets but i'll go ahead and save that for a little bit later maybe but you have a couple different encryption types so aws gives you the option to let them manage everything uh they give you the option to um to actually let to do your own uh encryption where that you manage the keys but they manage the actual encryption part so there are a couple different options they change a little bit for each

service aws also offers its own key management service kms it does come at an extra charge though so you always want to make sure to to be aware of that before going whole hog and deciding to use kms for everything and actually before i move on one thing i do want to point out this graphic here is an example of envelope encryption so this example is specific to s3 but essentially what it's doing is using a master key to encrypt a data key and that data those data keys are actually rotated um as well by aws and it actually stores the data key the encrypted data key with the encrypted data so you need the master

key to unlock the data key to unlock the data so it's it's kind of an interesting system like again there's a lot to go into here so i'm going to try to keep that as uh as brief as possible as can be possible for this expanse of the talk anyways uh and then one final note i want to make about data protection before moving into um into a couple other sections this talk so i am not normally the kind of presenter that gives you a wall of text this is not something that you should be reading and writing uh furious notes for really what i want to get across here is that compliance is always your responsibility

and cloud providers usually offer some amount of hipaa compliance in that they are ready to be hipaa compliant but in order to actually be hipaa compliant you need a business agreement uh with that company before doing so they have all the controls in place and for most services as long as you configure according to what hipaa requires and have a business agreement then you would be hypocompliant so for every service that you look through it's important to keep in mind that hipaa compliance actually varies across services and that's absolutely something you should should research before just saying oh you know azure is hipaa compliant or aws is so it's just one extra thing to keep in

mind if you're someone who works with compliance on a regular basis and then the next big area that i'm going to tackle is visibility and this uh comes down to um logging and monitoring all right i mostly do panels so i'm not used to talking in one straight go it's quite fun actually so i hope you had time to read this slide a little bit and uh and to be honest if you're if you're looking at this and you've dealt with any amount of logging whether in the cloud or not there are probably a couple things that you recognize here so visibility applies to applications to networks you can approach it from an event perspective intrusion detection

also from the perspective of analyzing behavior over time so you always want to consider what your objectives are before deciding what tools you're trying to use whether that be log collector sims um you can incorporate cosby's with cloud vendors as well so there are quite a few challenges here um i've actually had full panels just talking about logs and we we definitely touched on some challenges in the cloud so one of the main ones is that log formats can be inconsistent by research by resource especially when you have a mix of on-prem architecture cloud then you get into multi-cloud where you have log sources from multiple different cloud providers format is is going to be an issue and

trying to normalize that is it's a huge challenge um completeness varies by service aws especially has a you know a lot of new services coming out and at times they they don't default to um being as complete as you would hope and then the last of the challenges is actually correlating logs across multiple services so we'll briefly touch on microservices a little bit later in this talk but when we're talking about components-based architecture when we're talking about you know trying to create infrastructure that crosses between different services so in our example we have ec2 we have you know lambda we have rds correlating logs across all of those different components is it's a challenge and i can't tell you

that i have exactly the answer for it quite yet but it's definitely something to keep in mind um so a couple of approaches i thought about this and this is more of a thought process than a technical focus so the first thing is to actually analyze what you have collect logs look at them figure out what the new normal is the once you have a baseline for what normal behavior looks like it's a lot easier to go ahead and filter and figure out what is actually important and then the next thing to do is expand on that take your what you know as good behavior from your limited set of sources and add something more you know pull in

your um pull in on prem a little bit more or or try to start that correlation process and another note i want to make about this is you want to basically look at log sources from every layer you want to have logs for billing you want to have logs for any top level account use all the way down to the resource to the os if you can get to it so logging and monitoring the cloud doesn't end at api calls over to ec2 it also should include logs from the os itself because you still have control over that and then the last approach for that is reassess based on your needs fine tune it adapt it this goes right

back to flexibility you know cloud providers add features all the time and while that's great it requires some amount of kind of keeping up with what those changes are and what they can add and also what they can break in your infrastructure um you know if you need a third-party software to help manage those that reassessment is the time to look into it and figure out if it's right for your needs and you can also use tools in the cloud like like tagging to make your log collection analysis better oops right that's not what i wanted to do all right so let's talk a little bit more about some blogging stuff in aws um pretty much any cloud security

talk you're ever going to go to at least at a fairly introductory level is going to talk about cloudtrail and it's going to talk about cloudwatch if those are not addressed during a pretty basic cloud security talk i would be extremely surprised i'm also going to throw in there vpc flow logs because if you're interested in in that networking side of things it's a great thing to keep an eye on so all aws services and resources communicate with each other via api so you use cloud cloudtrail to log those um those calls um cloudtrail defaults on for many services but not all so whatever you're using you want to make sure that you understand what it is

doing and what is not it's also highly configurable so you can add a lot to it uh including if we go back to that that you know learning code the boto 2 library is a python sdk for aws you can actually incorporate extra logging and build it right into cloudtrail there is the option to do that this works really well for lambda you can basically include that while you're actually executing a lambda function which is pretty cool um cloud shell defaults storage to s3 but you can also feed it into cloudwatch and cloudwatch you can actually use an api with as well uh so you can group by services resources um group logs across regions

you can use tags um there's a lot of other really cool things that you can do with it um so uh for vpc flow logs um this basically is going to log any behavior from network interfaces which can be attached to any resources um and it's not just for use within a specific vpc but other services i think rds is one of them actually lets you track the network interfaces using vpc flow logs as well and again you can use tagging with this which is pretty cool and then the last one and we will touch on this a little bit more as well is you can monitor using cloudwatch so you can collect data you can analyze

there's some pretty cool dashboards you can use insights this is where you would build out alerting i found it a little bit a little bit janky to work with at first it takes some getting used to and it can be a little bit limited in what it can track but the nice thing is if you're able to build something like a metric filter you can essentially have it automatically you know kick off an alert um i think one of the ones i had set up at some point was like a change to a security group which is absolutely the kind of thing you want to be instantly notified of or within a few minutes at least

so let's take a look at what this looks like in our sample swag station 9 architecture so i've got a couple different things going on here i built out my public and private subnets i have resources in two different vpcs so i have a little bit of a perimeter going on there well let's say i want to log this so let's see what that looks like so first of all i can add vpc flow logs and this can actually track the connections between these different services the ec2 rds and lambda as well i'm just looking at this one part of the example so oops i've got a little ahead of myself there so the next thing you can do is uh so i

mentioned in lambda you can use that boto3 library i can actually add to the existing cloudtrail logs that get generated so if i want to make some other more detailed logs i can actually use the lambda event data or information that was sent into the lambda when it was executed i can actually add that or make decisions about that and incorporate it into the cloudtrail logs this has a lot of potential um i need to play around with it more there's just so much to learn in this area that it's it's just impossible to to have time for it all but it is pretty cool and then the last thing is um you can add a cloud watch trigger

for let's say unusual traffic so maybe my my site is like has some some weird um amount of orders or a large spike in activity that just does not feel normal because i'm a tiny little boutique star trek swag shop um and then the last thing i do want to point out on here that i did forget to um to kind of point out is i'm running an ec2 server i have access to the os so i can actually use or pull in logs from the actual os of my web server i can pull that into cloudtrail and and i'll support it over to cloudwatch so there's a huge amount of potential there as well

so so i i had um i originally had some plans to go into a little bit more depth with some of these tools but the problem is there are so many and they're creating more of them every day some of them work really well some of them probably need a few more months out and some tweaks before they're truly effective and it's really up to you and your organization and your situation to figure out what's going to work for you what works for your organization um you know aws has a ton of offerings but pretty much all of these are paid services and if you're a small company you don't necessarily have all the money

to just invest in in all the fancy tools that aws can offer what if you decide you know or well let's be realistic what if one of you know one of your c-suite decide that we should move over to azure what are you gonna do so it's best to try to assess what the future holds before investing all in in these expensive services and there are some great ones honestly kms is is phenomenal and i highly recommend it i've worked with it a little bit more in depth than some of the other ones and there's a lot that it can do it's it's really powerful and it makes things a lot easier um you know guard duty is pretty well

regarded um control tower has generated a ton of interest um but it's key to think about what you want to do uh and investigate and see like you know what your needs are as well before going whole hog into into investing in services there's also a ton of third party and open source tools out there many of which may uh maybe multi-cloud so if you are the company that wants to invest in in azure then it's absolutely worth looking into third party or and or open source tools that address that better than something that's dedicated to aws so we're now past the completely new level of this talk and actually the more i talk the more i realize it's turning

into the noobs complete guide and not the complete noobs guide so i apologize if you're a little uh if you're a little lost just know that there is a ton to learn you will never get bored you will never run out of things to learn in cloud security and that to me is what makes it so exciting so i'm going to talk about a couple other totally exciting things well to me anyways because i'm a huge nerd that are commonly connected to cloud security and i mean all these super fun things like serverless microservices containers i i think that um when we talk about cloud security one of the first things that comes to mind is containers

so i'm actually going to start with microservices and this is an area that i've explored a little bit more than some of the other areas so microservices is kind of a cloud native topic i feel like or at least it's very it's a very good fit for cloud talks in general or cloud architecture because the idea is microservices is a design pattern it has a methodology for creating applications and also it can be used for infrastructure as well it is a collection of loosely coupled components now i i know that um at the beginning of this talk i actually um basically described cloud services as kind of loosely coupled components this is all components-based architecture so

it makes sense that that microservices fits in really well with cloud architecture because this concept is shared between them but microservices also shifts a monolithic architecture way of thinking about an application to something that's a little bit more flexible and it it can make upgrading much easier because when you swap out components that have the same functionality it works a lot better this is actually comparable if you have any experience of programming to just the use of functions or the use of modules or a lot of the concepts that come with object-oriented programming so an example of this and i realize this is like the most non-color scheme abiding slide out of all of these i actually stole it from

another presentation that i did a while back uh this is just a quick overview of kind of what this monolithic architecture looks like versus microservices architecture and if you look at the the the right side of it it does look a lot like kind of a cloud architecture it's very similar so it's you know it's really well suited for the cloud um and microservices is also commonly used in combination with containers and uh serverless serverless functions aka lambda so what's serverless well let's be realistic there are servers in serverless they're just obfuscated away from you you have no interaction with the infrastructure so in essence the the idea behind this is this is a place for the for programmers

to create one function to execute something where you know there should be an input and a result there's one focus for it where they don't have to worry about confirming a server or an operating system or or even actually installing libraries all of that is done behind the scenes uh it simplifies the development process for developers and can be used for any number of normal it-related functionality that you could possibly dream up it's event driven meaning it's triggered by api access a call it kind of sleeps and then wakes up when you need it um and i could go completely on a rampage about that but i i think i'll try to hold off a little bit and not get

too crazy with it but really the idea is it's a very simple limited access model and it's also primarily accessed with apis so that's generally the only way that you're going to be able to access it aside from the initial configuration and this is aws is lambda is basically uh probably the best known example of of what a serverless function is and also kind of coin the phrase function as a service which is somewhere between that uh software as a service and platform as a service so again limited amount of access so this is an example of putting together microservices application with serverless functions um essentially what you can do is create a series of steps and then for

you know if this happens you move to the next step trigger the next lambda step functions is a pretty cool aws service it's definitely more on the development side than the the i.t side but it's still an interesting kind of example of a way to stitch together microservices applications and then last but definitely not least uh let's talk about containers for just a minute and i will freely admit that this is not my specialty um but it's again a really interesting area to dive in much deeper too if you have the time energy and you know if if you're interested in in this so essentially a container is a standard well this is actually docker describes it as a standard unit

of software that packages up code and its dependencies so the application runs quickly and reliably from one computing environment to the other essentially the idea behind this is to have a portable bundle of code that can run whatever application you need it's extendable it's flexible again fits really well into the cloud model overall and it's designed to isolate processes from the kernel to take that that management of the os away from you and it's very lightweight um but it can sometimes give the false sense of security uh in that it feels like isolation should equal security and that simply isn't really the case and that's kind of something that uh that pops up every now and then um so

again i'm not completely a specialist about this but it's definitely an area that you can really dig into and again i just stole this right from from docker's website but this kind of gives an example so in a vm you would see a hypervisor you'd see a guest os and all of that is actually obfuscated away in uh in a container and there are a lot of native cloud container services i think i want to say amazon has ecs elastic containers service storage one of one of those things um a lot of offerings in this space docker is definitely um well regarded um and i played around a little bit it's definitely something that's worth poking

at if if you have the the resources to do so so how does this all relate to security well it's not automatically secure if you're surprised that i'm saying that well don't be so a couple notes about this container images are generally open source so don't expect it just because it's available in the marketplace that it itself is safe that's not always the case so you do want to vet the container image before before using it and quite famously you can break out of a container okay containers are absolutely not secure uh by default um and there are plenty of ways to to play around and uh and use that to your advantage if you're

if you're a good hacker i'm not quite there yet um and then so going back to this idea of microservices multiple components is multiple permission sets so if we think about all of the different aws pieces that we looked at and all the connections between them there are increasing number of ways that we can configure roles and permissions and if you can break out of a container if you can break out of a serverless function that means that you have access to any of the roles that that that function has access to uh and that basically means that your application or your infrastructure is as secure as its least secure code and its most lenient permissions

boundary this is absolutely key if you remember nothing else from this entire talk this is what you should remember it's you know lowest common denominator your least secure code and your most linear permissions boundary if you have a role that has access to everything and can do everything you can use that to make anything happen you can create new iem users you can exfiltrate data all you want you can even delete logs so permissions is very important especially when you move into any kind of infrastructure um that is uh loosely coupled like microservices or like most of the architectures that that we've kind of poked at so far um and i actually put a call on twitter

for a really good basic level infographic had a hard time seeing one um but i don't i'm not going to go through this step by step and explain what it is so i will just say i'm going to reiterate its permissions permissions permissions so essentially in container security which this specific example relates to uh i mean you can basically you know have a default set of permissions but you need to lock it down you need to make sure that there's the container has only whatever level of access it needs to its underlying um infrastructure than that you need so it's always about permissions it always goes back to permissions so the last thing i'm going to talk

about very very briefly is orchestration and automation this is probably i mean this is a an entire presentation in itself um i realize we are slipping further and further away from complete noob into noobs complete guide category but i wanted to at least do this topic a little bit of lip service and the reason i say that is because these are terms that i cut that are going to come up time and time again we're always going to be talking about how do we automate this how can we create templates for things instead of having to individually stand up things that's always going to come up so automation is an incredibly powerful tool you can take boring repetitive tasks and

basically never have to worry about them again i often say i'm i know i'm a programmer because programmers are lazy programmers would rather do four hours of work up front then do a five minute task every other day or every week so essentially you want to use automation to eliminate repetitive tasks it's also a great way to standardize things that you're doing so that you have a consistent approach for pretty much anything so if you're trying to always respond to a certain type of of log a logged incident that uh that can happen so automation is a great tool it is also possible to auto to over automate your your um your infrastructure so uh definitely

keep an eye on what is necessary and what's overkill orchestration is a little bit more interactive than that it's more that the management of whole systems this is where you see things like terraform and ansible you know orchestration of containers kubernetes is one of those things that pops up a lot too so so again a huge area we can go into i'm not going to dig too deeply into it but if you want to enable flexible scalable apps and uh security infrastructure then uh these are kinds of things that you're going to be dabbling in um and i played around with terraform and ansible before they're super fun cloud formation just specific to aws also super fun and

they're called infrastructure as code which is kind of its own category in that pipeline or in that shared responsibility model so we're almost at the end i swear i only have a few slides left and then i'll i'll actually be done this is actually approaching an hour i'm pretty impressed um also i love this meme this is like one of my favorites uh so i just just to take a step back i know we've kind of gone zero to sixty and to be honest when i started out learning in aws i was a complete noob and i fumbled my way through learning how to use lambda i fumbled my way through cloudtrail and cloudwatch and

kms and iem roles policies lots of cursing was involved it's really easy to fall down the rabbit hole when you get into cloud security um and it's also really easy to fall all the way down the rabbit hole and end up with you know what we covered in our last slide about uh automation and orchestration so lots out there it's totally fine to feel like you're in over your head um so i i have a couple tips for that um which i'll get to in the next slide uh but kind of the other thing that i want to have you think about as the lessons learned is that you're always going to have different levels of access and control it goes

back to that shared responsibility model the difference between you know software as a service infrastructure service platform as a service every uh resource type resource service has a differing level of what you can actually do with it and you should always be keeping that in mind when you use them and you're you're basically designing infrastructure based on these connected components you have to think about what the connections are between those and the last thing on this list that i cannot even i cannot possibly stress enough is that permissions is the new perimeter you cannot fall back on perimeter defenses without it well in the in the cloud it just this is not on-prem it doesn't work the

same way so your permissions are your new parameter and always keep that in mind and uh one of the other last things that i'm going to say here is that you kind of go through a life cycle with this and i know this personally because i've done it a few times so my recommendation would be start simple go layer by layer if your organization is just moving to the cloud focus on getting the base set of logs in you know focus on base services learn them learn from them take it layer by layer component by component go from service to a group of services to the account to the big picture um constantly reevaluate um you know

it it's so important in it in general to always think about where you are and where you want to go and remember kind of what your idea was when you started has that changed does that mean your direction changes uh does it involve multi-cloud does it involve shifting in a totally different direction always re-evaluate and and think about what you're trying to do that is so important and once you've done that then you can level up incorporate new services incorporate new plans find new tools you know invest in that extensible flexible tool instead of something that's limited to one cloud provider but make sure that you do that re-evaluation before you you do that leveling up

cannot stress that enough and always prepare for change outside your control even though you know plenty of people had redundancy in regions across aws well what if they both went down you have no way of knowing so you should always be be prepared for things to happen that you have no control over uh and then the last thing is i'm going to bring it back to the complete noob as opposed to the complete guide for noobs um so i think when i started i had i had a a lot of ideas and i was bit i was missing some base knowledge so i'm going to say the biggest recommendation that i can make is to start by laying laying groundwork

and that means learning fundamentals it really helps you know for me i struggled a lot with vpcs because i didn't have that strong a network background networking background so learning networks and then using that to um to understand how vpcs work in aws really powerful you know learn learn a little bit of code because it makes understanding how these services work a lot easier and then the next thing is learn by doing aws is free tier um so do azure and uh and google's uh cloud platform use them abuse them create a little tiny web store for your star trek merchandise or whatever it is that you want to do it's so much easier to understand these

concepts when you actually get your hands dirty and don't be afraid to fail either there'll be a lot of failing you can't possibly learn something without things going massively wrong at some point or another and then the last thing i want to say uh is collaborate and communicate if you're this and that this actually applies whether or not you're a noob so if you're a complete noob reach out to other people learn from others ask dumb questions maybe google a little bit first but ask ask them questions um there are tons of people out there who have struggled through something and would be happy to help someone get a leg up on on this before

they struggle through it too so don't be afraid to reach out um and then if you're not a noob you know if you're in or you're in an organization that's moving to the cloud and maybe you're a little bit newer um communication and collaboration is important very important across teams so we already talked about how cloud security moves kind of in an abstract direction so you might be working a lot more closely with your dev team and if you're not maybe you should be because security is something that should be kind of a mindset and not just a job title so whatever teams are moving into the cloud should have security in the forefront of their mind or at

least maybe second or third and not you know fifth or tenth or something like that so learn to build bridges with your team members and leverage those relationships to incorporate security into the cloud as you move onwards and upwards and that's all i've got i'm i'm done so i have no idea why powerpoint suggested this image but i'm just going to go with it it doesn't understand my nerdiness so with no further ado enjoy the rest of the con and uh thanks to all my friends uh thanks to besides philly um it's it's been really awesome and uh yep nerd on

you