I am Sena. I am AWS Security Hero and senior cloud security engineer at Lirabar Studio. If you want to connect with me, you can use my LinkedIn, my Twitter and my medium account. Today we are going to talk about cloud security, securing the sky strategies for protecting against cloud hacking let's get started. First of all, we can start with why cloud security is so complicated and a nightmare for developers and DevOps engineers. First of all, there are lots of cloud providers in the market. Sometimes we struggle to choose which cloud provider is good and fit for us. In these providers there are lots of services that we need to learn and effectively use. Secondly, there are lots of product requirements in our company. We need to choose what is the best solution for us, what is the best solution for us to integrate the security with them. Product requirements can change quickly, so sometimes it's hard to detect security requirements and threat management between these product requirements. On the other side, actually, we all know there is a shared responsibility model for the cloud providers. Securing in the cloud and security of the cloud are the cloud terms are really important for us. Sometimes companies want to know what responsibilities they have and sometimes it can be complicated, analyze it all and get the best explanation. In addition to all of this, there are lots of cloud resources we need to use right now. You are going to use and you have lots of cloud resources in your cloud environment. You need to analyze all of them like unused resources, used resources that you need to remediate security findings. And this is a challenge for us. Depending on cloud resources, there are lots of attack surfaces in the cloud. We need to aware all of these. Like there are lots of endpoints, network environments, databases, AI services, iot services, blah blah. Attackers love using different attack surfaces, even if you don't know. And for the last one, there are lots of tools. We have lots of different tools and lack of experience in the cloud security. Sometimes companies get lots of tools to use, check the cloud security installs and configure them, and after that forget them. It's not the best way to protect the cloud. We need to know and use these tools and protect ourselves from the attackers. So we love the cloud, so attackers do. In this slide, there are some analytics about cloud security. It's from the Orca security report. Thanks to them for this. If you want to read them detail, you can see the report in their site. So there is a 91% of organizations have at least one vulnerability older than ten years and 46% of organizations have a vulnerability more than 20 years old. So it's important so what does it mean? It means we have lots of environment, we have lots of vulnerabilities and we have lots of old vulnerabilities and new vulnerabilities that we need to remediate. On the other side, there is analytics about the cloud malware attacks. So 38% of the cloud malware attacks are known the Trojans and for the malware by asset type we can see container storage bucket and the virtual machine. And these asset types are the most usage of the cloud. So we need to get a plan for this, for the containers, for the storage bucket and for the virtual machine, and the last one for the log for shell. You can see the numbers from it. Log four shell and the log 4G are some exploits in the recent years. So I can easily say it's important to protect the cloud with these numbers. For the recommendations and some points that we need to share, we can start with do not use public resources unless you really really need. What does it mean for your storage resources, for your container registries, for your publicly accessible databases, for your AI notebooks like Amazon Sagemaker? Please do not use public resources, publicly accessible resources unless you really really need. What does it mean really need? Like if you have a static website and if you have some publicly accessible photos in your website, it's fine to share in the s three bucket publicly. There is no issue in here. But if you have some public resources in the s three and some attacker can write on it, it's a problem or destroy on it, it's another problem. Or maybe there is some large files in the S three that is publicly accessible. It's also a problem for the denial of wallet amplification attack. And also if you have some publicly accessible databases and publicly notebooks, it's also a problem. They are also a problem because we don't want to databases can publicly accessible and we don't want someone use our AI notebooks, Amazon sagemaker models in our AWS account. So the publicly accessible resources we do not use publicly accessible resources is the number one recommendation from me for the two. Be aware of resources. Yes. It's also important which resources, where and why? We need to answer these questions, how your architecture is designed. There are lots of resources and there are lots of like in the AWS. There are lots of maybe regions, maybe different AWS accounts. And we need to know and be aware of our resources and what are the possible vulnerabilities on it. Like your EC two ECs AWs environment that I mentioned. Maybe you have lots of vulnerabilities in your environment and you need to all of them. You need to know all of them. So what are the misconfigurations in your cloud resources? Like unused access keys, like publicly accessible s, three buckets, like cloud trail that aren't enabled yet. All of it are the misconfigurations. And we need to follow and aware and check all misconfigurations, maybe daily, weekly or monthly, I don't know. It depends on your company. And what are the endpoints? For the endpoints, there are lots of endpoints like EIB endpoints, like lambda functions, like API gateway endpoints. I don't know if an endpoint is an external, this is an issue for us and this is an attack surface for the attackers. So you need to know what the endpoints are and they are vulnerable or not. And for the awareness. Actually there are lots of tools in the CSPM cloud security posture management. CSPM, it's not enough, but it's a good start for your posture management. Like you can get your security posture score, you can get general visibility of your cloud environment. Like for the CIS benchmark, what are my paths, what are my fails for cis Azure benchmark, what are my failed ones and what should I need to remediate them? This is a good start, but it's not enough. We need to do lots of work to protect our cloud. So for the other one, please read the documentation. I know that reading the documentation can be challenging and unwanted stuff for developers, for sometimes the security engineers, but it's so important. Following the documentation ensures that security features are configured and configured correctly. And sometimes there are some additional security features in the documentation and if we don't know it, we cannot enable it. So reading the documentation is very important in this point. And maximizing protection against threats, again, maximizing protection against threats is important for us. And the cloud engineers are updated on the Neve security features. Yes, that's why I'm saying and best practices and maximizing the use of documentation minimizes reliance of external support, saving time and for your resources. So please read the documentation whenever you see an AWS service, Azure service, whenever see a security service, maybe compute service, database service, it's so important. Yes. The other one get alerted from everything you need. Alerting is most important in the most important thing in the cloud I think, because there can be lots of anomalies in your AWS account, in your Azure environment, whatever you are going to use. And there are always some class resource threats. There are always cloud resources, configurations, chains, and we need to follow all of it. Like what are your anomalies? What are your cloud resources threats? What are your configuration chains? Like if someone, if an attacker gets in your AWS account and creates a new IM user for herself or himself, it's very dangerous for us and we need to be aware of it. So we need to get alerts from everything we need. And also getting alerts is an issue. But after getting the alerts, we need to have a plan for the alerts is another issue. Yes, we got lots of alerts. And if we do not analyze them, it's another issue because every alert should be analyzed deep dive. And if someone or something is bad on your cloud environment, you need to be aware of it. With these cool alerts, even if false positive alerts, you need to analyze all of it. And with the alerts we need to monitor everything. Yes, I am sure you know it, but again, I want to say it, we need to monitor everything because the constant monitoring enables early detection and suspicious activities or anomalies in our cloud environment. And the timely monitoring allows for rapid response to security incidents like there is some anomalies in it. And if we monitor it, there is a fast solution for this security incident. And also monitoring provides valuable insights into emerging threats and attack patterns. And also monitoring some resources helps control the cost anomalies and prevention of unnecessary expenses. So it's important to monitor everything. So the encryption we know the encryption we need to encrypt everything. We need to dance like no one is watching. Encrypt like everyone is. Encryption in transit is number one, encryption in rest is number one. Following the best practices in the encryption usage encryption stage like what is the best encryption key for the asymmetric encryption? What is the best TLS version for my HTTPs on the Erb? Like we need to follow the best practice for it and also follow up the cybersecurity work for encryption changes like TLS 100 and zero is not secure anymore. SSL version two is not secure anymore, something like that. Follow up cybersecurity word for encryption changes helps for us and the other stuff be open to change. I love this phrase. So I want to add in my presentation the most dangerous phrase in English languages. We always done it this way. This is the best dangerous phrase because yes, you have always done in this web and it's the most dangerous thing in your cloud environment. So it's important to be open to change open. Maybe you need to change all architecture, maybe you need to change your containers, maybe you need to change the code, I don't know, but it's important to be open to change and please do not use a phrase like, we have always done it this way and we didn't hack for ten years, so why do we need to change it? It's too dangerous. Please do not use and always be open to change for everything, for your architecture, for your code, maybe for your team, I don't know. It's important point for the cloud security and also for the teams. I believe you shouldn't isolate teams because everyone needs the security, marketing needs of security. Cloud security needs to security developer needs the security and each team brings unique skills and perspectives to the table. And if we do not isolate the teams, this improves the visibility across teams and helps identify and address security risks more efficiently. Maybe some developer knows about the architectural, maybe some architects in your team knows about the security stuff in your EC two. And if you don't isolate teams, it can be very helpful to solve things, to mitigate things, and to find a solution for the security incident. And also it avoids the duplication of efforts and resources, because if one team looks at a vulnerability, for example, if different teams isolated different teams, different teams analyzes the same vulnerability, it's a duplication. And for the efforts and for the resources, we don't want that. So please do not isolate teams in your company. And the last one, think what if. As a security professionals, we always think what if, what if I get hacked? What if someone gets my credentials from here? Think what if an attacker gets here and do this and do this after do this and after do this, what should I do? Considering the potential scenarios in their impacts on the cloud security posture and identify the vulnerabilities and weaknesses before they can be exploited. Always think like what if scenarios. Dive ongoing security enhancements and updates with your team. Like do not isolate teams and think always what if. And after that, I think with these recommendations, with this to do list, I think you can protect your cloud environments from the attacks and you can increase your visibility in your cloud environment. So that's it for my session. Thank you for joining me today. Again, this is a recording session, so I cannot get questions, but if you want to connect me, you can search from the LinkedIn, you can search in the twitter and to my medium, I write some blog posts on it. You can follow me from here. Thank you for joining me today and see you soon.