 Hi, everyone. My name is Henry Cannabelle, and this is my session, How Do You All the Clouds? In this session, I'd like to cover a number of different things, first is base planning and understanding for your cloud adoption needs. The second one is to establish common security issues for your teams and organizations that you support, or for yourself as you're deploying your workloads onto a cloud environment. The third is recognizing your stakeholders and partners throughout the journey as you're maturing your process and adoption of your cloud environments. And finally, where the focus of this conversation, I'd like to have with you is to introduce security tools, insights, and perspectives. I am going to presume that a lot of you are not as familiar with how to really take advance to the cloud. And so we'll talk about some of those things and what kinds of tools that I want to share with you that could really help you on the journey. So some quick information about myself. My name is Henry Cannabelle. I've been a security architect for the last several years. I've been a security professional for five plus years. I come to you as a former developer. I used to develop with C and C++ and Java about 10, 15 years ago. And now I kind of do Python on the side or as part of my role as a security architect. One of the hats I like wearing is I'm a data security specialist within my company, within my team. And so for now that the potential role of a logs are really sounds kind of fun to me. Location-wise, I'm from the area I live now in LA for the last few years. These are a few of images that I like to encapsulate my personality. So our target audience for today, I wanted to address the IT professionals and engineers that are deploying compute workloads, either through cloud functions or containerized applications or even just straight up VMs to deploy, you install software onto it. I'd also like to help address the security professionals that are not as familiar with cloud and how to provide them to enable them with better tools as part of their advisory roles. So what's the plan for today? To first address, I want to clarify for everyone that I'm not trying to target a cloud migration strategy to go through the details of why you should or shouldn't go move to the cloud. I also don't want to focus on the workload planning of how you migrate your applications from traditional software to cloud, take advantage of cloud tools and services. This is also not an incident response or application security type of talk. However, I do want to focus on the various cloud security challenges for the organization. When we talked about CMMI, that stands for the capability and maturity model integration. It's a traditional framework for application and software development. I want to apply it for cloud adoptions. Thirdly, I want to cover how for your teams to get started in securing your cloud adoptions more effectively. Fourth, I want to provide some strategic and tactical recommendations for the audience and finally, provide some tools and solutions to help you on your journey. So when we talk about general cloud challenges, these are pretty much the four pillars for any organization, for any type of projects. You'll get security and general, it's pretty straightforward. You'll get the governance privacy control, your compliance programs, your legal teams, as they are your consultants or consulted or your informed constituents and stakeholders. Thirdly, we talk about interoperability, how to deploy your systems and applications to work efficiently and to collaborate effectively across multiple cloud platforms. The idea is to focus on the ability to support a multi-cloud provider environment for your enterprise. And finally, that sometimes creeps up with you would be your cloud spend management. Either for security or non-security purposes, your finance teams are heavily interested in how much you use your cloud platform. Focusing on security challenges, these are a number of different areas that I've discovered and have learned and worked with over the last five to 10 years. The first one I want to emphasize is the sprawled cloud accounts and also the adoption of multiple cloud service providers. Oftentimes you have a lot of users that just, I have an idea, I want to push it up there and this group concept. And you have over time, a number of them, hundreds of them, maybe thousands. The second area I want to focus on is at least at a high level is premise configuration and the adequate change control. You're talking about you're protecting your environment. When you enable your IT professionals, your sales engineers and other channel engineers, they can build their own environments that like to be running their own virtual data center. There comes some cost in terms of operational overhead. How do you enable them? Third one, I talked about attribution. I want to make sure it's when we talk about attribution and we're talking about account ownership, points of contact, if you're in some response, pretty much effectively providing a reliable identity and asset management for a number of people that need to triage the instance, for example. And so with the rest of them, they're effectively around visibility and control of understanding how your projects are being managed and deployed within your cloud compute environments. In the end, how do you make that visible for a number of people more than just your engineers and professionals that are running, self-servicing their own cloud service needs? So when I talk about the cloud maturity model integration, this framework has been traditionally focused on application development and deployments. And so we can talk about these by different areas. Initial, managed defined, quantitatively managed and optimizing, most environments, when you're deploying software, it's pretty much again like proof of concept thing to all the way to something that's really snazzy, something that's really taking advantage of cloud environments or to take advantage of their software, the tech staff. So we want to adopt this to cloud as well. So when you talk about the cloud adoption journey, we have these areas as well, projects, deploying projects, typically that means a proof of concept. I have an idea, I want to run it somewhere else. I don't have a data center or maybe I just want to stand up really quickly and show that we are capable of running an application in a new environment. When you talk about foundation, it's pretty much like a lift and shift moving it over that you are using cloud, it's not your data center anymore, but the application is really aware, it just still kind of runs properly. And so you're pretty much the basis of your enterprise applications. When you're talking about migration, we're talking about how much of the application has been moved over much of the dependencies on your applications that are using cloud services, but the application may not necessarily be aware of it. And finally, reinvention, rebuilding the application itself. So these cloud and migration strategies, I just talked about lift and shift, refactor, rebuild in different ways. Lift and shift is typically when you have your application workload, you're still leveraging, you're minimizing the type of changes on your applications and moving towards, moving your legacy systems and applications. And you're not really taking advantage of cloud, moving it to a new virtual space, if you will. And so with each of these come with varying levels of flexibility and effort for a reason. For lift and shift, this flight's very low. You just want to pre-match walk your software into a new environment from the data center or some other data or some other cloud environments to a personal one to something that's managed by the IT organization, but you're not really changing much. When you're talking about refactoring, that's what I'm mentioning about back in this slide about location, where we talk about refactoring a little bit into using new tools or new backend software, for example. And then rebuilding when you're actually taking advantage of things like auto-scaling. And when you de-scale this well, or a strong password, we have a KMS that the provider uses that you're not using something a little more dynamic and can be with your compute systems as well. So it takes more effort to put into it, but at least it fits all your flexibility needs. So when we talk about CMI, that's where I want to adapt this for cloud adoption, where I see proof of concepting, where that's where I talk about here with projects. Early in the stage, it's part of the initial adoption of cloud services. Then you kind of go through the gradient of becoming until you're optimizing and really taking advantage of cloud services. For this talk as well, we target the audience and the trajectory for where are you typically? And for this talk, I want to focus on the stage from foundational to migration when you're from lift and shift to refactoring. What are the things that you need to take advantage of? One, when you're leveraging along these cloud services, do you have this ability to it? Can you see it? Can you extract the left information and centralize it for areas or tools that you use already? So when we talk about security, there's four different areas you want to protect. So with your infrastructure, your applications themselves, your data and your people, keep in mind, because these four topics, things are very important for especially privacy teams from legal or compliance teams, your IT teams, and then your engineer. So covering a number of different bases. So for security clouded options, as the security professional, these are the 10 different things I look forward when looking at the objectives and how you're protected and how do you be more cloud specific? And so I'm not going to go through all these in particular, but the first two at least just basically taking advantage of cloud. It's really easy to stay and be dynamic in a cloud environment. So you have to match that and how do you have to build that in early? Once you've done the lift and shift, how do you update and aggressively challenge your processes? So next few slides we're going to kind of, I'll just kind of blow through them really quickly since it's focused in a cloud environment model. It's always shared, but shared security models. So you talk about who's responsible for what on a cloud platform. So as I mentioned before about people, data, applications, infrastructure, there is a breakdown. And so it's all the responsibilities for the cloud provider, but a lot of it is on the organization using, you as a customer using the platform. So when you talk about multiple cloud services, here are a number of different tools across the different software services, cloud providers, AWS, Azure and GCP are the three top most ones. And so you break it down into compute services, database services, storage areas, network and services. Here's a number of different, when the products for each service, for each cloud provider. From a security perspective, specifically these are the different areas that you would want to focus on for each types of cloud service. You bring back to the stakeholders, as I mentioned earlier, here's a further breakdown with including the common descriptions and common roles. I leave it to you to check this out either here or after the presentation. So when you look at protecting your environments, I like referring back to technology tools and processes. The technology refers to the capabilities of the technology, the CSP provider, or pretty much what do they offer natively, what types of features and capabilities, like auto scaling is a simple example of it, or some sort of IAM store, credential store. In terms of tools, what do they offer the CSP itself or other third party providers? And thirdly, in terms of processes, what are your own processes of your solution of management of solution? What are areas that when you manage the environments, what are your choke points in? You need to cost them and also identify how to improve them. So in terms of simplification, I want to focus on the tools. That's why I mentioned a few times on this slide there. The hardest thing is to identify the biggest pain points and also how to optimize them. So there's a number of different talks in terms of DevOps that really focus on optimizing inefficiencies. And so when you programmatically target those, it's a lot easier to scale out your operations, your time, pretty much. So when you talk about tools, I pretty much have this basic formula, build versus buy, and then time to operate that helps define your TCL, your total cost of one mission. From a strategic recommendation perspective, I want to provide a number of different areas that help you drive success. You want to work with, you want to enable visibility for your organization. You want to run tools more easily. You want to expand coverage for the different tools and the different services that you're leveraging. We also want to make sure that you extend your current capabilities for tools, your skill sets, in terms of tools like SIM, in terms of Cornell, and you have a number of people that are your SysOps. You have particular strengths in different areas. Optimize your time pretty much. Other areas for consideration, I list over here. How you, what are your dependencies? Some of these tools are the apps that you maintain. What kind of support levels, support models are the offering? Do they have a premium model? So you can try before you buy things like that. For common cloud security solution, I categorize them to these three areas. These themes are pretty common when you talk about migrating to the cloud. These are three different type of security strategies or solutions to monitor based on the different types of activities or usage of it. CWPP, you're focusing on your workloads. You can talk about containers or cloud functions, how they're often they're being executed, from where, how, who's triggering it, access control, things like that. CSPM, I focus on generally, I talk about posture management and that mainly focuses on configuration and your surface area. TASV is another one. A lot of providers focus on file handling and exposure and sharing, for example. I like focusing on access control and reinforcing those types of policies. Other things to also consider for modern considerations for cloud, modern computing workloads. One of the things I feel is understated when you talk about DevOps. One of the biggest folks for that is infrastructure. That is infrastructure as code. However, when you talk about infrastructure as code, now you're exposing your infrastructure. If you misconfigure an API resources that may enable certain attack vectors, but if it's infrastructure, then you're talking about exposing entire services. Port range is a simple example of it. The second thing I want to make sure everyone understands is that most, if not all cloud service providers, they presume their default configurations and wizards are not safe by default. The Azure and GCP and AWS, when you go through training, they focus on the ease for the IT professional or any professional to stand up for workload, but they are sure to always correct themselves and saying like, don't use a default. So keep that in mind. So tactical recommendations for this, the rest of the talk, I want to focus on research, tool discovery and how you can attest or stage your progress. In terms of research, I provide for the rest of the talk, it's pretty much providing you a number of different links so you can research and kind of review these types of tools on your own in different talks. If you're new or not as comfortable with cloud security and you need some ideas, what does it entail? How do you discover new tools? How do you discover new perspectives? I would push towards, these are a sampling of different websites. One of my favorites is TLDRSec. Every week he sends a newsletter and compiles a number of different tools across. It's targeted initially for the application developer, however, for abstract purposes, but they also cover a number of different things. So container security, cloud security, vulnerability management is pretty much the entire gamut and so you can listen to a number of different tools. So it's a wonderful resource. Another one that I recommend is the Stony Blitz, his repo, my arsenal of AWS security tools. He also built a tool called Crawler. So it's pretty good stuff. So it's very exhaustive, a number of different resources, tools, code scanners, all these different things that are mostly open source. You can try yourself. AquaSet, they offer a premium type of products, but they have wonderful content regarding how to train and really understand cloud security. And so I gave you an example here with their cloud security scanner. There's a number of different links that they have to cover the different topics. So I highly recommend those. And the last one I do want to share with you is Chaos Monkey. While it's not specifically security, Netflix has been in the game for cloud adoption for a long time. They've identified a number of different problems, strategies, deployments, and they want to share a lot of their tools. Chaos Monkey is an old tool that was focused on this concept of chaos engineering. If, how do you build more resilient processes and tools? So if part of the environment goes down, your service still runs properly. And so they've extended that to Security Monkey and then Security Gorilla. To do a lot of this is a detection and remediation of things that are bad for your environment. So check this out. The other thing for research I want to emphasize is the attack vectors, the different types of attacks on your environments are completely different than data center. You've seen AWS misconfigure a certain setting in, taking down the half the web, half the internet because a lot of them were using S3 as part of their web hosting. So that opens a new kind of forms. The minor framework, I'm just going to focus on leading these two here that they've adapted their attack framework into two ways. One of them is for adapting for cloud specifically and two instead of standard attack, from the attack perspective, flip it over for a defend. And so there's a link for that. So you can see how it kind of pivots and how you can defend your environments as well. So other areas of consideration, these are different tools I mentioned earlier and you can leverage them over here as well. For tools, I want to share with you CSP cloud service provider that are native to those platforms. CSP has two tools I like. One of them is a generic link. The other one's for asset inventory. So they have a quick way of identifying all your assets. I'm more familiar with AWS. So config and audit manager rates. The IM analyzer is also pretty snazzy. There's a number of different checks from the credit reports, the IM credential report that you can also port into different tools that AWS uses. But the IM analyzer is free of charge and you can analyze and verifying all the different aspects. So there's different ways to set, determine your identity and entities. Here's a number of different open source and closed source tools. I've listed a lot of these different tools to kind of recognize each other as well, kind of in a message fashion because as you realize, not every tool can cover a lot of things. So let's bring in a lot of them. So here's an example. One of my favorites is ScoutSuite. It can scan multiple environments. Let's see if this works. Oh, no, it doesn't. Here's a link I can provide. If you go to the ScoutSuite, this link should animate itself. And so it basically builds a report. And so when you run it, it can create an HTML page and you can look at the different checks. Faces off for AWS, you have a set of security checks policies that all assess against the configuration that's specific for the cloud and for that provider, but also they look at it from CIS as well. So that's great. I like using it for multi-cloud environments. Prowler is the one I mentioned by Tony Blakes. This is also a Linux based one to run and it has a nice UI as well. And lastly, I want to talk about simulation. One of the biggest things when you adopt new tools, adopt new cloud environments, it's really hard to recognize. I did all this project. I did all this work together. I defined policies. I'm integrating and tightening up my security groups. I reduced the number of publicly accessible services or storage. I encrypted my backups and my snapshots and my attached volumes. But how do I verify it? Or how do I test my tools? And so these are a number of different tools that I think would really help you kind of scale based on different use cases, based on different, if it's specific cloud or even you want to extend it to Kubernetes, for example, for applications potentially, or how do you stand up environments that are sheet-bad by default? SAD Cloud and Terragilter are two examples of those that you deploy poorly configured environments. Then you can test your detection tools. If you scan, is it tracking it properly? And so I highly recommend those. The last one, Flows Up Cloud should be awesome for you. That's kind of like a CTF. You can actually test it in practice, your skill sets, improve their skill sets and also challenge yourself of understanding when I see this, how do I detect it? Or what do I look for? That's pretty much it. So a lot of different, yes, I tried throwing two in a quick 30-minute call. Hopefully it's not too much. I want to make sure that you guys have enough information to look back and kind of review what you've learned, how to best partner with, if you're an IT professional or an engineer, work with your security professional or if you're a security professional, understand more of the different tools and how to assess cloud if you're not familiar. So it's about synergy in the end, working with your organization. So in the end, I want to make sure that you're enabled with tools and understanding what different processes and to effectively work smarter, not crowded. So I'll be online, obviously during the talk. Thanks for having me. Thanks to the Blue Team Village for everything. If you have any questions, get me up. And there's a few other links in the appendix as well. Thank you.