Lessons Learned From Enterprise Cloud Security Programs

good so let's uh let's get started and talk about um this is one of my favorite types of topics um or types of sessions actually kind of a ranty war story uh session on enterprise cloud security and very very specifically uh on what can be cut what can we do better what can we learn learn from from those different approaches very briefly from if if this thing works let's see i guess it doesn't magic okay very briefly from my side i'm a consultant i consult enterprises mostly but also also smaller startups who aspire to be enterprises at some point so they have also enterprise-like requirements for for some of their cloud environments i've been mostly

working with azure myself for more than a decade now but i'll try to translate on the fly into us as cloud diagnostic stuff as as possible on on any of those points when i'm actually going going going technical so again not working what am i doing

nope there you go so the plan for the session is to really get a quick primer not on cloud security kind of technical topics i'm not going to talk about what is iam and what is what are some of the very basic tenets there but really kind of get into the mind of what's happening on from an enterprise per enterprises perspective with regards to cloud security and how is that maybe different or how is that handled um handled in a typical organization that i've i've worked with and uh we'll talk about this kind of basic problem area of the enterprise cloud security space uh then we'll take a look at some of those cloud security

programs how does that work from a perspective of do we hire someone from the outside do we just get kind of some insurance what are the options that are we going to do about it and then we are going to look at a little bit more details into the architectural components of a typical cloud security architecture how does that fit into into an existing enterprise security architecture and all all along i'll try to add some kind of reality checks and lessons learned throughout these different session parts as well but really towards uh then we also also wrapped this up on the last 10 15 minutes of the show all right so let's get started with uh with the first

first part in here and this isn't really a surprise to anyone who's who's here we we all saw this kind of barrage of memes means about who was the biggest digital transfer transformator transformer etc for our um see through it and it's not of course the ceo it's not the cio it's the kobe 19. and basically what happened is that everyone who was hesitating uh of not going going to the cloud at all needed to take the jump uh in in weeks maybe maybe even days and that meant that most of most of us or most of the enterprises went there fast and then now all of us from the security practitional perspective we needed to

figure out how now that we are here how do we actually make this being here anyway secure whereas previously it was kind of analyzes paralysis that we were kind of just continuing to argue and argue about whether or not to go to the cloud when will we go to the cloud et cetera et cetera lots of different industries of course still are there still not everyone made made the jump with all of the workloads but if your ceo is already taking their email checking their emails chats video discussions etc already on the cloud you've already started to think about what is this split tunnel tunneling and all of this uh previously scary stuff uh you you kind of had to do it already

then it's it's somewhat easier to kind of retroactively start thinking about how to how to start securing all of this and really these public cloud vendors uh kind of prove themselves in terms of the capacity as well in terms of available kind of peak capacity there were some hiccups on on all of those and especially also on the on the availability of these services uh very early on in a couple of a couple of first weeks of of the pandemic for example for example look at microsoft they really squeeze down the limitations of okay you cannot really provision anything else if you were a total new customer if you already were on board you had your enterprise kind of

agreements everything you had to building relationship supports everything on there you've got priority um so they they had the processes in place and they they managed to have also the physical capacity and the logistics uh in place to handle handle those new workloads as well so basically the the whole kind of cloud model is now kind of went from this kind of early innovator chasm and kind of made the jump on on that early adoption curve so to say so we basically need to start thinking about shift shifting away from thinking about cloud security as something that is an isolated domain of information security some a specialization of of someone like we would have like

application security or network security it's someone's speciality it's basically now something that everyone needs to understand up to uh up to a ac up to a level right but also at the same time the kind of traditional rules of of an enterprise's point of view of having a trusted mood or a perimeter perimeter around our safe safeguards of data that doesn't really fly anymore either and we really need to start now talking about how do we actually secure those those assets that have some sort of an exposure to the cloud side of things and hopefully maybe the mindset has shifted that kind of cloud is not uh not something that can be at most as secure

