 So, this was just the context setting of what we discussed here and what we want to do right now is talk about the mechanisms and controls that AWS has developed to achieve design security postures for the workflow which are running on AWS and that covers multiple area. So, let's start with one of the very important thing that, you know, needs to be taught through from an initial guardrail or initial set of perspective. So, the question is, which is the most secure place on the earth, the secure system on the earth is the system that is never built. Right. And what do you do when you build something the first thing that you build on AWS is you essentially create an account. Right. Now that's that essentially is the first border or the first guardrail that you need to think about right from the account perspective. Without going too much into detail of what AWS organization is my point here is two fold a very often and I'll be sharing more of what we also seen in the field at times. We have seen that some of the best practices that needs to be followed in terms of segregation of duties right we talk a lot about it and it's actually start from the account structure perspective right. We have seen environments where part of a production and dev are running into the same account. And by nature of it right by fundamental nature of the need of the development team versus the need of a production system they are very different. The production has to be more hardened production environment has to be more controlled. The dev team needs a better flexibility right they want to play around they want to maybe spin up some resources in a region where there is little less cost. Why not I mean you know most of the enterprise would want to it's okay to do a development maybe in US because the cost of resources are less I mean there are many reasons for that but that's can be one of the reason. But you may have some data locality or some other needs which wants you to be you know placed in in Mumbai. And so what happens is separation of duty starts from the account level perspective. The first point want to make is have a clear plan when you're starting off, or if you don't have one that is always a good time to start thinking about how to structure your workloads from an account perspective. When you're thinking about that, what you get is a very good, you know, set of service from AWS organizations which helps you define those account structures and create necessary guardrails. Many breaches are that we have seen or many of the areas that we have seen the concern happen is actually can be completely blocked out by means of a service control policy. Why even have a mechanism to detect something when you can actually prevent it from happening in first place. That doesn't mean you'd still don't have a detection. I'm not saying that. The only thing I'm saying is, let's have very strict control in terms of what can something be done in a specific account perspective so that's that's first point I wanted to talk about. Going to the next is once you have those account setup and you log in and you kind of see okay I've got like 170 to 190 services in my menu right how do I think about securing them. That's where we said three fundamental things is important. You need to start thinking about how am I going to, who am I going to give access to and where are my user identity going to remain that's an I am that's the first level after the account. You think me to think about what my data would look like and where all it resides that's the data encryption. And of course, your network perimeter. If you are using native services, you know how are you deploying them we are deploying within VPC outside VPCs and what is your network layout and VPC layout looks like, you know subnets, the guard rails and some of those things so these are the three important aspects to look into. Once you look at those three important aspect. What we have also seen is okay before I go to that point when we talk about I am under pattern that we have seen I like to share here is that imagine you had a AWS organization structure right. You would might have created like at least three account one for dev, test and product. Having multiple identities in each of these account can also be a cause of over permission or mispermission or a misconfiguration that can happen. What we recommend is using AWS SSO very few people know that AWS SSO as a service has an inbuilt directory service and it doesn't cost so that you can use that to manage the credentials, but you need to be careful over there a little bit. You know having multiple identities at even in AWS SSO and then in I am it's again an operational overhead to manage them so a little discipline in terms of when I'm creating users how am I accessing them. Good thing about SSO is is let's you create something known as a temporary tokens. So it takes away one of the attack vector, which is you know long term credentials. Developers would definitely want to play and when you create an I am users you would have access key secrets key you take them you play around with them. And what if my endpoint got compromised right essentially that's one of the root of compromise. So not having a long term credential is a good thing. That's what you do with SSO. And then there are few services which where you need specific long term credentials you need to have a rotation policies around that. So that covers the I am and the SSO piece but again be careful multiple accounts having both the strategy in place. Well you can do that but you need to be try to minimize in that case having number of I am users and have, you know, all the users on board it from SSO. While I do that, I cannot stress any more importance of securing the root account. It's super important we all know that but again, it's a matter of, you know, the execution rigor. You know, it is it's super important that in theory we always say that and if you ask if you take anybody from a security organization and they'll say do you use root forget I mean AWS root even on the Linux terminal right. People don't log in as root they use to do when they need it they escalate their privilege to do certain things and then they do and then come back that's where you have to do a list. When you have that discipline in not giving logging into your system as root. Why would you even want to log in into an AWS account as a root. Right. Only when we have those conversations I think people get the point. And especially this is for the people who are starting up their journey. It's super important that your root is essentially locked out you delegate your billing also to an administrator or a separate user have a separate billing role and do that. Root should be a break glass I would say that it or rather not even a break glass a break glass for a break glass. If that is if I have to put it that way. Never ever should you be using root users, you know, use multi-factor authentications and then there are different best practices around how we manage in case of a permission model. When I come to this. It's also again important that when when implementation happens right implementation happens from different perspective so where a provisioned account from it is from a partner if you have done a self provisioning some of those nuances do impact how do you want to structure accounts and that's a separate discussion but yeah it does has a little bit of an impact on how do you want to think about the number of accounts and structuring them. The next thing that we are seeing is once you have your account structure defined you've got your users and identity taken care of you then think about two aspect right my network aspect and my data aspect right and let's quickly talk about data. Now, this is a common trend that we see. First of all, I will recommend, you know, audience to definitely go and have a look at a data classification, a white paper that is published from AWS, but summarize the same thing here. It's more important that, you know, if you have to have an ability to answer these questions. Okay, where are my crown gels, what is important where all my data resides. Okay, who has access and what level of access to particular data, right, what controls I have deployed or what controls will I require to meet my compliance need that beforehand thought process is important. Even if you have a workload that is running, it's always a good time to take a pause, think through understanding where all your crown gels are or not even crown gels, it can be a different data sets which may not be super sensitive but yeah they still need to be protected. So, nonetheless, also knowing what is where does the public data sets right resides important is it in S3 is it in EBS volumes. Maybe it is residing in your database and there are different databases people use right that on many places that the data sets can resides and and when we talk about the data sets here. I'm talking of two datasets. A is the customer data or application data. Your infrastructure related data is also super important. We talk a lot about infrastructure as a core. So, where is your infrastructure templates, whether it is a cloud formation or a terraform templates, where are those templates stores, are your credentials stuffed into those templates. If so, you know, a visibility on to that. Where are those credentials stores. This is about provisioning of the infrastructure. The first one was about the user data. There is one more type of data. That's your operational data, your application logs. Where are those logs. How are you, what is the sensitivity of the law, you know, data that the application is logging. Oftentimes, we see that application might log an information it might log a PI data right I mean. What is the masking strategy over there you may need it for data lineage purposes even you're doing a log correlation but you still need to have a mechanisms from a logging perspective for how am I logging my data do we have. Do you have a common framework for logging do you have common format in which developers so you know, in a microservices world you will have all different teams doing their own development but it's always good to have that enterprise wide standard guidelines which says okay beat any application these this is a format in what I want you to log your application logs because then that helps you. You know do correlation, and I'm sure you know, many times I have talked, you know, to different team members from a security operations him and one of the biggest problems challenge that I have seen and I've myself done it for a couple of large banks implementation. And, and the question that comes is, okay, we want to have a, you know, a centralized sim that's that phone to build, but the challenge comes is we are fine with logs because you know apache logs are an is log they have got a standard log format. The challenge comes when the application logs comes in, right there is no standard format over there. And then if you have to do the correlation that becomes challenge. I see developers may be logging some very sensitive information and other things. So, classify the data from these four data sets, and then, you know, it's time to move ahead. What the next question that comes is okay I know where my data set I have done my classification but should I encrypt should I not encrypt what should I encrypt. Well this standard answer and the best answer is to that is encrypt everything encrypt data in motion encrypt data in rest, anyone encrypt data when you're using it. And, and there are different set of services from AWS that helps you achieve each of this set in all the three stages. Be it, you know, your tls at albis and and points where you want to have HTTPS encrypting data volumes and s3 buckets and in your applications, we mentioned you know how often I have seen, and I can tell you a couple of reviews that we do, and we often see that database credentials are stuffed into easy to we all know that. So the question is this right if you ask somebody a question they will say no that's not a best practice but hey it's there right. And that's again, you know repeating the same thing is implementation rigor. It's implementation rigor it's it's doing the validation and I think the previous session we're talking about red teams right things some of these things I'm talking about should be on the radar of the red team. They should be looking for these things they should be looking for, you know, data from an application logs, logging PI data, you know, the credentials been put into a configuration files or maybe, you know, an easy to instance lying here and there. These are the things, as you start thinking through this right it also gives you a good input or use cases for the red team to run through. Right, or maybe when you're just doing a validation within your own environment. It's important to run through them. Another important thing that I've seen in the environment and oftentimes is that people tend to get a little confused in terms of server side encryption and use of the MS and I'll keep it short but I'll still want to mention that. So looking at your defense in depth from a data perspective a first of all control who has got access from a rule perspective. Don't access your data directly you don't need to go out from the internet and then enter this as to bucket and this is an example of STM talking here. There are VPC and points. The same is for your dynamo DB or other database that you're using again in multiple, you know, discussions and things that have come up is there, there have been misconfiguration of route tables for another input for a red team. Look at your route tables. They are very important. So people will actually tell you is it something what you think it is from a network path perspective and it's important. Once you look at that, you know, we want to have all those traffic goes internally and not out from the internet. Having a bucket policies like resource based policies and identity based policies have a good resource based policies. And the third and the most and the fourth one which I'm talking here is about KMS. When we say server-side encryption, what happens is my data when it is at rest is encrypted. Right. But if for any reason, my key has to get compromised. When I do that, when I get an access, what I get is the actual data because you know it's it encryption is the rest. But when I'm retrieving it, it's decryption give me the data. And that's that's lies that's where lies the power of using KMS based encryption. What you do as a best practices, you do not give a rather you separate out the roles from an IM roles perspective who has access to the decryption keys in the KMS. So if there has to be a breach for so-called children happen, but even if that breach happens, whatever the the adversaries gets is encrypted data. They still don't have access to the encrypted data. And this again is a very, very important thing that we talk a lot about when we are, you know, talking to the teams and going to the workloads is that use the separation of duty. Have a separate encryption keys, assign a very strict rules on that of who can actually decrypt that. So in case if a developer or something if you know there is a misconfiguration or there is a credential theft that happened, you're still data is of no use for adversaries who have taken it out. So this is what I want to recover from a data perspective. So three things we had right we had an account structure IM data and the network piece now I'm switching to the network part. When you talk about network protection, what aspect of network protection we need to think about and these are the questions that comes to mind right how do I protect the network. How do I filter the network traffic or basically have a visibility in my network traffic. And that's where it starts you you start with your VPC design. When I talk about VPC design, there are again two parts to it. When it comes to productions, don't use. First of all, delete the default VPC. That's the first rule of thumb, delete the default VPC right create your own VPC have a very clear network architecture of how we want the traffic to flow. And you have done separation of duties for my production Dev and test environment. It's okay if you peer your Dev and test environment, because you want development freedom over there or people we want the same set of people are working on both that's fine. Don't link it back to your production environment, keep it different. Once you have done that, have your clear segregations of security groups and knuckles and some of those things. Once you've created them, remove the permissions from an I am for anybody to even go and change that why there is a need for somebody to go and change the security group. We have seen use cases where, you know, people have written automation around detecting a change in security group and then remediating it. But what if I can in first place not even allow it to happen. And if you have those permissions and if you've got an organization block it at a CP level. Once you've done that, and you've got your base architecture hardly. Now comes your application and you know you want to protect the edge. That's where the set of services that comes, which is AWS WAF. Another common pattern that we see is WAF is seen as a, you know, you know, super thing which will protect your all the web application, which isn't the case right until you why there are two parts to it. So while you have deployed a WAF and AWS gives you a set of standard rules, right, the standard set of WAF rules which are there, which covers your apps and some of the best practices. It takes care of that cross-site scripting or SQL index and the standard patterns over there. But essentially WAF is also about having a mechanism where you block some of the, or you have some rules which blocks the traffic, which are not considered normal from your application perspective. That's where spending some time in understanding your application is important. What kind of URL pattern looks normal? What kind of URL patterns looks fishy? Get into the observation mode, look at those patterns, and then create a block over there. Another area is where you've got, you know, a lot of zero-day vulnerability from an application perspective that happens, right? And especially for so many are using an open source libraries, right? There are like, I've been a Java developer and I know when I use this Mevin file and, you know, people tend to import everything from a Mevin central, which is fine. But how many times have developers gone and updated those Mevin central config files to some of those, you know, libraries? The famous one of 2010-11 is the Struts framework. It may not be relevant now here, but it's still important to know that, you know, those libraries can have breach. The most relevant ones will be the Node.js libraries. You've got NPN modules, developers would use NPN modules, NPN import, and use those libraries, right? Those libraries essentially have vulnerabilities. So while you check about those vulnerabilities in your DevOps pipeline, but what if there is a vulnerability that is detected and you want to block it? Use WAF for that. And the reason I'm again emphasizing on WAF is, WAF is not just set up for default rules. You need to understand your application, your usage pattern, your application libraries, and some of those things. Once you do that, there's next layer of defense that's, WAF is at layer seven. If you want a higher level of defense at DDoS attacks that happen that layer four, three, four, that's where the shield, AWS shield comes in. And then you've got Firewall manager to manage all the rule sets for managing each of these things, whether it is WAF rules or a security group and NACL groups, or also a network firewall. Again, that's a new service which is now live in Mumbai region. So essentially, if you have to do a deep packet inspections like, you know, IPS or network IDS or network intrusion detection systems, if some of those use cases you have, you can use network firewall. There are different architecture patterns, you know, distributed patterns or single pattern based on how your workload looks like. You can deploy that and then write a set of rules. You can in fact import your Nanasuri cartas or some of the open source rules into this and then, you know, look for any specific signatures of patterns that you want to put as a guard really in your network traffic. So this is essentially what comes from a network protection perspective of what is available. There's another thing that we discussed from a previous session is my detection charity. So these, what we talk is about, you know, the account structure, the IAM, VPCs and networks. So we laid the foundation and we are fine. And it's more like a preventive control setting up the baseline. We talked about that. Another thing, another measure which is about detection maturity. And this is a famous slide from my colleague Lalith. And I really like the way he takes it and he says, fair enough, that's how the detection maturity looks like, right? So detection maturity, A, no logging. So I think that's where, you know, people have to spend some time within the organizations and go application by application because what happens is, certain application may be really good in terms of saying, oh, so this is how it is, right? The CISO team or a SOC team will have centralized logging. And if you ask somebody, do you have centralized logging? Yes, we do have. It's a tick mark. But how many of your applications are onboarded onto those application logging infrastructure? That's the question to ask. Tell me how many applications are actually onboarded? If they're onboarded, have you done data classification? Have you got a common log format structure where you're able to correlate and see for any anomalies that is happening in the system, right? From no logging to native logging and monitoring, which is available from AWS, but which is more of an infra level, right? So if you've got, you know, VPC flow logs, you've got cloud trail, cloud config, so many things that you can do from a monitoring perspective, detect any configuration chains or any event that happens. Any signals, maybe from any C2, we return a matrix in terms of utilization, those metrics we are referring there. And finally, we talk about event correlation. We have got maturity, we have got all logs coming in. Event correlation, again, classification is key, standard data format of an application site. Once you have got that level, that's where I will say more of a role of a red team will start coming in. Are you doing threat hunting? Are you looking? Do you know, even before we do that, do you know what a normal looks like for your application? When you have got your application running, what does a normal behavior look like? What is the user journey, right? We talk about user journey only from a use case perspective when you're building it. But I think when you are looking it from a security perspective, you also need to look at what is the user journey or what is the interaction of the user from a system perspective, right? Go through that and understand what normal looks like. Only when you know what the normal looks like, you will be able to create baselines. Once you create a baseline, you will be then able to look for anomaly, right? You will also be able to identify what comprises indicator of compromise for me. If there is a compromise, what is an indicator for it? Because I know my baseline, I know this is an anomaly or this is an indicator of compromise. I can build my library of IOCs. Have those libraries of IOCs in your system and then kind of go through the different mechanisms to see if you are able to exploit. If there is any vulnerability, go and fix them. And finally, the last step is where you are actually able to deploy deception technology. This is all what is there from a detection maturity perspective. And the final stage of all of this is all about loglines. How many loglines are you able to correlate and analyze? And that's where the next slide comes in. Is this one? I know it's a little heavy in terms of the content, but it's important because it gives you a single view of different loglines that can come in. You have got loglines that is coming from your instances, from what is happening at an infrastructure level from a cloud trail. You've got a network that is flow log that is coming in. Each of these services kind of move into, say, a guard duty, which is basically a network infrastructure section and something more than that. It uses a machine learning to identify anomalies that is happening in your account. If you've got AWS organizations, enable it at an organization level so it gives you visibility across your account. Use these config inspector. These set of services, all of them, they're feeding to security hubs. You don't have to kind of look at each of the services. And from security hub, what you get is also an important thing is there are multiple top party or ISP products if you're deployed. They are all to our checkpoint or any of these, right? They have got adapters. Again, I'm coming to the standard logging format. They have got the standard logging format that feed into the security hub, which essentially gives you the ability to kind of correlate, aggregate, build alerts based on your cloud watch. And if at all you have to push it down to your sim somewhere, you can use those flow. This is one of the references. There are many ways to implement this, but I just wanted to say that, okay, multiple loglines detection can only happen of what you're logging in. Imagine in this case, right, if I am not logging certain aspects. Say for example, I'm not looking at the configuration trip, which is AWS config. I'm not looking at the configuration trip, right? You would not know where the breach has happened, right? So I think each logline has got its own relevance in terms of which area of compromise you want to look at and then correlate and have an action table on that. And that's where, you know, finally you will have an automation of how you want to respond to that. The response thing I think we also mentioned in the previous session, the maturity to do a response. First variable to identify. And the moment you identify what is a delta from the time that you identify that something has been reached to the time you're able to respond. And that's where the automation piece starts coming in. Just to summarize the last slide that I have here, across these domains, these are the set of AWS services. You don't have to start using all of them on day one, but definitely each has got his own relevance as you start maturing in your adaptation. But yes, the fundamentals, which we talked about at the beginning, the account structure identity data and network. That's how you start with and then you kind of expand from there based on the use cases. That's all I wanted to cover from a slight perspective and open for Q&A. And that was quite a comprehensive guide to using AWS and imposing security on AWS accounts. We have Rashid Feroz today from Craig. Rashid, I would like to ask you, what are some of the best practices that you and your team use for AWS security? What do you think startups could learn from common mistakes that you've seen in the industry with regards to data security? Definitely, Anvesha. Thanks, Ravindra, for very comprehensive coverage on AWS security. I would not talk about what Ravindra has already talked about because that covers the majority of the best practices aspect. I would want to talk more from an implementation and practical angle where, as in, I've been working into cloud security day in and day out since the last four years and Craig has grown a lot from a very small company to a mid-size org in the last four years and I've seen a lot of challenges. So I would just want to highlight some very basic and important points that we have to take care of. So when we talk about securing our cloud or AWS, it actually depends on what maturity level the org is in currently and we need to keep this in mind that we can't achieve 100% security in a day or even in a month. So it is a security implementation is always going to be a continuous journey and it takes time to build a culture of security within the team, within the org and align everybody else. This is the right way to do things. So apart from that, I think we also need to understand the shared responsibility model of AWS as what AWS is responsible to secure and what you are responsible for. Having a good understanding of these concepts would actually build a groundwork for people, for security teams, for defenders as what they would want to do. Now to sum it up, I would want to talk about few of the points that I've noted down. So considering that you're starting from scratch and you have almost no clue as how to go ahead with securing your AWS account, I would suggest get started with the basics. So while creating your architecture, take the help of experts for AWS Enterprise Support Team to start with the security best practices. So when there is already covered on that, for example, enable all the relevant logging, enable SSO, enable RTV, set up alarms, etc. So in the engineering world, we often talk about tech debt. Some backlogs is what I'm referring to tech debt. So similarly in security, I would also say we also have security debt that I would want to talk about now. So as your company grows, your architecture level security mistakes are going to come back and haunt you. And after a certain point of time, if you have not done things for the best practices in mind, you're going to try to fix it via some hacks or patches, which is not as per the best practices. Giving a very simple example, not creating different AWS accounts for different purposes. There should be different accounts for UAT, different accounts for fraud, different accounts for debt. This is the best practice. If you have not created these three different accounts on different AWS accounts, then it's going to be a problem for you going ahead. And then migration would again come with a separate set of challenges, changing the VPC structure, etc. Again, another example on the similar lines would be not enabling SSO for logging, creating individual user accounts for employees. It's going to be a huge, huge pain later on. So to sum it up, my point is basically what I'm trying to say is keep focus on absolute basics and fix it from the ground up. If you don't have much clue about it, read AWS Security Best Practices White Paper, read AWS Well Architecture Review White Paper published by AWS, and you will get enough data as what to work upon. That was the first point that focused on the basics. If you don't know where to start from, there are enough resources given by AWS itself to do as what to do with the best practices. The second thing, what I've observed is, as Raminder already said, that you need to up your prevention game from start. For example, if you look at the data breaches happening around S3 buckets, which is a storage unit, getting public, going public is a major problem. Now, if we enforce SCP, which is Service Control Policies, using AWS organization, that nobody can make any bucket public within my org. Now, this is also a big problem that nobody can make your S3 bucket public. So you don't have to keep an eye on the detection aspect of this, that if somebody is trying to make the bucket public. So if you try to up your prevention game from start, build guardrails using SCPs or using restrictive IAM controls, I think that is going to make your life easier. But on the same side, you don't have to loosen up on the detection game as well. So my point is, if you up your prevention game from start, the detection is going to be easier for us because you'd have lesser points to cover. Another thing that I have seen is a lot of times people do not give enough importance to protecting their keys to the palace. So when I mean keys to the palace, I mean AWS IAM access and secret keys. So again, after analyzing all the data breaches that has happened around, even when companies have followed best practices, a big chunk of those data breaches has happened because of access and secret key leakages. There are tons of ways they can get leaked, but we should give enough importance to protecting our keys. Instead of running behind fancy buzzwords and tools. So there's a lot of hype in the security industry, a lot of fancy tools coming up every day and day out with AI and ML and whatnot. But we need to again be grounded and focus on the basics that we have to protect our keys. So a lot of steps you can take for this, right? For example, minimizing the use of keys using roles instead of access and secret keys, setting a boundaries where our access keys can be used, upping the detection game if by chance any access keys get leaked. So this is one of the important points I would want to convey. The last thing I would want to say is when you are acting as a defender in any org, you should never stop thinking like an attacker. And the moment you stop thinking like an attacker, you start doing stupid things. For example, somebody might be placing hard-ported credentials in an environment variable somewhere in Lambda or EC2 or something like that. Because you have assumed that you can't be breached, so I can go in a hacky way and do this. So if you have assumed that you will never be breached, you will keep doing stupid mistakes. So that's why you always have to keep your guard up and assume that one day you might be breached. So one thing that has really helped us here is periodic threat modeling of all our ground jewels. For example, let's talk about threat modeling of data stores. So all your customers' data is in some data store and periodic threat modeling of the data store has enabled us to uncover any of the risks that we might see and fix it. For example, you can do threat modeling around access control. What is the access control policy of that data store? Who can get access to that? How do they get access to that? Can they extract sensitive data? Can they not? What am I trying to protect? Can I monitor if somebody is trying to extract data out of it? Is it encrypted? Are there backup policies written up? Is the logging and monitoring on? So when you try to do regular threat modeling around your data stores, around your SSO or access control, a lot of such things, you would get an understanding from a darker perspective as where things could lack. So again, here you shouldn't copy someone else's cloud security strategy. That's not a good way to do that because depending on the scale your org is and what business you are in, your priorities might differ. Some things might be right for you, some things might not be. So keep doing threat modeling, identify the risks and fix them. This is a repeated process. So just to sum it up, the first thing I would want to say is the first point that I talked about is that if you don't have a clue if you're starting from scratch, then start with the basics. Go with the security best practices, a lot of resources given by AWS to read and understand and also talk with AWS Enterprise support team. They're always ready to help you out. Second point I want to talk about is once you have implemented the best practices is that up your prevention game from start. Don't be in a way that I'm going to do it later, sometime later because again it's going to be a pain for you to implement this at a later point of time because there could be some exceptions coming your way. The third point I talked about is give importance to protecting your keys and take all the steps necessary to make sure your keys are secure. And the fourth point I wanted to make here is that never stop thinking like an attacker, keep doing threat modeling and uncover all the hidden risks and fix it and this has to be repeated exercise. So I think this is what I had Anvesha on AWS to carry.