There. Today's talk is about truth about running cloud security assessments in 2021. A practitioner story. The topic should really have been documentation versus the reality of cloud cloud cloud security assessments in modern day architecture of cloud environment in 2021. That should have been the real title. But clearly you would not be here if I said that you might think it's just a fun talk. Maybe you may be right. But before I get into this, let's talk about what am I going to discuss in this talk? I would be talking about the framework that people use to run assessments and the framework that people use to run assessments against themselves in any given paid engagement. We also talk about assessment landscape, the type of threats, the assessment types, automation, do you even need it? And come of the differentiation between running an assessment from an auditor versus having automated tooling. And in conclusion, well, we'll conclude with what the real truth is about everything, but the documentation really holds up the test of ground. There is an assumption made that you understand one or more services of the cloud service provider that you may be dealing with. It could be any cloud service provider. You don't have to be an expert in it, but having some understanding of some of the foundational pieces would be helpful as we go through this talk. If you're an auditor, even better, maybe this may be an introduction to what modern auditing could look like. So without further ado, let's get into this. First of all, nine to five, I am the head of security and as a CISO, four of a growing company. Normal day for me is about running initiatives and trying to reduce the risk of an overall organization's security posture. Before that, I used to run a practice of cloud security for a consulting company, which I'm an investor in. We used to help organizations of all sizes in different industries, specifically enterprise, move into cloud through digital transformation. Outside my nine to five on the weekends, I am the host of Cloud security podcast, a weekly video podcast which is live streamed every week, and we talk to different cloud security experts on various topics around cloud security each week. If you are a follower of the podcast and subscribe or come on livestream special shout out to you and thank you for joining me over here. Looking at the experience that I've had as an auditor, you would be able to take that and apply some of those concepts into your environment as applying from a perspective of if you have an internal auditor, what kind of questions you should be asking them, or what kind of expectations you should have from them, or what kind of information you should be provider them so they can help you the best way possible. First thing, suitable framework based on the organization you work for and the kind of data you deal with. You may have a lot of frameworks from a compliance perspective that you may have to adhere to. Those frameworks are pretty rigid in terms of requirements they have. Some of them even call out specifically what encryption algorithms should be used. You could be looking at things like NIST, ISO 27,001, GDPR, sock two type two, PCI, HIPAA. We can keep going on, but a lot of these would primarily depend on the kind of organization you have and the kind of data you store in cloud. This may not be as different to what you run on your data center environment, but it will be different in terms of the kind of landscape you have in your cloud environment and how shared responsibility plays an important role in this, especially if you're in a hybrid environment where your applications exist both in an on premise world as well as a cloud world. You may have to think about custom frameworks where what segmentation is appropriate for your architecture, whether you have your non compliance driven architecture or non compliance driven data and application hosted in cloud, whereas the compliance driven sensitive data being hosted on premise. There could be multiple models like that as well. But primarily you would use a foundational piece like a NIST CSF or ISO 27,001 as a base. And on top of that, build for the cloud service provider you work on now, that's generally the kind of framework as a baseline that you would start with. Let's talk about the cloud assessment landscape. As you can imagine, I love blogs. The reason I had this picture for expectation versus reality is the expectation that people have about landscape. For any cloud environment. I'm going to take the three most popular ones, Azure, GCP and AWS. They all have documentation on AWS. Well architected framework, well architected framework in Google Cloud, well architected framework in Azure. But how many people actually follow these? Even though cloud service providers have been quite open about what you should be doing as the right form of architecture? Answer is none of them. People go through exercises to shape some of their organization architecture with the well architected framework. I think AWS and some of the other cloud service provider have assessments that help you map to how aligned you are to the well architected framework. But a lot of times what we would find in an audit is it's not really well aligned, it's not by the textbook. So that kind of makes things quite challenging. To that point, the cloud adoption type, what you really see in the real world as an auditor or as someone who runs a cloud security assessment is cloud architecture, which would have been migrated into cloud. How do I put this in a simple way so I don't offend anyone? There are two ways to move into cloud. One is a simple lift and shift model where you had something on premise and you moved it exactly as it is into cloud. That's called lift and shift, whereas there's another model where you migrated into cloud but went through digital transformation, you made them into microservices and started using some of the services which were provided by a cloud provider. Now, depending on what stage of migration you are in, like for example, if you're migrated recently, or if you've been in the cloud for a year or maybe for a few years, you may have a separate security tenancy or account in your cloud service provider. And depending on the cloud adoption type, you could have gone down either ways. What that means is you would come across teams which have been specifically designed that their job is to provision the tenancy or accounts for the CSP that the customer is using. Each business unit sometimes are given a lot of liberty in what they can do in each of these tenancies, but there's usually like a central team that creates it. Sometimes it's just the individual business unit are paying for themselves. But predominantly the adoption type is varied. So when you walk into an organization and thinking about, okay, clearly well architected framework is not going to be the case because the reality is depending on what stage of migration they are in and how they migrated, it could be a combination of any of these. So my advice would be to what kind of adoption was this and at what stage of migration to cloud they are currently at, to kind of get into that physical mind from of, okay, this is the kind of question or the subset I should be thinking of. Once you understand the type of adoption or the stage that the customer is in, the next obvious step that a lot of people go into is let's talk about the different source types that I need to assess expectation over there. If you look at the documentation, if you're in AWS, the expectation would be, I would get a lot of cloudformation templates. You probably would be only using one cloud service provider, maybe two maximum, right? Why would you go more than two? If you are a mature organization, you may even be using cloud native services, which could be cheap combination of services provider by your cloud service provider and maybe even deploying multiple times a day as well. All of that would be built on a code repository because everything would be running on code, and no one would have access to any of the production environment either via RDP or SSH. Unfortunately, the reality is different. The truth is, I've been in assessments where infrastructure type is a mix of containers, kubernetes, vms, EC two, you go in and you're told, hey, we only have one tenancy. And you make an assumption that okay, one tenancy. So they would have gone down the well architected framework, they would have segmented their network properly and would only be using one type of compute because you would only have one application per network. Unfortunately, a lot of the conversations that I had was where one network had multiple assets or multiple applications hosted within that one single network, which is not a bad pattern if you segment them properly. But you're told that there's only one network without letting you know that there are hundreds of services within it. So you can see where the discrepancy comes in, because it's cloud, and one click gets your data better. So assuming that if someone tells you we only have one tenancy, whether it's AWS, azure or GCP, you probably are looking at potentially hundreds of services. That's kind of point number one, application itself, you could have a mix of monolith or a microservices. Now generally this is easier to kind of comprehend, because if an organization has been in existence for over ten years, it's most likely they already have some monoliths which they've been carrying over. So digital transformation may not have fully been adopted. So you might see a mix of things which are not that flexible, so they might not give you that to assess. They would just say, hey, focus on these, do not focus on these. So there could be those kind of scenarios as well. Now we'd mentioned source types, and I think it's worthwhile calling out, not everyone does automation in cloud, not everyone does infrastructure has cloud. Sometimes it's just easier for you to click through the console of your favorite CSP and just deploy them. But what that also means is the other extreme where people have gone down the infrastructure has code path. What I was getting a lot of times as an auditor was a Yaml file, and I was told, hey, audit the Yaml file. This is exactly what we use, and this goes into production. So no access to the actual accounts as well as you can imagine, that makes things very difficult. The other thing that you would also notice from a source perspective is the type of access you get. Some organizations, they'll give you all admin access, because it's a small team like some of the startups that I worked with gave me full access, and this is a trust because it's a small team of 25 people, everyone knows everyone and understandable, but I would probably say do not give admin access to an external auditor who's trying to assess your cloud environment. The other one example that I've seen is where each business unit gets its own data center or tenancy, and you end up in a situation where you have 20 plus accounts under one business unit because they were told by Amazon you should have segregation of accounts. And they've created multiple accounts because creating an account is free, but you just put so much stuff in there. So that's another version which we come across where they might ask you to audit just one business unit, but then again, kind of like the infrastructure type where you assume it's just one business unit. So Max might what, five to ten applications, but kind of realize it's a lot more. These are examples of not so mature cloud organizations. However, there are some good examples as well that I had the fortune to work with some of these mature organizations. An enterprise, they had predefined security default for all their environments. They did have a centralized team to deploy and provision cloud tenancies for their entire organization. So if I was a business unit and I wanted a AWS account, I can go to that team and get an AWS account which already had my security defaults over there. I was given access with a read only permission and I was given, provided, even provided mean I was mind blown at that point. I'm like oh my God, they want me to actually use come of the automation that I've created to not waste their time with me asking them questions and figuring out how to put access keys instead I could just run come automation and do the entire audit in half the time. So I can understand the architecture of the application in the first half of my audit and the remaining is basically cut in half because I'm just going to run a tool while I'm having the interview with them. So I'm just saying I love mature organizations. So that's some of the realities that you find in a organization which has just, I guess found their way to maturity. You can already see documentation is starting to show some cracks. We definitely don't have AWS well architected framework or Azure or even Google Cloud's well architected framework being used. And then the assumption that everything is cloud native. Because if you read documentation from any of your CSPM, they're basically calling out like for example Azure would say use Azure DevOps, don't use Jenkins or any other tool, insert another tool which is open source, but your developers love it. They would also call out you should use only the tools that are there in their cloud service provider, which clearly is not a complete security suite. But sure, we clearly cannot be following that to the t. Not just as someone who audits AWS assessments or does AWS assessments or even runs a team that has AWS assessments. If you're one of those, you probably should start thinking about don't just rely on cloud native and stop drinking the kool aid. For lack of better word, they don't have all the answers to all your security requirements. So you definitely have to seek an external person to either identify what you're missing or have someone in your team research and find out what you're actually missing. From a risk perspective, you could be completely missing out on some of the blind spots that are created by just drinking the cloud koolaid. Let's talk about threats. And I love this. As I mentioned, I love dogs. So this was something hilarious that I found out somehow people have this negative, I guess, emotion attached to doing threats assessments. And I just do not get it because I understand there's a compliance requirement and you're trying to have a certification. So you can increase your sales as a startup or as an enterprise. You can show that the customers can trust your organization because you take security seriously and consider all kinds of threats in cloud. So let's go through these threats and identify what kind of brackets do these really fit in. This is the meter attack, which is a really popular TTP or tactic tools and techniques. That's how they say it. Or tactic techniques and tools. However you want to say it, every threat hunter would look at something like this in order to understand what is the kill chain or aka how do I completely take over an AWS, GCP or azure account or tenancy? These are some of the kill chains that are known in the industry. So as you can see, start from the left, how you get initial access, how do you persist access? How do you go about escalating your privileges, what kind of defense measures you can take, and credential access? How can you do discovery work? I'm going to try and focus on the initial access because everything else is built on the assumption that you have access. So I guess why not build threat on how someone would get initial access, right? So let's focus on that. If you look at all of these drive by compromise, exploit, public facing application phishing, trusted relationship and valid accounts, they kind of fall into three big buckets. Someone's exploiting a public facing application of yours, or someone who's successful in getting credentials from one of your staff members, or you're not managing your supply chain or third party in a good way. Let's take a deeper look, right, because we're talking about threats. I'm not just not going to give you the high level definition. Let's go a bit more deeper. Public facing applications is usually around application security and network security. Remember the conversation about one network that I had just before? And application security is the application which is hosted inside that network. Accidental s three bucket being made public, or a Google Cloud bucket being made public. Those are scenarios for public facing application. There's another scenario where you could have a Kubernetes clusters API open to the Internet as well. Someone's able to use that and escape out. Brings me to point number two, which is phishing identity access management and secret management. Your identity access management uses the same password as your corporate username password. There is no single sign on, there is no multiple factor. And to make things worse, in a cloud environment, it's not just a regular user, an admin user, there's a third kind of user or an identity in a cloud environment, which is also called a server identity or a computer identity. The concept is even when you're not logged in, you can make a server or a service have permissions which they can use to go and take some actions. Now it's great from an automation perspective, you could be sleeping and all your machines are being patched or all your scans are running while you're sleeping away. But the other point to this also is that if someone exploits that and is able to use that key that's been provided to that, I guess, server, they can use it for doing exactly the opposite of what it should be doing. So that's phishing, invalid accounts. Third party management for this is primarily around shared responsibility. Now whether it's shared responsibility between the third party that you give access to, you may have a CSPM for managing security posture, you may have a data dog for performance management or something else. Include any services that you may think of and you give them access user either a credential of some sort into your cloud service provider. As you've done that, you've basically opened up another identity that has access to your environment. So let's just say probably should look into reviewing this ongoingly and also try to look at having come kind of a check for how often was someone accessing or updating new third party supply chains or new third party into your supply chain? Let's talk about assessment types. We've spoken about the source, we've spoken about the kind of adoption. So I'm an auditor, or I'm about to learn auditing and I've kind of gone in. Okay, so I've given you a realistic picture of the kind of environments you would see. Let's talk about the kind of assessments that people do. One is a point in time, big bracket. Point in time would be someone, an auditor comes in, goes through a checklist with you for one of the compliance standards that we mentioned earlier, whether that's iso 27,001 or NIST standard or soc two, type two as well. Another type for point in time is someone like me or another person who would have been part of my team who uses automation. We would come in, we would ask you about architecture review of what is the architecture of your cloud environment, what kind of services are you using? And we may even validate that using some kind of an automation tool. Because let's face it, you may think you know all the services, but that may not be the complete truth. So it's always a good idea to have some kind of automation handy with some access keys or some username passwords that you can have for the AWS or Azure or Google Cloud account. So you can understand on your own, are there services that the customer or the client should be aware of, which they're not currently, unless they have basically chosen to hide that information. The complete different story. Now, these are point in time, another form of assessment that a lot of people think is an assessment, but I think it's more awareness and visibility and monitoring, which is the continuous assessment type, which is providers like of your CSPM, which is cloud security posture manager or cloud access security brokers, CASP, what these provide, and I would not be going into too much definition of these providers. They are excellent tools. If you are starting off in cloud for the first time and you have no idea where to go, great tools for that. It gives you visibility for what your cloud looks like compared to a standard which could be CIs or NIST or some other standard that they support right now. And CASB's are almost, the way I would put this is it's a proxy for what kind of services are allowed in your network. So you could choose to say I only allow AWS as a cloud service provider in my environment. Or Azure has the only one, or maybe a combination of two most popular ones nothing outside that. You would control that using cloud access security broker you scans also use that for checking what other SaaS services are being used in your organization, but that's more of a continuous model. So what's the reality of getting any of these assessments done? If you're looking at a point in time or continuous assessment, the difference would be in a point in time continuous assessment. If you do a regular point in time assessment, you get an audit of your architecture and get information about what may be a potential risk that you're exposing yourself to without realizing in your cloud environment, which the CSPM may not have considered and worthwhile calling out the cspms of the world. They are great tools, but they're usually focusing on the checklist approach because there's an API that they call and they rely on the availability of an API before they can even add that checklist in there. There's no manual approach to it. So the risk that is shared is a based on a checklist which is API driven. Great for something that already has an API. But for me personally, what I found after running CSPM for a lot of years, it looks a context for why is something a high risk? Why is it a high risk if I have an s three bucket open to public when it is supposed to be public? Or why do I have it has a risk when my s three bucket policy on the top of AWS account, which controls all the s three bucket policies says irrespective of the status of the individual bucket, all my buckets are going to remain private. So things like that are just not there. There is a context missing between a CSPM and a CASB. It's a great tool for you, giving you visibility, but it just lacks that context. So it doesn't have the context of the architecture. If it makes sense to architect a solution like that from a security context, if there are enough defense and dev layers, it doesn't make sense from a concept of okay, as I'm saying this, I do want to call it out. I don't dislike CSPM. Hate is probably a strong word. The reason I say this is because I think it's worthwhile calling out that the report that you would get from a point in time assessment would help you create actionable backlogs in your security team or relevant development teams. Whereas what you get from a CASB or CSPM may really be about how do you link to a compliance checklist, which may be the goal of your organizations are totally fine with that, but you probably need more than that to understand why is this something a risk? And is this genuinely a risk or just a false positive? So a real risk is only real, in my opinion, is when it's assessed by people like you and I, unless AI machine learning gets to that point where it can make that, I guess, call. So whenever that happens, but for the moment, we're stuck with this. So I'm going to stop bashing CSPM. But let me just tell you about, I guess the other things that I've noticed being has caspian CSPM after being customer of these for some time. The checks and controls are obviously API driven and if there is a service which is released by one of the cloud service provider, it's not always the case that it becomes available on the day of the release. So if there's a new service that gets announced right now by any of the cloud service providers, your CASB or your CSPM may take some time or may rely on your feedback before this gets added into your so called continuous assessment tool, which ends up in a scenario where you have a lot of wall of red. So for example, assume I came in or someone else who looks like me and knows like me uses automation for reducing the audit time to half and comes with a checklist and gives it to you. What you might realize if you use some of that checklist and dig into one of these CSPM. A lot of them may already be there, but they're buried in the gamut of false positives or ignored messages or alerts of CSPM. If this was real chalk, I would probably go raise your hand if you have seen a wall of red on your CSPM provider. How many have zero as the alerts on their CSPM provider? I do not know of that many examples where people have not had false positive because of the lack of context, which is what I was talking about earlier. So that's the honest truth between a point of in time assessment as well has an automation driven assessment and a tool which is a CSPM or a CASP. That's the difference. Talking about tools, I wanted to call out some of the tools that I've personally used and some of the tools that have been recommended by the community, I would definitely ask you to check them out. Obviously this is not a complete list. This is the one that I could fit in the slide, but if there are ones that are popular and I've missed out on them, clearly add them in has you go these are just for the tools of the compute itself, but there's another version that's coming out which is specifically for infrastructure as code, which I believe is almost like the next generation of cloud security. Having done cloud security podcast for almost two years with 40,000 downloads, and having endless conversations with cloud security experts around the world, one thing I've realized, we're going through evolutions of how cloud security is evolving. These are lists which are applicable across the board for the moment, irrespective of if you're using infrastructure as code or not. But now we're at that generation where a lot of tools like checkoff from bridge crew and other tools which are going into the space of infrastructure as code security where the DevOps is transformed into devsecops and the security alerts are being captured right in the beginning when it's being committed into your source repository or your code repository. So do check them out as well. But this is a great place to start if you are someone who may have a combination of complex environments with a bit of infrastructure as code, and bit of automation and bit of click Ops. So definitely check these out and obviously ask any questions if you have any. In conclusion, I have a few truth that I wanted to reveal. You definitely need both continuous as well as point in time assessments. Continuous assessments are great from a monitoring perspective, as at any given point in time you don't want to wait for a hypothetical ashish to knock on your door and hey, let's talk for the next two weeks and see what we can find out when you're done. Assessment you need something ongoing so you can monitor for configuration drifts. So you definitely need something like a CSPM, or probably even something better than a CSPM if you can design it on your own. Talking about designing on your own, the challenge with open source tools, if you do go down that path, like the example that I gave you before, open source tools are great, but they also would not cover all the new services, which means you need to have some skill set in your team to either add and contribute into the open source so you have the new services available and someone has spent the time to understand what is a security requirement for a particular service that has been released. I would also ask if you are engaging an auditor, definitely understand if they have an understanding of cloud, because let's be honest, running an assessment on premise is not the same as running assessment on cloud, where a lot of compute can be ephemeral. You may have instances right now, but the IP changes because the instance went down and a new ip came up and it has been auto scaling or dynamically scaling up and down. So you need to have an auditor that understands that context because you don't want to go into a compliance audit without realizing the truth behind whether they understand the environment in order, whether you are in this exercise going to spend probably a lot more time than someone who just understands cloud and know what to do when you tell them, hey, I'm using this service from this cloud service provider, and that's why we comply with this requirement. What do you think? They should be able to give you a reasonable answer, which makes sense to both you and them as well. So I would say the other approach you can take, if you don't find one of those auditors and you probably are stuck with someone who doesn't run internal assessments, call in someone. Again, it doesn't need to be someone who has tools, that people have been creating the community, but at least they have an understanding of what the cloud infrastructure should be like, and they understand what kind of common security services from the cloud service provider you can use to pass your assessments. But at the same time, what are the gaps that are left behind by using those cloud assessment tools which are provided by the cloud service provider? Last but not the least, the one truth that I want to give away, and that's quite bold and underlined, a successful compliance certification doesn't really mean you're secure. It just does mean that you were able to convince an auditor that you are ticking all the boxes. So I would ask you to be honest yourself with an audit now you know what the truth behind doing an assessment from an auditor perspective or a practitioner perspective is. So I would hope you would make the right call and find an internal assessment by your team or by calling an external auditor, maybe even build some tools of your own and some checklists of your own which are relevant for your organization or your industry, and use that as a baseline for calling yourself secure. Or I guess, as secure as possible, because no one's 100% secure. That's what my conclusion for you would be. And one final thought would be find your trusted advisor to get a real picture of risk in your cloud environment. I hope you learned something from this. So if you have any questions or feedback, feel free to reach out to me on that website. But otherwise, I just wanted to say thank you for inviting me for this talk, and I am looking forward to some of the questions that come through for this. If you're someone who enjoys cloud security content, I would definitely ask you to just check out cloud cloud security podcast. Well, but otherwise I would see you, but in the wild. But thank you so much for your time, and I look forward to talking to you soon.