as something that we can do on the uh on our own especially on kind of mid uh or medium-sized organizations and and up from there but also something that potentially can can be better than what we have um in our own environments if we do it right of course if we screw things up then the exposure area is of course much bigger so we need something called cloud native security this is uh one one look at this thing uh cloud native of course is also part of you know it's not just containers in my context what i mean with cloud native is that it's it's not it's specific to each of each of the clouds that you are you are working with

so if you are working with aws usually use the native tools and capabilities there if you're using azure the same thing going on there if you are looking at building a cloud-native security organization you need to start thinking about what are the cloud-native skills that i have that i need there do i actually need to ship all of my previous security architects into a cloud course most likely yes but do they need to be purely cloud specialists by kind of completely forgetting forgetting what they did earlier no it's it's something something in the middle so it's kind of completely different uh set of approaches we have less control available by default we need to understand a ton of new product names

within the individual clouds that we are working on uh even if we are dealing with only infrastructure service or platform as a service of course then when we add software as a service on top of that then you know it's in infinity then it's about identities maybe maybe barely some um there's identities maybe maybe some some level of access access control that we can add there to kind of at least bring our own identity provider and then it's about almost almost going in the full legal and vendor management mode of trying to understand each of the software service providers and how do they run things i'm trying to make this a little bit easier when we are trying to move all our

applications or infra to the cloud then we are dealing with provide csps like microsoft like amazon like google sim ali similars so you need new skills you need the skills specific to each of the clouds that you are using most likely you are using more than one but my kind of opinionated part of of this round is really really that you can do multiple clouds you can do multi-cloud but that just means that you need to have multiple single cloud expertise and multiple single cloud programs and and people behind it so this is kind of brand of building it in not bolting it on so if you if you've seen any any cloud security stuff you're seeing kind of the

approach of cloud security is a shared responsibility when you move from uh from uh left right when you when you move from on-premises you have the most control available you are also responsible of everything if you move all the way on the spectrum to the software service side you have the least controls available for you mainly on the data data and endpoint side maybe on the identity but everything else is done for you and you can basically just do your due diligence or maybe get a better pricing tier and that's about it so most likely this is familiar to you if you dabble with cloud security overall and a lot of the organizations do understand this even if they they didn't

yet go to the cloud fully what i argue is that you really need to the kind of the point of of the earlier slide saying that you also need to do this natively for each of the cloud and each of the cloud service that you are using within the cloud is that you really need to understand what does the shared responsibility model mean not just hey we are using azure or we are using aws but for each of the service what are the parts that are actually handled by us and what are the parts that we are responsible for and what are the parts that we can even control here's an example of of managed kubernetes

services there's different acronym for this from each of the cloud providers that and each of these have of course different ways of hosting the containers uh but this is an example of something that sounds very much tempting in terms of hey we get to be in control of of the workloads we get to get some unlimited scalability and we also get someone else to manage the infra off of our kubernetes workloads well in reality we mostly uh only get a little bit fancier infrastructure as a service and just a teeny tiny bit of container as a service doubled on top of it everything else is still are responsible most most of these cases aks eks and g key we basically just just get

a managed version of the keyboard in this control plane which is the one that then goes ahead and does the actual orchestration spins up new nodes and then spins up new containers into those nodes the nodes themselves are our responsibility we need to either kill them off very fast and update them regularly or we depending on our maturity and depending on our approach there we might need to actually think about hardening this at least monitor what's going on in those environments we saw earlier last year for example with the with the ombi guard on on azure site where basically not all customers who were using these services understood that even though that microsoft provisions the csp provisions a node that hosts

your containers and they patch and they provide you a patch for them uh kind of it's available you still actually need to go ahead and kill those nodes and and get those new nodes up and running and that's all your responsibility the bigger part of of this beautiful colorful display here so kind of a little bit of an intro um uh intro on the on the approach on the cloud security site then quite typically when we actually start thinking about okay now we have some budget yay pandemic gave us budget pandemic gave us a way of now that no we are in the cloud we need to now actually secure this uh then what's going to happen

basically as with any any enterprise there's already existing existing set of people there's existing vendors maybe the caesar and the cto have different budget than the folks who are driving in the cloud of course you need to put all of those in the same uh same kind of internal political um warfare but if you're looking at this from the perspective that we will already have an idea of what are we going to do on the cloud we know that there's only one part of the organization who's handling it we don't have any turf force or anything then then it's basic basically about balancing this the scales of of these business needs of of we need to be there fast

