 Welcome. Thank you for being here. My name is Eran Bibi, and I'm the co-founder of Firefly. Before that, I was the head of DevOps at Aqua Security. And I have a lot of experience with writing infrastructure as code, I think, from the last seven years. And I have few lessons learned that I would like to share with you. I only have 10 minutes, so I pinpoint those only to three lessons, focusing on security. So the first part we'll be talking about state file. State file in a nutshell for anyone that doesn't familiar is one of the components that involve infrastructure as code. So the state file being used in order to the compiler, for example, the Terraform or the Pulumi, to map the infrastructure into the actual state of the cloud. One of the pitfalls of state file that is contain a very sensitive data. So in most of the case, you are putting the state file in a remote location in order for the entire DevOps team or developer to work together on provisioning cloud resources. But you need to be alerted that if this state file be exposed or a third party have a scanning capability on the place that you are putting your state file, for example, an S3 bucket or some data store, the third party might be having your either access key to deploy stuff on your AWS environment or your database credential and in other cases, have the certificate. So a state file is something very sensitive. It's a clear text file format in a JSON. But you need to make sure nobody have an access or at least have the option to read that file beside the infrastructure as code compiler. The second lesson is about infrastructure drift. So drift is a state when the actual configuration on the cloud diverge from the stuff that you planned to be that's sitting on your source control. And this is something surprisingly very common. You are deploying infrastructure. Everything is aligned. Your code is basically reflect the stuff that you have on the cloud. But over time, because a lot of people have access to the cloud or a third party application have a permission to alter the cloud, you may find those differences. And in some of the cases, drift can be a security vulnerability. Let me show you an example. In the left side, we have a terrible manifest declaring a DNS record, a role for DNS record with a permission to list the DNS. However, over time, when I access the cloud console and I see what the actual configuration is, I can notice there is a slight change. It's only one line that said route 53 asterisks basically giving a full access to the specific role. So any service, any machine that have assigned to that specific role, if you look on the git, you think it's a read only access. But on the real life scenario, it's basically a full permission. The third lesson is about models. So models is a very easy way to use infrastructure as code. Instead of writing repeatedly the same lines over and over, you can basically grab something that is out there online on some registry on some public git repository and utilize it for your project. So the advantages of using models is huge. It's easy to use. It's out there. You can save a lot of development time because somebody else already written it. But it can be so, it can be malicious in some cases and also might include misconfiguration. This is an example of a Terraform model that exists on Terraform registry that basically giving cross-account access to the attacker. So the developer without the right tooling in place doesn't have the context that with those few IAM roles that this specific model is creating is also creating additional IAM role that giving cross-account to an attacker account. So it's very easy to make mistakes when taking something from online. If you are using model, you see only the line that having the import of the model, you don't see the content and you don't have the visibility or at least the typical developer that doesn't have the right tooling doesn't have the visibility to know that even if you're doing a small test and deploy it on a sandbox account, somebody else can take over this account and use it for malicious activity. To wrap everything up, few takeaways. For Statefile, make sure you are putting it in a safe place and have encryption in place that even if someone doesn't have access, is not able to read the file. Also, just verify if you already have a third-party application that's scanning your cloud, already have access to those Statefile and you should know that it's most probably that they have your AWS access keys and other type of sensitive data. For infrastructure drift, you have two options. Either monitor for drift, implement some drift detection tooling or to use something that will reconcile automatically the state of your Git into the cloud. This is a methodology more in the GitOps way. For the public model, just use one of those security scanning tools even for models and make sure nobody will have the option in your organization to utilize unauthorized model directly from the web. That's it. Hope you enjoyed the talk. You can find me later on outside and tomorrow in Firefly booth. Take care. Yeah. Thanks, Iran. This was really informative. I think we have time for maybe a question if anyone has any questions for Iran. Or maybe I have one question, right? So, you talk about this take-aways, right? So, do you see any automations, any tools that are already available to do that? Like, I see there are a lot of things scanning we can do on the static file. Yeah. So, yes, there is a few popular open source tooling for scanning infrastructure as code. You have TFSEC, you have check-off of Bridge Crew, and you also have tool that we wrote in Firefly called validIC.com and basically an online validator for your configuration. And it's very easy to implement using the CACD. I think you also need to make sure everybody is aware about this specific scenario of using model because sometimes a developer utilizing and not scanning because it's not going through the CACD, but you need only one time that you have some malicious configuration in your cloud in order to have the attacker option to access your AWS. So, it's very easy to bypass those scanning tools. Yeah. Thanks, Iran. Yeah. Bye-bye.