 Very good afternoon to all of you. My name is Himansu. I'm super thrilled and excited to be part of root conf 2019 Little bit about myself I work with a fintech startup call us great. Our startup is based out of Bangalore, India And currently I am looking at security overall security for credit Previously I have worked with a few of the companies eBay Flipkart grab Mostly on building products platforms security I Have mostly focused on blue team I have also presented at some of the conference Nullcon cocoon grace super I do pass participate that capture the flag contest with a team call a six-fold and I'm part of few of the open source communities where I Actively get involved a little bit about my company. We are into fintech space If you use our app the current platform is based on credit card bill payments our overall Goal is to actually help Indian consumers improve their current behavior Little bit about our tech currently we have 35 micro services Which is close to six lines of code and we have 50 GB of data growing per day We are heavily based on AWS infrastructure and our tech stacks includes Java and Golan. So the aim of this talk is basically to share our learnings What we have done at day one For the whole infrastructure plus security Now this talk is not the end There are lots of things to be covered, but given the time that I have I'm quickly going to focus on three core areas of security data is a data security software development life cycle and infrastructure security Let's take data as the first thing As you know that data security is very important right now Currently if you try to look at the frameworks, they are none available So there's no right way to actually go ahead and do data security based on some industrial standard framework So we tried a couple of things at all in and it has actually worked for us And that's what I'm actually going to talk about today So there are various steps that we followed as a part of data security So I will walk you through the steps that we have followed On the step one corresponding to data security basically if you're trying to You know start with data security the most important thing at step one is to identify like what data you have at your company right so it could be in multiple forms for example for us it was cardholder data and PII Similarly for you it may be some design It may be the code that your developers or tech team has written that you would like to protect So step one becomes a very crucial step on identifying what exactly you're trying to protect So we went ahead and created a kind of mindmap So this was like a Individual exercise the mindmap may not be visible to you But this is a holistic view So as I mentioned that cardholder data and PII is kind of important for us We actually went ahead and did an individual assessment of You know what are the ways by which a cardholder data could be compromised right so Distributing into two primary buckets internal as well as external So there are multiple ways a cardholder data or PII could get leaked Get leaked from your internal sources, right? It could be your employees or somewhere from the tech Similarly on the external aspect, there could be multiple scenarios on which The data could be leaked from your AWS infrastructure Or from your database or from your application Or if there is some third party Right, so these are the These are the ways by which you can actually, you know figure out and do a mindmap sort of now. This could be This could be exercise which you could do independently based on what data you have and what are the possible ways you think that A data could be compromised right so Let's focus on one of the One of the one of the you know subtopic of it. For example, let's take infrastructure Right so infrastructure is very crucial for all of us because all our data is going to lie there and for us uh, we were uh AWS heavy infrastructure Within all the data lies on AWS. So we thought that let's focus primarily on AWS Right so on this exercise, we actually went ahead and laid out all the scenarios that could lead on to The Kalka data leak or PI data leak Right. So if you look at the slides here, uh, basically if you see the top few things that you think about um, maybe Say for example, uh, uh, AWS root key or your access key or security key gets Right. So, uh, that's one of the scenario where in a data could Other could be a street bucket say, uh, there are teams who are actually using a street bucket and You are doing some storing of card data over there and if it gets public the data could be leaked That's a similar there are multiple uh scenarios and all of this exercise were done independently Now if you think about, uh, the whole process right though, this is not a very standard typical process that you would go ahead and do Right. This is something very uncommon. Uh, and this is again a self evaluation So you are only saying that these are the possible ways, but does it end here? Uh, So the answer is no right there that you need to have a second level of view Second view of someone actually, uh, telling that these are the few things that you might be missing right so Once you're done with the individual assessment, you can go ahead and step to step three wherein you can actually talk to your tech team Right. So you also need a second view wherein I think that tech team are the best partner because they are actually writing the code They are designing the product. Uh, They may know better than what exactly you know, right? So you are only accessing based on Based on your knowledge, but there could be some, um, other corner cases which you may have never thought about So on step three when we went ahead and we did another exercise with tech team wherein we actually identify If you see the first column here, I'm not sure if that is visible, but I'll just zoom in If you see the first column over here, you actually list down all the data sources that you have I have two examples over here. Uh, so once you have listed all the data sources, you actually classify Whether it is the app data, whether what is the source of data or how do you classify the data would be right And then you go ahead and fill the rest of the column, right? So, uh, What data does your, uh, your app app doesn't have, right? So it may have some basic identity like phone number Right. And once you fill the whole thing exercise, you identify the impact, right? Now, there's no, uh, proper mathematical calculation as such, uh, because there there was no framework that existed, uh, at that point of time But we said that, okay, let's talk to tech team and identify like What if what if the data gets leaked from? Uh, one of these sources, right? What could be the impact? Uh, so we identify the impact And then based on the impact, we actually laid out like what are the details, right? You know, what could happen if the data gets leaked from here? Uh, so once you have identified the impact details, you actually laid out the remediation steps, right? What are the ways you can actually go ahead and, uh, remediate the whole, uh, whole impact or remediate the whole, uh, source from which the data could be So these are the, uh, these are the few steps that we took actually to identify, uh, you know, what are the bays by which, uh, data could be leaked. Now, this is not the end. Uh, we had done a bunch of other things Uh, but then this was a starting point for us, uh, to identify and ensure that, uh, all the data that we are having in our systems are, uh, securely stored and securely accessible to people Coming to the second, um Second thing, uh, which is SDLC Right? So think about, uh, starting a software developer lifecycle, right? So there are frameworks available Now, if you think about, uh, Implementing one of these frameworks at, uh, at day one on your startup, things may not work, right? Because, uh, Product and design are fast-paced, moved Each day, each hour, uh, your design and product is changed, right? There may be some business decisions and there may be some, uh, market decisions which may, uh, lead to change the design, right? So, for example, if I, if I think about implementing a NIST cybersecurity framework, uh, I may not be Honestly able to implement this at day one, right? So it requires a Very comprehensive effort, effort not only by a security team, but, uh, to buy in the entire company Similarly, uh, Think about a commercial solutions, right? There are lots of commercial solutions available Now, um, on the SDLC part, uh, take for example, static analysis tool, right? So, uh, if you think, if you think of buying a static analysis tool On day one and you go with a buy approach wherein you buy a static analysis tool and implement it It may actually solve some of the purpose, but then you would have lots of false false to deal with Right? And you would need someone who can actually Sit down, look at the dashboard or look at the tool and identify, uh, what are the problems or, uh, You know, what, what, what exactly is relevant out of that tool? So again, uh, this kind of doesn't make sense on day one at, at, uh, your startup So what, what did work for us, right? At day one So, uh, if you think about SDLC, right? So you don't think SDLC as a, as a framework which exists in market For example, there are multiple frameworks that exist in market, right? So the big companies like Microsoft have their framework Which is very, very mature, right? So it only works for a company which is very mature But a fast-moving company like us, uh, it's very difficult for us to think about, uh, Having a Microsoft SDLC in place on day one, right? So Now the key is to understand, you know, why exactly are you doing SDLC for whom you're doing, right? So you understand the end user, you understand the product and based on that You actually see like what exactly can can actually work for you Now I have taken example here the way you can actually start with you can go and talk to your team And, um, get a simple sequence diagram or UML diagram, right? So I have example here on On a sign-in or a sign-up flow, right? So come commonly if you see Think about a mobile app today Or the OTP sign-in and sign-up flow is very common, right? So you take an example of it And then you implement it over here, right? So you see the sequence diagram here It's a very basic flow, right? So in a flow you enter a mobile number Excuse me, the OTP is sent and on the second state the OTP is verified Now if you if you think from product perspective, right? So Usually the way it happens is they usually come up with a very unnatural number wherein they want a customer to You know, allow Making OTP attempts Say for example, 25-30 times, right? Because they don't want funnel drop on on top of the top of the product, right? So, but if you think of as a security guy, then their problem involved, right? So you may not you may not want to allow Uh The product to go with our 25 OTP attempt But you have to actually come up and think through what are the solutions about it, right? You cannot simply say that Hey, because there is a there's a possibility that people can actually go ahead and do force Let's not do this. You have to come up with something logical Excuse me So what you do is you actually think through it, right? So what are the problems that could happen and then Think through the designs that you can actually go ahead and propose Now there could be multiple solutions, right? You don't go to a product say that, you know, what is This is what I'm proposing and you should go ahead and implement So you go with a multiple approach scenario wherein you propose multiple approaches, right? So quickly talking about the first approach in first approach you say that Maybe in three minutes of time, uh, uh, a user can actually make a OTP attempt For nine times, right? A block of three in session one. He can make three attempts and then again on session two He can make another three attempts. So typically you are allowing Excuse me to make, uh, nine attempts, uh, in three minutes And then you can say that we can actually go ahead and block user for next 15 minutes Let's say this is one of the solution. The other solution could be Uh, you know, allowing allowing a very aggressive proposal when you say that, uh, for every three minutes I would allow a user to attempt OTP three times and then you actually go ahead and increase the time exponentially, right? So after three attempts, you may say that, uh, we want to block the user for five minutes or we want, uh, The whole session to be blocked for five minutes and then you can simply go on increasing the, uh, time limit On on each of these steps Right, so you go with six and then you go with nine and then you keep exponentially increasing it So this is one of the, uh, design solutions that you can actually recommend to your product team And the third thing is basically about the best practices, right? If you think around there are lots of best practices already available, right? You you need not, uh, Need to actually go and talk to people around, uh, for example, if you think about the android app or ios app Then, uh, there is already a best practice, uh, which is actually documented by google Um, maybe after the talk you can go through the link So all the typical things, right? Of on for example on day one, you may want to have a ssl printing in place Uh, you may want to have, uh Because you're dealing with lots of data You may want to securely store the data on your device, right? So all of these are actually already out there. You just need to go look at it and then See what exactly works for you, right? And most of the things are very easy to implement and this is something that you can actually work with your product team Your development team and then implement all the best practices as much as possible Because as as you grow and become big All of this best practices actually becomes a a backlog for you, right? So if you if you think about a mature company who is like a three years or two years old Either think about implementing ssl printing. It's going to be very very tough for them, right? So you start thinking on what are the things that you can actually do from day one in terms of best practices Right? So these these are the things that actually worked for us, uh on day one So I spoke about static analysis tool and given an example of uh doing a commercial solution, right? So we thought that this is something we can actually go ahead and solve for And what we did was we actually, uh, have done an in-house framework Where in as I mentioned in my in my first slide that uh, we have golang and java as our primary tech So there are tools available already open source tools, which are you can actually go ahead and integrate with your whole You know as dlc pipeline On the top left, we have go sit. This is for golang On the top right, we have find books. This is for java based On the bottom left, we have dependency check. These are to, uh Look at all the third party leverage that your java code may have On the bottom right, uh, I have an npm audit, which is again, uh, a javascript based audit, which is which comes with the npm package manager So you go ahead and integrate the whole framework now you have the control of What exactly you are trying to look at, right? So with this framework, we were actually able to See that what what exactly we want to focus on, right? So one of the critical, uh, thing on static code analysis is basically The pattern that we have seen over a while right now is, uh, the developer tend to make the same mistake For example, uh, let's take an example of sequel injection, which is very very common, right? So, uh What we have seen is that, uh Once we identify the sequel injection and the code has been determined by a single developer We have seen that the same pattern works actually, right? The same pattern has been, uh Founded multiple places. Now it actually becomes easier for you, right? Because you have the control over your framework You know that what mistakes you could happen. So now the framework actually allows us to, uh, do the whole regression Um, currently I will not be able to demo the whole framework. Uh Uh, right now, uh, the time taken for Is like 35 plus repositories can Takes close to half an hour because we actually, uh, independently do this whole thing wherein we build the whole, uh Repositories and we run our framework on top of it. We are working towards optimizing optimizing it And at some point, uh, we plan to open source this, uh, whole thing Um, if you're if you have time and feel free to check out our both outside to, uh, look for the demo We can do a code walkthrough after the talk No, the third piece is infrastructure, right? So As I mentioned that we are on, uh, we are in EWS. We are EWS. We have a EWS heavy infrastructure Now these are the key things, uh, that you think on the infrastructure building block Right? Something like you start with defense in depth. Uh, you you look at the identity and are back You look at the cscd pipeline You do the mounting logging and all of these, right? So I'm I'm gonna pick The first three part and I'm gonna deep dive, uh, in each of this how we did it What exactly has worked for it and what were our pain points and our requirements First about, uh, defense in the depth, uh, there are three key points The first one being AWS multi-account strategy So what this basically means is If you are on a public cloud You better have, uh, multiple accounts, AWS accounts from day one Uh, so why why do we need to have that? There are lots of advantages towards it First one, of course, being the billing, you have multiple accounts and you know, what are the resources consumption in each account? The second one being security Say for some reason one of your AWS account gets compromised be it stays, they were brought The last radius remains only to that account Unless there are multiple ways people figure out and then They actually, uh, Take over the other accounts, right? So This is again a best practice So what we did was basically, uh We went ahead with something called as AWS organization Uh, wherein you have a root account, uh, which is your identity account And below identity account, uh, you have multiple other accounts Uh, which is your child account. For example, currently we have five accounts They will stage brought, uh, as we're into fintech We have a separate PCI account and then we have a central account, uh, which is a common account And all the, uh, other account, for example, stays and brought Talks to each other only via central account And so this is again, um, the approach that we took so that, uh, things are pretty much neat, uh, from the D1 The second important part is the monthly layer, uh, approach wherein You actually segregate, uh Your DMG, uh, your public, uh, public subnet from The private subnet And then you identify like what are layers you want to have, right? So we had multiple layers for example We had ELB layer on the top, which was our, which was our DMG Then we had a web, uh, subnet wherein, uh, we had an API that we call as, uh, KONG And then below that we had a ELB subnet, which was a private subnet and All of these actually Talk to each other ugly, uh, via VPC layer Right? So you, uh, you define what security groups, uh, you need to have so that The web layer never talks to the Db layer directly There's always a layer below it and then Uh, that's how you actually go ahead and, uh, implement the multi-layer architecture, right? You segregate each layer from each other The third important part is lease privilege access So basically, if you think, uh, in a, in a, in a company, you may have multiple teams You may have, uh, business team, you may have tech team, you may have marketing team Sales team, right? So typically a business team is, uh, Is someone who would actually need a wage lease privilege They only want to, uh, look at some of the analytics, uh, tool which is based out of AWS and You basically go ahead and define policy for them, right? You define a role for them and you group it And based on that, you can actually segregate like What category or employee fall into and then what level of privilege that does he require Right? So you keep a very neat segregation, uh, based on the access principles Moving on to, um, our infrastructure than our back so, uh This was again a very challenging part for us Uh, think about, uh, think about a company, right? So on day one, you decide to go with a public cloud Say, for example, AWS was our case now Multiple things happen, right? So if, if on a day one, uh, you start or you create a AWS account And you start seeing with, uh, The founding people in your company After a week, you go and see the account Uh People have actually gone gaga over your account, right? So they would actually see You would end up seeing that people have actually gone and use, uh, multiple reasons To create the AWS workload You would see some S3 bucket, which is public and you have no clue what data that public bucket has There may be some other gentleman who thought that, you know, Jenny didn't want access keys not cool So he may go ahead and create two access keys So these kind of things happen, right? And this is beyond your control And Maybe after a week, the guy who actually ended up creating to a public key, uh, sorry access key and security Thought that this startup is not cool and he may leave the company with along with the access key and security, right? So These are the problems. So we we had some requirements in mind, right? So we wanted to have a single place wherein From one single place we can actually on board and off board people Having access to our infrastructure The other requirement was, uh We actually wanted to group it here, uh, based on what access people want to our infrastructure So we have multiple groups. We have deep group. We have tech group. We have sysops group We have secops groups. So you actually dividing groups And depending upon the groups, you actually, uh, define what access people actually need to infrastructure So we created that, uh Second was we wanted to have something like a SAML based integration, which in wherein, uh, Wherever there is, uh, there is some app that we are trying to integrate with We have a single place where people can actually go ahead and, uh You know, click on the app and then access the app without You without entering any username and password. So it becomes very simple if if you take this approach Uh, the other requirement was we as a security team, we also wanted to have some audit behind it, right? It should not happen that, uh, one of the AWS secret key or, uh, Access key gets compromised and someone sitting in a room and he is accessing your AWS account. So we wanted to have Uh, the audit around the whole ecosystem of, uh The identity and role-based access control Last but not least, we also did not want you to manage our on Active Bell Activity And as many of you understand that, uh The moment you have Active Bell Activity in your in your ecosystem The management plus security of Active Directory becomes a big train for all of us. So based on this requirement, uh We actually ended up, uh Using Okta which actually has worked for us And on Okta we have a SAML based integration to AWS. So as I mentioned earlier, uh, we have an auditory account and Once you, uh, once you once a user logs into Okta, uh, they actually land up on an auditory account Which is our root account. We don't have any resource over there, but it's like a jump account and From the jump account, we actually, uh, use our service call as AWS STS Uh, from which, uh, the AWS allows you to give us social-based token. So using their token, uh User can actually log into one of these accounts And so these are short-lived token wherein, uh The lifetime of token usually is one hour So in a worst case scenario, uh If the whole thing access keys secret key as well as the STS token gets compromised Uh, the attacker would have one hour, uh, to actually play around with things on infrastructure And I'll talk more about how we can identify all of these Let's say this was on the RBAC, uh, what we had implemented, uh, initially Second most, uh, the third most important part actually is the CACD pipeline, the whole CACD pipeline Uh, so we we had few requirements over here. One of them was we wanted to make make the whole CACD pipeline uh automated self-serve Uh, we want to give a flexibility to all our developers that, uh They could actually define how they want to You know showcase their service or how they want to deploy the service, uh on the prod So the whole thing was conflict driven, uh, wherein we have a simple, uh YAML-based configuration And based on that, uh, we use a managed service called as EWS pipeline code pipeline and The the config actually goes to code pipeline and from code pipeline on first step, uh, goes to code build, where in, uh The the code gets compromised, uh, the the code gets, uh, compiled And on second step, uh, the compiled code, uh, is actually dockerized So we use dockerized container management system, uh, and then based on that the whole, uh, cloud formation template is built Now this cloud formation template, uh is built on On the configuration, uh, which we had given to developers. So the whole thing gets built And what it basically does is it goes and creates a ELB or ELB depending upon what is required and then, uh, we attach our So we basically use EWS Fargate. So EWS Fargate is like a managed service from EWS, uh visitors the whole, uh whole country, uh, uh orchestration So, uh, this is how the CACD pipeline looks like for us now If you think about a typical CACD pipeline and, uh, the common thing that people we have seen people using is Jenkins right, so we We basically thought about not using it. The reason being, uh We don't we did not want to have the overhead of managing it right and The beauty of the whole pipeline that we have built here is the whole pipeline is, uh, role-based driven IAM role driven way, uh, at each step, uh The whole thing works on based on IAM roles and not based on some user going and triggering it Let's take a scenario where in, uh, the whole pipeline kind of gets compromised. It's so, uh Since I mentioned that the whole pipeline is based on IAM roles, the moment you a user actually, uh, Goes and tries to modify the code in one of the steps the role changes right and then I'm going to talk about EWS GuardDuty wherein Any sort of change would actually trigger a Trigger API call on EWS and that gets logged Right, so if you have proper, uh, monitoring system around your EWS infrastructure Then you can possibly go ahead and see like what really happened And EWS Fargate, the reason we actually went with EWS Fargate is because the whole thing is managed by EWS And if you see from security standpoint, the most painful point for me is, uh Think about a VM, uh, running on a cloud, right? So every time there is a VM running on cloud, we actually need to continuously monitor it In terms of whenever there is some new security vulnerability You need to go ahead and patch it, right? So patching again becomes a problem As you know that we end up in phintic space, there are lots of compliance given requirements and One of the things that that is required you to have is having some sort of Anti-malware antivirus on your systems, right? So again, you end up with buying another solution because you are at the end of the day You are not going to write your own device. You are going to buy it, right? So, uh Managing the whole thing actually becomes painful Uh, so this is the one of the reason that we actually went with Fargate when the whole thing is actually managed by EWS Including the patch management, uh, the antivirus, anti-malware, uh You know, uh, it's taken care of by EWS So this was on the, uh, CSCD pipeline Now, uh No, this is only internal, right? This is only a managed service, uh, which is actually we are leveraging, right? So we also wanted to have an Outside in view wherein we continuously want to monitor our EWS accounts, uh, from outside perspective Right? So we went ahead. We evaluated a couple of things And then we ended up on Uh, these many commercial products using being Uh, we thought of doing it ourselves and we evaluate a bunch of things For example, they are, uh, there are open source tools. Uh, for example, there is a security monkey from netflix which actually, uh Does the configuration, AWS configuration monitoring, right? Recently, they have actually stopped the development of it because they are coming up with something called as historical There is another tool called as packbot Uh, that is again from T-Mobile So they, they have open source the whole project and we did a POC with that as well Uh, the problem was the kind of resource that it actually goes ahead and creates Uh, was very costly for us in terms of, uh, the whole management Plus, uh Even the cost wise. So we actually evaluated some of this, uh, uh Commercial solution and has worked for us Cloud Confirmative to name, uh, one of them, Cloud Exploited So this actually goes ahead and does the whole AWS configuration monitoring and Since you are alert based on if there are any misconfiguration forms on AWS And the third thing is AWS security hub. This is still in beta and they have recently come up with, uh, the new product It actually integrates with multiple, uh tools, uh, commercial as well as, uh, show the open source things out there So, uh, we do use all of these to, uh, get an outside in view of our AWS accounts Coming to, uh, one of the case study, uh We did something, uh, good with guard duty so AWS guard duty is again a managed service. What they basically do is, uh You have locks from multiple sources in your AWS account. The first one being cloud tree locks So what are cloud tree locks? If you go to your AWS console Any sort of click that you do or any sort of API call that you make gets locked in a cloud tree The second one is a VPC flow lock in nutshell VPC flow lock is like a firewall locks So it actually has, uh, the data about which service or which, uh Which service in your AWS is talking, uh, to each other and how they're talking Whether the packet is getting dropped or the request is going through So, uh, that's about the AWS VPC flow lock The third one is DNS locks. All the DNS queries also get locked So the whole, uh, point of using guard duty was that it was a managed service And it actually, uh, goes ahead and looks at all of these and Gives a data data saying that, you know, there is some anomaly happening Now the whole thing is based on rules, uh, they have close to 6065 rules based on which they actually classify one of the activities, uh, being malicious And they actually show on a dashboard, right? So The the pain point is that no one is actually going to look at the dashboard every day So what we did was we actually implemented a lambda, uh, we wrote a lambda which actually, uh, goes ahead and looks at Looks at all the alerts that is on guard duty, uh, dashboard and then sends an email And then after a while we thought that, okay, this is only something God did we do that what else we can do And then seems like, uh, guard duty actually allows you to add your own threat list Where in you can actually look at multiple threat exchange platforms, something like alien world threat exchange Uh, which is otx open threat exchange There's something called as, uh, Facebook threat exchange Right, so there are multiple threat exchange. So what does it give? That actually gives you a list of Bad ip's right based on reputation. So you get a reputation list So what we did was we actually went ahead and we implemented another lambda which actually, uh, consumes Uh, one of these, uh, head list And then it actually integrates with guard duty when Say there is a ip which is actually, uh, trying to scan you or trying to, you know, attack you Guard duty will automatically match if the ip the client ip That is trying to do anything malicious matches with one of one of the list in the threat list that you have already have integrated And then again, since you alert saying that there's something happening. Let's do the whole automation was done Um So what are the next step, right? So once once you integrate the whole threat list Now at the at some point at some point in time, you would actually know, uh, you know, what our ip's have attacked in past That should this this would actually help you to create your own threat list It's added at the end of the day You have your own threat list which by which you can actually use this certainly to to feed on one of your waf, right? Or if you're using waf or if there's some perimeter level security, you can actually feed this thing that You're based on based on the count. Uh, I see that these are top five ip's which has been trying to attack us And so you block, uh, all your threat at the But uh, we have been trying to do, uh So these are the next step forward looking, uh now Since I have only covered uh data sdlc and infrastructure This is something that we did, uh At our initial days like one one one and a half month of our effort, right? There has been a lot going, uh in last five to six months uh primarily around compliance around enterprise security So on the same lines, we are actually looking forward for zero trust framework. We're actually towards moving that Uh, so due to this framework is uh in nutshell, it's basically a chain of trust wherein, um Think about the employee using a device to access the resource Right. So how do you ensure that there is a chain of trust between an employee A device and an application that a employee is trying to access that right so This is the whole concept on a very high level about zero trust framework SOR is basically uh S I E M plus your uh Whole automation wherein say there is some incident that is detected by your Automated platform that you have implemented. What are the next step? How do you actually go ahead and You know respond to that incident So the whole automation framework could be written on it. We're still evaluating it probably Uh on our next talk sometime we'll have some demo or more to talk about it Uh, the key takeaway is I think so far if you see security, uh security has been like a roadblocker for everyone, right? So if you if you think Uh from a company CEO perspective, uh They think they think security to be a roadblock, right? Because the moment security comes in We come up with our own requirements, uh our own way of, uh, you know, designing things, implementing things Uh So the whole whole thing actually started with uh So I don't know how much how many of you know about kanalsa, but uh the company is from uh very seasoned entrepreneur kanalsa and he's very much He's very much, you know, sensitive about security, right? So from day one he wanted to have Everything but he also wanted to ensure that We actually, you know, keep moving things. We don't block things So basically as a security guy what what I thought about that how actually we can do things so that we actually don't end up blocking any product or any design, right so So we actually solve for people in the tech Then the second thing was basically we wanted to actually enable first because Every time it's a small team and every time there is some design change They want to actually move fast. They want to do some p.o.c. They want to do some eb It's so how do we actually enable them? What are the problems that you actually identify and how you can actually prioritize and solve in background The third thing that we had kept as our basic principle was to develop some self-suff system wherein There is no dependency, right? If I go on a vacation for a week There are systems which are actually running and ensuring that Some of the things Are being taken care by not indirectly it's never going to be possible 100% But then there are systems which are actually self-serve and not blocking people as such That's about my talk I have references here Whatever things I have used on my slide I have kept as a reference here Thanks to one of my best team. I think the team has been very helpful for me To ensure that I get everything done from tech from infra Even from our company co That's about it. Thank you so much I'm open for any Q&A Questions Hello Great talk. So can you give me another example of where you Nables something and solved in the background of specific examples So, so I think first example that I gave right? So the OTP flow signer flow, right the sign in flow on the slide itself So product team wanted to do a AB or they wanted to do a beta of it, right? So we're on a very early stage where you want to actually see Among the hundred user. What is the response right? So They actually wanted to go ahead with it when I said, okay, let's go ahead with it Let's see. What are the responses? So now I'm not blocking them, but I am also solving in background way and I'm thinking about How are we going to scale from hundred user to thousand user in the next few days? Right. So this is how we actually went right and We're actually enabling people in the tech and business Yeah While speaking about code pipeline, you mentioned that if someone goes and changes something in between The role changes and it gets stopped in between and the account gets locked out So there's no lockdown as such, but the thing is that the whole CICD pipeline is always driven, right? So say You can obviously go to AWS console and go to AWS code pipeline service And make changes over there, right? I as an attacker have flexibility say for example I have the right privilege to go and Do something over there make the code change over there, right? So what basically end up happening in background is the moment you are trying to make code change You're basically talking to API and saying that hey, I'm making this change Which actually gets locked as a cloud trail, right? So now the cloud trail is actually being monitored by AWS GuardDuty Which actually says that there is a malicious reconnaissance happening from some malicious user Right. So we actually go ahead and get to know that there is some user who is actually trying out something Which is is not supposed to So this is what what we actually ensured and how ensured We get an alert on the mail, right? So entirely based on reconnaissance