and we need to do whatever we do ai blockchain whatever that the latest types do we have in here in addition to the basically the ease of this shadow cloud basically if you if we make this too hard then our customers the business will just swipe their credit card and do their own thing in their own isolated environment and we are known the visor on the other hand we of course have have our kind of existing security requirements that might need update upgrading to the to this decade or or to to even acknowledge the concept of us not understanding or us not being uh physically uh in the ownership of the whole stack end-to-end um and at the same time we have we have

more and more people coming in and taking um potentially more risks uh in our environments when when a developer was working on or any uh any user was working on our own environment we were basically able to control limit the amount of damage when they when their environment goes boom then it was still within within our trusted trusted network perimeter and within our uh monitored environment now if if something goes wrong they can potentially expose themselves to to everyone on the well one third of the internet everyone is able to go ahead and download the ip address ranges for all of the major csps and of course they are getting scanned and bombarded all the time if you if you

host your own uh whatever application in there you can definitely do things the wrong way um and then all of this needs to needs to of course fit somehow our existing security architecture as well typically i see this kind of asymmetry of there's maybe one too many relationship of security architects versus versus cloud solution architects or or cloud and even more cloud developers who might not even understand the cloud architecture part let alone the kind of security implications of of those a lot of people seem to understand very well that those pricing models of different cloud services and architect stuff around those but not necessarily the the security parts so basically we need to start thinking about

keeping our new security policies competitive and secure or updating them in a way that keep us competitive and secure with this with this cloud move so basically again if our controls are too strict if we are too slow at providing those controls the developers will start using those new cloud services themselves either in our own environment or if we really kind of go go ahead and have this kind of a list of allowed us cloud services in there and we enforce that using some policies or other tools again they have their option of just picking up a new cloud environment and doing all of that on their own just for the development area and there's the typical argument is that if

if we have this kind of pre-security verification of all all security all cloud services than it always takes because again the symmetry of less people on the secure understanding security than there are people who want to use the cloud because of that asymmetry it will always take more time for the central it or the security organization to catch up and provide those services so we need to be fast and we need to put on those controls that are minimally disruptive uh to the actual business to actual use of those services while still trying to balance all of our existing requirements on the security so it's a lot about verification so it's a lot about shift left and other other approaches

there but this is the problem uh problem statement and that's where we can get into a cloud security program uh which there's a one example of that of course you know as a consultant i'll say everything depends but basic basically uh you need to have some sort of a cloud architecture this this is usually done within like a cloud center of excellence this is maybe done according to the best practices of the vendor according to your cloud uh well arc will architect that frameworks on aws side or cough on on micro micro side of things but basically we need to have some sort of a cloud architecture there might be another other team already working on

that we need to update our cloud security policies and we need to be able to start designing our cloud controls at least for some parts of our environment maybe not everything that we already happen to have now with the pandemic there but at least identifying our own crown jewels and going from from there it's a as a consultant yes it always depends there's always all nice different boxes maybe the anti-pattern that i see is that all of this part is done well the upper part all of the cross referencing and mapping to external requirements if this is driven by an internal audit or risk or compliance part of the organization you'll have plenty of beautiful cross

references and plenty of beautiful excel sheets but you don't actually get any any controls defined you need to actually provide the real-time data from your cspm or you need to be able to define uh kind of bridge the gap between your fancy governance models and and your your framework with the actual security controls that you have in place and you need to get some visibility into uh into this cloud security framework so it's not a cloud security framework which is part of the whole program is it's not an excel exercise it's not an internal audit exercise that's a nice outcome of it but it needs to be tangible it needs to be a set of cloud

native policies for example it needs to be a set of things that you deploy that actually control or limit uh what you can do in in your cloud environment in a safe and uh agile and secure way okay so to implement all of this you need you need this cloud security architecture typically these different components that you will see see here include the landing zone or some sort of a secured cloud platform this typically what this really is is basically well the only technical thing that we really have to have there is basically the billing relationship so that we won't our accounts will be taken over if someone's credit card gets gets stolen or uh or not updated accordingly and

