 Yeah, so as Mike was talking, it's kind of hard to manage access to Cloud and see who has access and everything. So in this talk, we're going to talk about kind of like some of the security best practices that I've learned working at Microsoft, and then like the tool that my company created. So we're going to start with a little bit about myself. So I'm an identity security engineer with years of experience creating identity and PKI services for Microsoft, and then after a few years decided to leave and co-found Keto's where we create PKI services, easy to use PKI services to kind of make the world a password less place. And then there's my Twitter handle. If you have any questions, feel free to send them there and also send them into the Cloud Village and we'll answer them at the end. And here's a picture of me outside. Since I didn't know we were going to talk about rowing, I wanted to show that sometimes I go outside too. So let's start with something that we can all agree on. Humans suck. Like they're slow to respond when there's an outage. They get hacked because they don't follow your recommendations and they can't scale. What do you... They don't follow your recommendations. So they will still go on Facebook. They'll still click that phishing email. And why? Because we're humans. We make mistakes. They can't scale. We can't go all the way to Cloud Scale and having hundreds and thousands of machines. As Mike was saying, like automation is taking over and we should take over. It doesn't make sense to people still going in and clicking through and creating VMs. So we have to try to get them out of the equation as much as possible, but also understand when we're designing our security policy, they're not going to be perfect humans having, doing everything perfectly, like count that they might choose a bad password and help them do the right thing the easiest way. So in this talk, I'm going to start by first talking about like kind of like the cloud best security best practices. Going to go through each one of them. So I'm not going to read them out right now. So first one is keep management identity ideally to zero. So Mike in the previous talk was also talking about PIM and just in time access. So it's something we're going to talk about. But the first thing we have to do is infrastructure as code. If you don't have the humans go in and click through and everything, and they don't really have to go to the portal as much, it'll make it easier for them to not have access to the infrastructure and harder to hackers to get in when humans don't have access. And the way to make this is making it easier for them. So one of the things we have learned at Keto's is that one of our most visited sites is our docs page where we talk about how to deploy cloud VMs with already SSH certificates in them. The reason for that, it's easier to just go to one site that has all the information than to have to go and figure it out. And if that information has the best practices, then your users are just gonna follow the best practices. So incurred arm templates, terraform templates, Pulumi templates, whatever your organization uses to make it easy for the user to do the right thing, maybe create some with the ports closed and all that stuff. And then as I was saying about just in time access. So one of the things that just in time access gives you is first of all, you don't have access all the time. So it makes it a little bit harder to scan. And it also gives you the ability to have dual key approval. Dual key approval helps because then you need another account compromised and you need to convene someone at Microsoft we had to do with that. Like I would go in person or like call my manager and be like, Hey, I need access to this. Please approve this, which is very hard for a hacker to be able to imitate that. So having dual key approval, having some policy that the user has to actually talk to the other person will really help mitigate some of the attacks. And the other one, it also makes it hard. It makes it hard to get into the infrastructure, forcing people to do the first thing that we were talking about infrastructure as code and automate some of the stuff. If it's gonna take you a while to get in every time you have to get in, then you're gonna find ways to automate yourself out of it. And then we have talked about how we're trying to get out of it but you also have to have a strong identity. So one of the things that we do at KITOS and many companies do as well is having a completely isolated identity. That your email identity is gonna be compromised because you're checking email, you will get phished and bad things are gonna happen to that account. You use it a lot, you enter it for multiple sites. So the user is kind of like train the password and move on with their life. So if you create an isolated identity that you only use for production. So you're only using it in AWS or you're only using it in Azure. That kind of helps your users only think that that identity is for that and it's harder to get phished. So something to keep in mind that you can have two different identities. And those identities should have MFA. Nowadays with cloud, there's no reason you shouldn't have MFA. I'm a big fan of FIDO and PIV and Ho for Business because I worked on some of those technologies or because it's the best way to work with, for humans, like it's way harder for a human to remember a 20 character password and have 400 different passwords for all their accounts. But it's very easy for a human to grab their UB key and plug it in and get access to enter a pin and get access. So it's way easier to remember and it's a better user experience. I actually prefer having this and typing six things instead of having to have a big password and cell phone. And the other one is you can do conditional access that I'll cover a little bit more in another slide, but basically it allows you to have, if the user hasn't logged in in a while, like ask for MFA, although I recommend asking MFA for each time. And if the computer is not compliant, you can block the access. And then as I said, humans are always gonna try to find a way to get in the lazy way. And one of the ways that they do that is creating a service principal, a service account with a password. And then they can set the password whatever they want. So if you set up all the MFA and everything, they can still set up a password and bypass that. So have some policy that you cannot create with passwords. And also you shouldn't use passwords for service to service. Certificates are out there, use PKI. And the last one I wanna talk to is remove VM passwords. So most VMs in cloud like AWS and Azure and GCP will come with a default password that you set. And it's like a local account. Make that, automate that in your scripts when you're creating, that it's just a random password that no one has access to. And don't use that password. The reason for that is you don't wanna have a shared account. And also the engineer that is creating the VM will have that password. And if they leave or in the insider thread, like they can still, when you're saying your Azure Active Directory passwords or basically they need to provide their passwords to access your VMs. And there's a lot of tools that do it, like you can domain join your machines and for Linux, there's many tools we actually create in Keto is one of those tools. So there's a lot of tools out there that you can use. And then the other one is keep your network closed. I don't know why everybody decided that it was okay to open all the ports. Maybe it's about earlier that it's just people don't, like before it was like the network engineer making sure that the firewall and everything was closed and now everybody has access. But from going from like completely firewall to being completely open, we should still keep just necessary ports open, be very strict about your IP ranges. So no, your whole corporate doesn't need access to manage your VMs. Like your management port should probably be closed all the time and maybe have some IP addresses. And same with service to service authentication, not all services talk to each other, just have the specific IP addresses of the services that talk to this specific service have access to the service. There's no reason to have a completely open network. And then networking JIT, so that goes back to the management ports. So Azure offers this networking just in time access, which means that when you need access to the port it's always closed, no IP has access. And, okay, sorry. No port has access to the machine. And then when you need access it will just request access for you. I got a hurry up here. So I'm gonna keep going. The strong device, so a strong device. So you manage your identity, you secure your identity, you do all this great things for keeping your identity secure. But then if you have a device with malware they can still store your token and do stuff like that. So you have to have your device manage, make sure that they get scanned and they have proper policies. So you can see for the me, my prefer Intune is way easier than AD GPOs and it's cloud-based and easier to manage. And you can use conditional access based on this device's health. So if the device has been scanned and everything they give you access. If it doesn't, it'll block access even if you have the correct credentials. And then currently we use isolated device for production. So this is something that some companies do. It's kind of going in the extra mile but we're an identity security company. So we go the extra mile. That you have a completely different device that you only access production with. So you have your dev machine that is where I'm presenting this. You have your email and everything actually touch the production. You have to open another device and log in with production identity. So your production identity is always in that device. So a compromise to this device wouldn't give access to the device identity. And the last one is use cloud tools. So you have the Azure Security Center that will help you with compliance and help you with some stuff when you're moving to the cloud that you might oversee. Like, hey, you left all the ports open. You should probably close some of the ports. The other one is manage service identities. It allows you to manage your identities for you. And this is all Azure. I would mostly use Azure. So all my terminology is in Azure but most of these cloud providers have the same. So you just have to translate it to your cloud provider. So manage service identities. The cloud provider will manage the password for you. This makes it hard for a user to get at the password and use it. And it also avoids outages such as bad password rotations or anything. So using manage identities is great for availability and it's great for security. And for the passwords that you can use that you should use Azure Key Vault, KMS, any of the password vaults that will allow the services to access the vaults and you can rotate them and have all your policies to do all that stuff. And once again, if you make it easy, put some code samples out there and be like, hey, this is how you get your passwords from a Key Vault or this is how you authenticate with the manage service identities. It makes it easier for your developers to use the right tools and instead of them having to figure it out on their own and also makes a better experience for the security team. I always thought that security teams should, people should come out with security meetings instead of with more tasks to do, with ways to improve. So they look forward to those security meetings instead of dreading like, oh, I have to go to another security meeting. So let's see how we get delayed this time. And then I already talked about PIM, NetworkingJet and Intune. So those are some that I already covered in the talk. And then monitor everything. So you should have your SIM up and running with alerts Azure Security Center. It has some alerts, and then turn logs on every service. Even if you're not reading all the services, you have to turn on the logs just to have forensics. If something bad happens, you wanna be able to go back and look. So don't save those extra few dollars, turn on logs on every single you run. And also run your own custom alerts in code because some of the things they get through infrastructure, but one of the things that we did great at Microsoft was we had some trainings that said everybody had to do them and we would talk about security. The Red Team would go up there and say, like, hey, this is how we get in and this is how you guys can stop us. So then like the engineers are aware of it. You write different alerts in here. I have an example of one that we actually write. We have, I'm not gonna show exactly what we log in where this is, but somewhere in our code, we log this and the engineer on call will get a call saying like, hey, someone is trying to mess with our APIs. Let's track that. So basically, if you follow this, we solve security. You'll never get hacked. No, I'm kidding. This is just, this is not a silver bullet. These are just best practices. And that's the thing. Even if you follow all this, you can make a mistake. Something's gonna happen and that hack can still get in. So I'm gonna talk about some of the backdoors that I've seen people do. And then I'm gonna talk about CloudWatch for a tool that we have created. So the first one is adding, so if you have your groups that are echoed, like you might have like your engineering group and that group gets hackled into your subscriptions. If you add an extra member in there, it's a group that you don't check the membership that often. So having that extra member will give them access to all the stuff your engineers have access, but you won't notice. Having an administrator. So this, once again, Azure specific. Classic administrators was a way of doing things like four years ago, we have been trying to facing them out since then. And now they have moved them to another tab, which is great, less chances of people creating them. But it's also harder to detect when someone adds one. So if like a hacker adds one, it's harder to detect that there's one and that they have a stack. Another one that I used to love when I was doing pen testing is adding a service principle as a contributor to the subscription. And if you put like the employer somewhere in the name, no one wants to break the deployments. So no one is going to touch it. So something to make sure that you're keeping track of and usually deployment has contributor access because you have to create and delete resources. This one is more developers being lazy that it's removing the Azure Active Directory authentication only. So they might want to create a password for SQL and just use that instead of their Active Directory account. So having that checked forces them to use Azure Active Directory. Add more permissions to IKV. So this one is if you have all these different permissions like let's say a developer only has list permissions but it doesn't have get. If they get the get permission, now they can steal the code, the secreting use it. So keeping track of that is kind of hard because when you're looking at the keyboard, you're like, yeah, they should have some permission. So that's about right. Then adding IP addresses to a firewall. This one is one match when you have like a long list of IP addresses and you just add a one. They might be a developer being lazy, maybe a hacker from else trying to get in. So catching one is kind of hard. If you have, if they try to remove the rule or something is easy, but catching one is kind of hard for a human. So we created a solution that kind of monitors all those back doors. And it's basically a PowerShell module that runs in Azure Automation. You can get it from the Azure PowerShell Gallery. It's all free. We basically used it internally and decided to open source it. Like we, this is not one of our products or anything. We don't make any money out of it. We just wanted to share with the security community. Scans your subscription and detect any of the configurations changes that I mentioned and alert to if a change has been detected. So in here you can see no changes have been detected. This is kind of like a run that would be fine. And in here we show one that it hasn't been detected and we have it that it fails the run book whenever something is detected. And then we set up an alert that when a run book fails, it calls our own call engineer. So in here you can see we added some stuff and it failed. So what it covers, our break changes. So if something gets added to the RBAC or it'll detect it and let you know because production access should be very monitored. Classic administrator changes. So we'll alert if a net classic administrator has changed. Azure resource provider changes. So this one is Azure resources get access through Azure resource providers. And they get kind of like automatically added to your subscription, but you can create custom ones. So for example, like one of the ways that I like explaining it is like the Azure resource provider for Key Vault has access to the VMs so they can encrypt the disks. So it can give you some access to the resources. So we just like to keep it clean. So we added it for monitoring, research creation of deletion. These might seem a little bit harmless, but if someone adds a VM that then they're using for tests, but it's not production network and then that doesn't get patched, it can be a way in later. So it's important to keep everything clean. And also if someone deletes something in a production subscription, you should be alerted because you don't know if it's something that happened by mistake. And all of a sudden you're one of your ability sounds is down and you'll eventually have a disaster or something. So it's important to keep track of that. Change of group members, we only do nested groups. Sorry, we don't do nested groups. So we only do first degree. So any group that is echoed anywhere in your subscription will monitor the membership to make sure that nothing has changed. SQL Firewall changes. So if a firewall rule gets added, a single IP or something will do. SQL Server, AAD admin changes. So as I mentioned, if they like uncheck the AAD only or they change the admin group or anything, will alert Azure Key Vault access policy. So once again, those are the ones that I talked about that like changing the, how many permissions you have into the, Azure Key Vault firewall changes. So I'm gonna address the elephant in the room. Maybe a few of you might be thinking like, he already talked about cloud tools. Why isn't he just using Azure Security Center and like Sentinel? And the reason is like those don't cover all the stuff. So we use all of those plus this. So we have all our detections and everything but this is more kind of like making sure that nothing has changed because Azure Security Center is not gonna alert you if someone adds an extra person to a group that seems pretty normal or if someone has an extra IP address that's something that might service got a new IP address or something. So this one we keep it just because we wanna make sure that everything we get alerted and we know if something changes. So now I'm gonna talk about how we set it up. This is a great picture of how we actually set it up. And then here I kind of make it easier. We just have one cloud watcher in this one what every subscription would have a cloud watcher watching in the other subscriptions. And you have your production subscription in this case that is the one we're watching. You have a cloud watcher in this subscription that ideally has different identity management than the original. So like you don't have the same administrator so a compromise in one identity doesn't compromise the other one. And then you have the baseline in the different subscriptions. So a compromise in this one doesn't compromise the baseline which this one only has read app. And we actually keep this one in a different tenant, a whole different setup. But so yeah, so this one will read the baseline which is basically a JSON file then it'll compare it to your resources. So what's next? The next thing we wanna attack is create a UI to visualize the resources and kind of like alert on certain things that might be a vulnerability. So like we would show kind of like all the resources and say like, hey, like it seems like this is very open. You should check that. And that will help us because we think security reviews don't like all diagrams. So like having something up to date that you can actually use for a security review and actually being based on the scan of your subscription instead of what you think the service looks like will help a lot with the security. Then add more resources, as you saw right now it's kind of limited but we're a small company that doesn't use many types of resources. So that's one of the reasons we're open sourcing it. If you wanna use it and you wanna add your own resources please feel free to make a pull request and add them. And then the last one is we wanna integrate with Pulumi Terraform and all the other providers to be able to match the baseline also to your infrastructure as code to make sure that nothing is changing from your infrastructure as code to the actual console. And once again, thank you so much. Here's the link to the GitHub project. Here are the slides and I actually also created a set of videos so make sure to check that out. I'll just go through the whole things of how to set it up. And that's it. I don't know if there's any questions, Jeff.