everything else is basically up to up to what you are doing there it can be a set of set of tenants it for example on the aws organization side or azure side you can you can define to trust a specific identity provider that you can then link with your with your existing idp you can bring in azure active directory to both of those to control access there it can be about all of that identity part it can be about having some specific um cloud architecture in place to enable networking connecting actually back to your organization the whole concept of the landing zone depends a little bit what you are doing there and there are best practices and pre-populated stuff

available for you there but basically it's either some infrastructure as code that you you keep on updating and deploying or it it's at least someone did once this one vpn connection to our cloud and then we have this one account or a subscription where we are deploying stuff and everything more granular from there and within that there's different approaches different concepts uh you can use different cloud products these different cloud services like lambdas or aci or aks and basically your cloud application or a cloud workload the workload is just a collection of those if you are a larger enterprise or if you just buy like a buy like a large enterprise you might want to have a

customized versions of these products so you might want to have your own repository of your of the same products but with your default configuration maybe you have your built-in hardening there you have the specific controls already inside those products so you are not even letting your developers freely freely deploy stuff from the portals or consoles you just give them a bunch of infrastructures code and say okay this is our uh enterprise version of lambda this is our enterprise version of rds or azure sql database use this when you deploy then you're golden you don't need to worry about it that again requires that we do all of this pre-work and keep on being faster than all of the requirements from our

developers whichever approach you take basically you will have some sort of awake landings or some sort of a secured cloud environment uh that a bunch of people are going to deploy much more rapidly uh different cloud products uh into that and they might even interconnect even if you don't need so you need to have some sort of controls to put in place in there uh identity and access management is something that we always always think in this landing zone i mentioned that it can be just a simple thing as a tenant where you have very very connected possibility to your existing identity system uh here we need to think about how does all of this fit

into our existing enterprise im processes the abort service now a year ago it was uh it's still ongoing the implementation uh project now we are going to have a bunch of bunch plenty of new roles in in this cloud world we don't even know how many roles uh before we before we get started so how does that pacing work together with uh with these cloud requirements again do we need to think about separating uh admin credentials for cloud is our cloud tenant different from our is our business productivity tenant different from our uh apps and infra tenant do we have a separate attractive directory or whatever we are using for them um will we have different set of access

controls for or you will have different sets of access controls for the control plane or management pane of your cloud environment so meaning who can go ahead and deploy those aks create and delete those clusters versus who can go in inside those vms who can actually get those ssh keys or however you're authenticating there and actually make those patches inside uh inside those those nodes and the same is true with uh with all of those different services that you're using and you don't have this this con you don't have this decomposition of control and management plain versus data plane before you actually do this uh this bit of analysis of the shared responsibility model that that we did

earlier there so all of this surprisingly connects and then you need to think about external users do you have exactly the same set of external user or guest user onboarding do you still ship your company laptop to your external developers who are working on your cloud environments uh if you do then what what's happening with your network controls again do you do you have a set of conditions that allow your developers to only access access the cloud environment cloud console or portal only from the company network within with all of those specific criteria being met maybe yes maybe that's going to take some time and you gradually will shift towards that and then finally how do you think about

all of this when everything should be on that should be deployed not by developers going into the portal but actually going to some infrastructure as code updates in your section of pipeline and then you're basically once you're done kind of hardening all of your accounts and subscriptions you start to understand that they're actually more or less persistent access that you need to create to your deployment pipelines into those same environments that will have to have by definition a lot of power they will need to have basically right access to create read update and delete all of those resources in order to create read update and delete your cloud environment that's that's your data center now it's it's

it's completely defined as infrastructure as code and you know stay here in the room to check the next session i guess to how to do that um but from an infrastructure or from the iem perspective you basically you don't have a single place uh where you can see okay who has root on my cloud cloud subscriptions because you will have that shared service principle or something else that is being used as the credentials of your whole sections pipeline that might might be a single a single user or a single service principal or all of your teams might be sharing that it might be basically you need to combine your ci cd access logs and access reviews

together with your actual persistent cloud access controls and access monitoring in that so it does disconnect and abstract it away which means that it's more obscure which means that more things can hide can be hidden here this is this is how um well i forgot forgot the term apt 2029 got in basically by just piggy packing on existing service service principles on azure active directory that were created either by developers or just by business users when they were taking in basically basically software as a service applications and and just saying give me single sign-on to my whatever hootsuite or or whatever i'm using behind the scenes if they had the power to do it in a self-service way they

basically got a service principle on the azure active directory with fixed set of credentials no one looked at those keys it wasn't done centrally because again the first bullet or first box was integrating with existing im as processes on our organization noah look at looked at those things when when you actually got in there you could create regenerate your own permissions you could generate your own keys to do other stuff in the same environment and that brings us to detection and monitoring part of course tons of logs tons of new information that we didn't have before we need to figure out where where and how and if to store all of these things we need to add machine

learning to throw us some alerts from here and we need to somehow integrate all of that with our existing sim and sock which brings us to some sort of centralized cloud logging architecture uh this is one example where um the azure logos but the same is true with everywhere everywhere else i mentioned that you will have more than more at least one landing zone where you have those applications those applications which are a combination of pre-built products a landing zone can be a subscription or an account in aws world and most likely you will have some sort of a centralized one where you don't have all of your developers accessing uh your your logs and then you need to figure out how do

you ship those logs from from those uh more or less isolated application specific or however you divided this those accounts and subscriptions how do you ship those logs um is there a cost impact is there a cross-cloud impact is there a retention or compliance impact and if i decide that i store more stuff in my application subscriptions in those log environments that's great that's more useful for my developers and that kind of shifts their responsibility to them but what if i need to do uh incident recovery what if i need to do some sort of forensics work do i have a place of do i have a system in place where those centralized folks or whoever is that uh

that set of people who are doing this incident uh and and forensics work how do they get how will they get access to to those uh isolated or decentralized logs and is it is it an on-demand type of approach or is the persistent approach if they have persistent access to my application logs that that might be hard for for my certification or audit purposes and there is still the networking question it's not just one magical cloud there is the cross subscription networking which i just kind of opened up that do i send all of those logs on the previous picture across the backbone of my csp or do i have some sort of vpn or do i have do i have something

specific on the cloud environment to secure the connection in transit in a way that meets my compliance requirements and in a way that doesn't add additional cost or slowness to the to the implementation there what's happened if i need to use multiple uh regions of my cloud provider and what happens if i need to transfer those into my own premise needing to do hybrid uh cloud connectivity what if i need to do connectivity between my aws azure and google environments and what happens if if one of my sas vendors uh is big enough that they they burned their own networking structure if i'm using stuff like i don't know palantir for exam for example that's hosted in some

some one of these big csps i need to figure out how do i get my my existing landing zones in that csp connected into that more or less multi-tenant or shared environment of my sas provider and then of course we have this application level traffic that's kind of uh something that we we should be familiar with web application firewalls ddos protection etc only the so the problem area is familiar it might be that the fact that everyone is doing this now in a self-service way that might might be the headache there it might be the fact that we need to have some sort of way of controlling all of our rule sets for example across all of our

web application firewalls if we allow people to use their own and how do we do this in a kind of cloud native cloud-native way which brings me to the fourth part i basically alluded to uh to this animations are a bit wobbly a little spoilers there but that's fine i basically alluded to this first problem area of how do we integrate with our existing uh enterprise im it could be that we have very elaborate processes very elaborate tools uh already in place for each of the roles uh for each of the applications that we uh we might have we might have done years of work on stuff like sap where we have very granular level roles defined and defined very

specifically what happens kind of in an end-to-end life cycle perspective of privileged users regular users and all of those different roles with their externals internals what if they they move uh move to a different unit but still stay internal all of those uh all of that kind of existing work that we've done now somehow needs to catch up with the hundreds of different role types available on the cloud environments and with the concept of not just having this one landing zone level role which is kind of a dc admin type of type of role but going very very granular potentially even in the level of a single a single cloud database resource that we have might have their own own role types

available for them and our typical database admin might need that role but they might also need a reader role in a wider scope and that's basically the kind of the business role composition becomes a very taxing process if we want to do it exactly the same way and as manual as we did for all of this existing uh stuff that we had um the same goes again with these unmanaged accounts especially the service principles similar type of accounts where when the first time you started using using your cloud environment you asked like hey can i get a a service account created for my aws account or service principle created for my azure azure subscription so that i can deploy

my ci cd from there if you don't by default if you don't do anything anything and if it's old enough uh those search basically those credentials basically don't expire you need to manage those credentials how how do you actually get access there now nowadays they fixed a little bit on some of this so the default expiry dates uh in in gui are short but there's no such thing actually for example on service principle aside there's no such thing on the actual api level so if you still have the same code that creates them you're you're out of luck and and again our guest accounts federated accounts our if we buy or sell a part of our business we

need to maybe carve out a piece of our our identities there as well so you basically need to uh create some sort of a concept of a cloud account vending machine that makes you get your developer some sort of a self-service way of getting access getting the proper type of access maybe even defining that access on their own uh instead of you doing that pre-work for them maybe they just submit a pull request and the security work is actually you're reviewing the specific role description and uh doing that analyst an analysis there rather than you trying to figure out uh before they they use what type of roles they should be getting and then automating automating that

so trying to speed up on the multi-cloud side and even even in a in a single cloud multi subscription uh just a larger larger environment uh inventory and asset management becomes uh a big question because we don't know what we might not even know what we need to control we might not if you recall that that omigod case uh we might had might have had the idea that we had a ton of vms in our environment but did we had an inventory of all of all of those cloud cloud solution provider provisioned uh agents and and configurations on those images that were provisioned for us did we have an inventory of all of those all of the versions that we that are

deployed there where was that up today did we understand that we are the ones who need to patch that um sometimes yes containers seems to be pretty much the standard way of deploying stuff now that's great we need to understand uh if you have a kind of modern cspm there we have most likely great scans available of of our of the vulnerabilities of the containers when they were created or built are these are these alerts now relevant still five years later or a year later what are we actually which of these images are we actually running in our cloud and how do we make that make that connection that's that's the part that we we do need to

figure out again are we doing this in a cloud database or are we doing this in the kind of using the tools provided by the cloud vendor or we do we need to somehow integrate that tool into our uh existing uh that information into our existing inventory and asset management basically do we have some sort of a web hook that whenever we deploy a new container in our in our thousands of different subscriptions in in some kubernetes managed cuban in this cluster how do we get that information of a new new pod is uh pulling in a new container image how does that information get into our s-bomb whatever we will have in the in

the future of a collection of what are we actually using in production right now there's new vulnerabilities in csps uh we saw uh both on on azure we saw on cosmos we saw on aws we saw on lambda there's there's tons of new vulnerabilities as there's more use we get more disclosures of new vulnerabilities of the csps themselves cells and again we need to understand what have we configured that has been our responsible and now that we haven't haven't done any controls ourselves on the part that they were they were responsible of we basically just need to understand what is the impact when when will they go when are they going to patch that and is there an impact for us

and then we had these new signals from cloud health kind of new maintenance events new scaling events all of those events it's very hard to kind of find any type of insights from that noise we need to basically take into some new products which have machine learning and all sort of pre-filtering and playbooks available in in there we talked about shared responsibility we talked about omigod quite a quite a bit um and this concept of of we are just doing this for that we don't need to uh do this properly because we are not yet using production data well attackers of of course don't care and also the public doesn't care if whenever you you have a

management port publicly open in in your environment on the public cloud and that is somehow linked to your business they're still at minimum the reputational risk if nothing else in there and believe believe you me you will be found out whenever you provision something within five minutes you will have everyone knocking uh on on your door there and this is basically where this uh software bill of materials uh could maybe help potentially let's see how how do we how do we get a better integration from from all of our different vendors in in this space two minutes for q a and very fast switch of a speaker at the same time thank you very much and i'm gonna take

some questions