 Hello So encryption both will start at 2 40 p.m. If anybody wants to attend Hello, hello, like testing Okay, good afternoon everyone after post-lunch. It's great to see you all in order one there are Flash stocks and it's from 2 40 p.m. Till 3 10 The talks are on running cubelit as a container by abhay SSH key management tool using aws I am NS 3 by roshan kumar Foreman discover metal as a service by rahul bhajaj Data as rest encryption by mriddle rebooting by ladies bangalore 2.0 by puja and the final one security communities in Bangalore by Vandana a Humble request, please do keep my your mobile phones on silent Because it becomes a problem. So please cooperate and thank you. Please come forward So this talk is About how you can scale your SSH by pulkit Today we are going to talk about SSS certificate a way to scale the SSH access My name is pulkit vashnao I'm working as devops engineer for three years and i'm currently working at moingage I I have worked in different domains like digital marketing cdn and e-commerce in the companies like package zoom moingage and pyro I'm devops enthusiast and a lenox fan So the agenda of today's talk is What are the traditional methods to use the SSH then we'll discuss what are the centralized Authentication approaches which are scalable, but what and what problems they have Then we'll have a adventurous ride of the SSH certificates Then we'll have a quick demo and we'll discuss about the features of SSH certificate And at the last we'll discuss limitation and the solutions So here you can see a hospital In the hospital there is one one ladder and there is one helicopter A ladder is a regular way to access the hospital and To get the platinum access you can come using the helicopter at moingage We were using the regular approach for the SSH access to provide our developers but We wanted a solution which was scalable which was easy to set up and Which is secure so we come to a solution of SS certificates using which we performed We we got all the things it was secure. We we have so many nice features like role-based SSH Okay, so before starting about SSH certificate What SSH is SSH is a client server based protocol Or to access the remote machine on an unsecured network or sorry Remote machine securely over an unsecured network. So we all need to SSH into the machine either that can be for debugging that can be for Setting up anything or to check the performance of the server Here are some common commands, which you you you would have used to SSH into the server Now there are some traditional ways So Password best password authentication to SSH into the servers. We set a password and When we were SSH we we entered the password to access the server The problem with the password base authentication is password can be cracked can be leaked or Passwords are predictable and nowadays we have a problem like we have so many passwords of different applications. So sometimes we forget uh Forget the password and we lost the access of the server. I I recently had this kind of incident Now the second is public key based authentication here. Here we have access key via pm files like some cloud provider provides you a private file and using those files you can SSH into the server Problem with this method is if your key is leaked your that private pm key file is leaked your your system is compromised The other way is public key Authentication method in which you we we add the public key file Of of the user to the authorized key file of the server and every time a user adds or delete from the system We update the authorized key file Now here on scale like like For example, you have hundreds of users and thousands of servers In that case management of this Public key on all the servers is is a pretty hard problem So are there any alternatives? Yes. Yes, there are. Uh, we can use some central authentication services like LDAP, Kerberos or Active Directory But this solutions have some problems like they are hard to install they are hard to configure and During an an incident. They are single point of failure So let's say You have an incident like your centralized server went down or your cloud provider has our outage or the dns outage You you will lock out yourself from your own system. That would be a nightmare for any any developer Now SSH certificate it comes as a savior like kung fu panda. It's very easy to set up low maintenance Secure and there are so many cool features like role-based access and the certificate validity. We'll discuss this in detail in the further slides Here are the benefits of SSH certificates. It's cost efficient. So you don't have to uh Set up a New infrastructure, let's say if you use LDAP you have to Set up a different service for it. You have to scale your servers for that if your number of servers increase of on your infrastructure, you have to scale your centralized authentication servers as well It's simple to set up. You just have to make couple of changes on your server and you are ready to go And it's flexible. It has many features like you can provide role-based access You can add the certificate validity and there are some host based access. You can provide using it Now who uses it? They are companies like facebook uber netflix lift and we at the moeingage use Certificate based authentication methods. There are some uh open source projects like bless Pam ssh by uber and we recently open sourced the project easy ssh In this talk, we are going to discuss about the concept behind the ssh certificates Now here how ssh certificate works Uh before that, uh, what ssh certificate is ssh certificate is nothing but a certificate based authentication method And it's it's it's a certificate authority. It works like a certificate authority And your certificate authority have a public key And a private key you will populate this public key to all your servers And you will mark this key as your trusted ca user key file now When a user request when a user request that i want access of I want ssh access what you will do you will take the public key from the user And you will generate a intermediate certificate using the private key file the private key file will sign Your intermediate certificate from the public key of the user and using that intermediate certificate You will give that intermediate certificate to the user and user then will be able to ssh into all the servers according to the accessibility of that certificate Now what are the features of intermediate certificate? Why do we need a intermediate certificate or why should we use intermediate certificate? There are features like certificate identity. So, uh, if you use any centralized system like LDAP, uh It will manage all the users for you Let's say if you have 100 users, you know in your organization LDAP will manage that on all the servers of the infrastructure, but uh, it comes with a cost because You have to run the LDAP client on all the servers But using ss certificates, you don't have to do it, but you will get the identity who is uh accessing the Server using the certificate identity to every certificate you provide a identity and you can track that identity in the logs of ssh Then the certificate validity Uh, we we see that uh in in uh in any organization people comes and leaves From from from the organization And if they have access of the infrastructure if they have access of the ssh key They can access your uh entire infrastructure even after leaving the company So what you can do you can provide an intermediate certificate, uh, let's say for a day He can access his infrastructure for a day only and after that, uh, he has to uh Request for the new certificate so that he can able to access the certificate Sorry servers Now the other is principles or role-based access so we can provide the role-based access There are so many roles, uh, which we can create let's say If you have developers in your team if you have ops in your team if you have front end team, uh then you can create different kinds of roles and You you can provide access to those uh servers only with which this person is associated with And the last is instead of providing Access to a user you can also provide Access to a host So this is why you should use the intermediate certificate. Let's uh, Let's go through the demo where we will Will we'll see how ssh certificate is working So here We have three servers ca server A log server and a bob server. So bob is in the backend team and he wants access of the log server Now we will generate intermediate certificate for him and provide him the ssh access here. I intentionally did a mistake I I want you guys to, uh, correct me. Uh, what it is So let's go through the demo so here, uh we'll generate the Certificate authority using ssh key gen hypen t rsa is the encryption type and f is the output file which we want that is the ca Here we generated our ss certificate and here we have two files as ca and ca.pub Now we'll copy the ca.pub And we'll paste it to the all the servers here in our case. It's a log server We'll go to the log server and we'll copy our public key on this So we'll copy this file and paste it to the log server Here we'll create one file. Uh, i'm creating it in etc ssh and ca.pub I'll paste the public key of the ca from here to this file I'll save this file and now I need to I need to add this file to the ssd ssh configuration So that it will mark it as the trusted ca user So we'll open the ssh configuration file that is etc ssh and ssd conf At the end of file, we'll add a line Uh, that is trusted user ca keys and the path of the file where we created That is etc ssh ca.pub we'll we'll add this path and we'll save this file and Then we'll go to the then we'll go to the client here on the bob's machine We we need to set up something first. We will check whether bob's have public or private key or not So here we'll go and check whether uh bob so There's not uh So we'll generate public private key for him using ssh key gen command And ssh key gen hypen t rsa we will provide the encryption type That is rsa Now add your passphrase if It's recommended to add passphrase when you generate the ca you can avoid here So now we have the public and private key id rsa is the private key and id rsa dot pub is the public key of the bob Now we'll copy the public key of bob and we'll generate an intermediate certificate For him uh from the certificate authority which we created So we'll copy this public key We'll go to the certificate authority server Here we'll paste this file uh in in the new file bob.pub and We'll generate the certificate See we created the file now now we need to generate the certificate So here ssh key gen is the command Using which we will generate the certificate minus s Hypen s is for the source file that is our ca Which we created now we'll give him the identity of the file that is hypen i and bob is the identity of the file Now using hypen n you can give Uh Roles or principles which we are we discussed here you can see there is one developer Principal there is one ops principle and there is one ubuntu principle. These are all the roles of any system Now we'll add the validity of At the validity of this certificate. So in this case i'm giving it for one week so hypen v and plus one and Now hypen z is for the Unique number you give to this certificate so that you can identify whose certificate is it And Finally the public key of the file that is bob.pub here. You can see it is signed now. We'll check the details of this certificate so here ssh key gen hypen lf and the Certificate name that is bob hypen cert dotpub So now here you can see it's a certificate user certificate It is created from this public key signed by the ca now here. We have key id that is bob We the serial number which we gave that is one and it is valid from 20 20 to 27 And here are the principal files developers ops and ubuntu critical options are there Which are some advanced topic which we are not going to discuss in this talk But here are the extensions which you can Change using hypen option So let's copy this certificate and paste this certificate to the Client machine that is the bob's machine will will copy this certificate and paste it to the bob machine We copy and under dot ssh folder We will create a file id rsa that is the name of our private key and will add hypen cert to that file and Will add our certificate this is the path Which by default ssh will use if you want to give your path explicitly you can name it whatever you want but if you want it to Implicitly use this you can use this So we'll paste our certificate here and Now we will set the known host on on our on bob's machine because Our our client bob's machine don't know what certificate authority it needs to refer Before accessing the ssh so will Yeah, so here under dot ssh file will create a known host And we'll add our public key of our ca To this this file So for that we'll add at the red cert cert hypen authority Then we need to specify a host in this case We are just going to access our own machine only so we can add a strict sign here So it will refer this certificate this public file for all the All the ssh access Now we'll copy the public key of the certificate from the ca server and We'll paste it to the bob's machine Here we paste this file and Now we'll try to ssh into our log server We'll try to access the log server from the bob's machine Now we try to ssh ssh Yeah, ssh Ubuntu is the user and and the ip of the logs machine now We are just doing host key checking and permission deny Can you tell me? What mistake I did Anyone are you feeling sleepy after lunch? Actually, I I I forget to restart the ssh server. I change ssh configuration here But I forget to start the restart the ssh. So I have to go to the log server and Restart it back So I'll go here sudo service ssh restart and after that I'll try to ssh again And it worked. Welcome to the log server. Here is the log server. Here is our So You just have to add some couple of couple of things To your servers. You just have to this one time setup on your client and you can able to Use the ssh certificate So that this is all from the demo What we just did, uh, this is the quick recap of that will create a csa certificate Will copy c a public key will paste it to all our servers Then we'll set this copied file as the trusted cf file and will restart the ssh this time don't forget to restart Now on the client side, we we we need to create a public private key if it is not exist Will create one intermediate certificate from the c a will paste that intermediate certificate from cs server and Now here we'll set up the known host will copy the Public key of the c a to the known host and then we try to ssh into the our server Now here is the quick recap of the command as well. What we we used ssh key gen is the open ssh command To which will give the source file that is the c a then will give identity that is bob Then will provide principle whatever you want that could be developer Ops or whatever teams you have you can provide the roles you can add the validity In this case one week the unique number and the client's file Now to check the details of the certificate ssh key gen Hypen is l is for the content of the certificate and f is the file name Now here are some features role-based access. So what do we need to Implement the role-based access you just need to add a principal file On the server it is a simple text file and You can add all the roles in the new line separated way and after that in the ssh configuration You need to add this this this this line the authorized principal file and the path of the file And you will be able to create the role-based access for your system Now the second is host-based access instead of using Providing access to a user you can provide access to a your host as well now certificate validity Now it is recommended to give as minimal as possible because As we discussed if you give but ssh access Like certificate validity for like one day or one week or one year to your employee and he left he still Have access of your infrastructure because he have that intermediate certificate Now the identity of certificate Uh, so when you log log all all your ssh access either you you will create new user for for All the users you have in your company or you create You use identity certificate if you so here we we provide the certificate identity So now There are some cons as well So when you rotate your ca when you rotate your certificate authority You have to update the public key on all the servers which you are using The second is if ca is leaked it's a single point of failure Everyone can create intermediate certificate and use it to ssh to your infrastructure So it's recommended to add a passphrase if it is not set And the revocation of intermediate certificate is not possible. So it is recommended to Give as minimal validity as possible Now even ssh certificates are not secure You should be cautious when you are generating a intermediate certificate and you should Follow some good practices like add small Small validity to the certificate Use bastion host so that instead of users machine you you can manage users from the bastion host You can create All the users on bastion host and you can manage and provide intermediate certificate on the bastion host only You should rotate your ca private key regularly And must must must must add a passphrase while generating a ca certificate because it's important And if your ca certificate is leaked or compromised it will need password to get access or create a New intermediate certificate now All we have so far all we have done is so so much effort you have to copy the public key to the all the servers then Users public key you have to populate and generate an intermediate certificate. So it's so much effort So We at mowingage built a open source project easy as ssh So what we we have done so far it's it's it's It's a three-step process you just have to add your ip of the servers in the ansible inventory and You just need to run to a script one to set up a ca server and other one is to set up the client So you can use this you can contribute to this Yeah, so that's all from the talk here are the references any questions So here for the example purpose. I used a ca You just need that certificate file only so you can keep it anywhere. You can keep multiple copies of that if you're It's a it's a ansible script. I can add it add in the roadmap to do that as well Yes Yeah So the question is role-based users are associated with the Users or the system Yes, yes, so you create one file And on the servers you create one file where you have multiple roles. Let's say there are devops There is a back end and there is front end. There are three roles You will add in the new line separated way and while generating the intermediate certificate You will add these strings like back end Devops or the front end in the comma separated way You are managing the security of security of the public key In ansible code, you have everything at one place, right? So if that is compromised It can be easily hacked. So it's a public key So you you might be having everything in ansible code your public key your ca and Whatever is ca. Yes. Yes. Yes. Yes. So how you are managing that because I have everything I can I can you know collate that information and Access the system whatever is required So what you can do is Instead of keeping it the private certificate at one place You can replicate it at all the places and the other thing you can do is Giving access to this infrastructure the ca infrastructure. It is not recommended. So you should give this access to the limited persons only to avoid this kind of situation because At the end it's a single single place where which is governing all these things So uh pulkit will be around here outside. Maybe you can catch him later Or yeah, so thanks a lot pulkit for the awesome talk Yeah, thank you. Thank you So uh next talk is uh about implementing security from day one at a fintech startup by Himanshu So he'll talk about his journey of security at cred So after this session, uh, there will be a beverage break and after that there will be a cncf buff here Where we'll discuss about uh, let's say what is cncf and how you can take your project under cncf and also we have Satyam from open ebs. He will share his journey. How they took open ebs to cncf. So Stay tuned. Can I just put it? If you can help me, yeah Yeah, please go ahead. One second. One second. One second. Just remove the wallet Yeah, all good. All right I'm audible cool Very good afternoon to all of you. Um My name is Himanshu. I'm super thrilled and excited to be part of root conf 2019 Uh Little bit about myself, um, I work with a fintech startup call us crit Our startup is based out of banglore india And currently I am looking at security overall security for crit Uh, previously I have worked with, um, further companies ebay flip cut grab Mostly on, um, building, um, products platforms security, um, I have mostly focused on blue team Um, I have also presented at, um, some of the conference null con cocoon grace super Um, I do pass participate at capture the flag contest Uh with a team call a seq fold And I'm part of few of the open source communities where I, um Actively get involved a little bit about my company. Um, we are into fintech space Um, if you use our app, uh, the current platform is Based on credit card bill payments um our overall Goal is to actually help indian consumers improve their current behavior Uh, little bit about our tech, uh, currently we have 35 micro services um, which is close to six lines of code and, um We have 50 gb of data, um, growing per day Um, we are heavily based on aws infrastructure And our tech stacks includes, uh Java and golang So the aim of this talk is basically to share our learnings. Um, um, what we have done, um at day one, um For the whole infrastructure plus security Now this talk is not the end. Uh, 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, data security Um software development life cycle and infrastructure security Uh, let's take data as the first thing. Um, as you know that data security is very important right now Currently if you try to look at the frameworks, uh, they are non available So there's no right way to actually go ahead and, uh, do data security based on some industrial standard framework um So we tried a couple of things at our end and, uh, it has actually worked for us And that's what I'm actually going to talk about today Uh, so there are various steps that we followed as a part of data security Uh, so I will walk you through the steps that we have followed Um on the step one, uh, corresponding to data security Basically if you're trying to, um, 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, um, design It may be, uh, the code that your developers or tech team has written that you would like to project So, uh, step one becomes a very crucial step on identifying what exactly you're trying to project uh So we went ahead and created a kind of manmipe. So this was like a, uh Individual exercise the mind map may not be visible to you But this is a holistic view So, uh, as I mentioned that cardholder data and PII is kind of important for us, uh, We actually went ahead and did an individual assessment of You know, what are the ways by which our cardholder data could be compromised right so, uh Distributing into two primary buckets internal as well as external So there are multiple ways a cardholder data or PII could get leaked, uh, uh, 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, uh, 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, uh These are the ways by which you can actually, uh, you know figure out and do a mind map 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, uh, uh one of the one of the, uh, 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 We didn't all the data lies on AWS So we thought that let's focus, uh, primarily on AWS, right So on this exercise, we actually went ahead and laid out all the scenarios that could lead on to, uh, The Kalkar data leak or PI data leak Right, so if you look at, uh, the slides here, uh Basically, if you see the top few things that you think about, um, maybe, uh, Say for example, uh, uh, AWS root key or your access key or secret key gates leak Right, so, uh, that's one of the scenarios where in a data could leak Other could be a sleep bucket say, uh, they are teams who are actually using a sleep bucket and You are doing some storing of card data over there and if it gets public the data could be leaked Right, so similarly there are multiple, uh, scenarios and all of this exercise but 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? So the answer is no, right, that you need to have a second level of view Second view of someone actually, uh, telling that, okay, 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 Where in, you can actually talk to your tech team, right So you also need a second view Where in, 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, uh, 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 Where in, 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, uh, 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 tools and 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 here 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 So once you have identified the impact details, you actually laid out the mediation steps, right What are the ways you can actually go ahead and, uh, eliminate the whole, uh, whole impact Or remediate the whole, uh, source from which the data could leak So these, these are the, uh, these are the few steps that we took actually to identify, uh, You know, what are the base by which, uh, data could be leaked Now this is not the end, uh, we had done a bunch of other things 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, uh, second thing, uh, which is SDLC, right So think about, uh, starting a software developer life cycle, 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 of 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, uh, very comprehensive effort Effort not only by a security team, but, uh, by the entire company Similarly, uh, think about commercial solutions, right There are, 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 do deal with Right, and you would need someone who can actually, uh, 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 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, why exactly are you doing SDLC for whom you're doing, right So understand your 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 an example here, the way you can actually start with, you can go and talk to your tech team and, um, get a simple sequence diagram or UML diagram, right So I have an example here on, on a sign-in or a sign-up flow, right Commonly if you see, think about a, 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, uh, and on the second step the OTP is verified Now if you, if you think from product perspective, right, so Usually the way it happens is they, they usually come up with a very, uh, unnatural number varying They want a customer to, you know, allow, uh, uh, making OTP attempts Say for example 25, 30 times, right Because they don't want funnel drop on, on top of the, uh, top of the product Right, so But if you think of, of, as a security guy then there are problems involved, right So you may not, you may not want to allow, uh The product to go with a 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, uh, 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, uh, this is what I'm proposing and you should go ahead and implement So you go with a multiple approach scenario when in, uh, 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 Right, so this is one of the solution, the other solution could be, uh, You know, allowing, allowing a very aggressive approach 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, uh, need to actually go and talk to people around, uh, for example, if you think about, uh, 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, uh, on, for example, on day one you may want to have an SSL training 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 these 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 old, two years old If you think about implementing SSL training, 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 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 the whole, uh, You know as DLC pipeline On the top left, we have Gosec, this is for Golang On the top right, we have Findbooks, this is for Java based On the bottom left, we have dependency check, these are to, uh, Look at all the third party libraries that your Java code may have On the bottom right, I have a 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 SQL injection, which is very, very common, right So, uh, what we have seen is that, uh, Once we identify the SQL injection and the code has a written by a single developer We have seen that the same pattern works actually, right So 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 Uh, currently I will not be able to demo the whole framework Right now, uh, the time taken for the entire repository scan Which is like 35 plus repository scan Exclose to half an hour Because we actually, uh, independently do this whole thing Wherein we build the whole, uh, repository and we run our framework on top of it We are working towards optimizing it And at some point, uh, we plan to open source this, uh, whole thing Um, if you have time and feel free to check out our booth outside To, uh, look for the demo where we can do a code walkthrough After the talk Now the third piece is infrastructure, right So, as I mentioned that we are on, uh, we are on EWS We are on EWS We have an 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 CI CD pipeline You do the monitoring, logging and all of these, right So I'm, I'm gonna pick, uh, 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 depth, uh, there are three key points The first one being EWS multi-account strategy So what this basically means is If you are on a public cloud You better have, uh, multiple accounts, EWS 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 resource consumption in each account The second one being security Say for some reason one of your EWS, uh, 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 over here with something called as EWS organization Where in, uh, you have a root account, uh, which is your identity account And below identity account, uh, you have multiple other accounts Which is your child account For example, currently we have five accounts Davis stays, brought, uh, as we are 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 Right, so this is again, uh, the approach that we took So that things are pretty much neat, uh, from the D1 The second important part is the multi-layer, uh, approach Where in, you actually segregate, uh, your DMG 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 DMG Then we had a web, uh, subnet, where in, uh, we had an API that we call as KONG And then below that we had an ELB subnet, which was a private subnet And all of these actually Talked to each other ugly, uh, via VPC layer Right, so 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 very 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 a 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 and RBAC 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, you create a AWS account And you start seeing with, uh, 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 used, uh, multiple reasons, um, 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 secret key Thought that this startup is not cool and He may leave the company with, along with the access key and secret key, right? So these are the problems So we, we had some requirements in mind, right? So we wanted to have a single place where in From one single place, we can actually on board and off board people, uh, having, uh, 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, uh, we have deep group, uh, we have tech group We have SysOps group We have SecOps group 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 Where in, 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 Uh, you, without entering any username and password So it becomes very simple if, if you take this approach Uh, the other requirement was we are, as a security team, we also wanted to have some audit behind it, right? It's not happened that, uh, one of the EWS secret key or, uh, Access key gets compromised and someone sitting in a Germany is accessing your EWS 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 wanted to manage our, on Active Directory And as many of you understand that, uh, The moment you have Active Directory in your, uh, in your ecosystem The management plus security of Active Directory becomes a big thing 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 EWS 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 a 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, a user can actually log into one of these accounts Right, so these are short-lived tokens 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 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 Right, so 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 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 config driven, uh, wherein, uh, we have a simple, uh, YAML-based configuration And based on that, uh, we use a managed service called as AWS pipeline, code pipeline and, uh, the, the config actually goes to code pipeline and From code pipeline on first step, uh, goes to code build, wherein, 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, uh, ELB or ELB depending on what is required and then, uh, we attach our, uh, so we basically use AWS Fargate So AWS Fargate is like a managed service from AWS, uh, which does the whole, uh, whole country, 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, uh, the beauty of the whole pipeline that we have built here is The whole pipeline is, uh, role-based driven, uh, IAM role-driven, 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 have 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 AWS GuardDuty where in Any sort of change would actually trigger a, uh, trigger API call on AWS and that gets logged Right, so if you have proper, uh, monitoring system around your AWS infrastructure Then you can possibly go ahead and see like what really happened And AWS Fargate, the reason we actually went with AWS Fargate is because the whole thing is managed by AWS 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 have to go ahead and patch it, right? So patching again becomes a problem As you know that we are into fintech space, there are lots of, uh, compliance driven requirements and, uh, One of the things that, that is required you to have is Having some sort of, uh, 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 antivirus, 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 AWS Including the patch management, uh, the antivirus, anti-malware, uh You know, uh, is taken care of by AWS 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, where in We continuously want to monitor our AWS 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, this has been being, uh, We thought of doing it ourselves and we evaluated 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, Commercial solution and has worked for us Cloud Confirmative to name, uh, one of them, cloud exploit So this actually goes ahead and, uh, does the whole AWS configuration monitoring and Since you are alert based on, if there are any misconfiguration founds on AWS 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 logs from multiple sources in your AWS account The first one being cloutry logs So what are cloutry logs? 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 cloutry The second one is a VPC flow log In nutshell, VPC flow log is like a firewall logs 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 logs The third one is gdns logs 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 so on a dashboard, right So the, the pain point here 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, uh, Looks at all the alerts, uh, that is on guard duty, uh, dashboard and then sends us an email And then after a while we thought that, okay, this is only something guard duty doing, right What else we can do? And then seems like, uh, guard duty actually allows you to add your own threat list Wherein 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? Threat exchange actually gives you a list of bad IPs, 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, threat list And then it actually integrates with guard duty Wherein, 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 sends you alert saying that there's something happening Let's say the whole automation was done Uh, 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 IPs have attacked in the past And so this, this would actually help you to create your own threat list It's a, at the end of the day, you have your own threat list Which, by which you can actually use this threat list to feed on one of your WAF, right? Or if you are using WAF Or if there is some perimeter level security You can actually feed this thing that you are based on, based on the count I see that these are top five IPs which has been trying to attack us Right, so you block, uh, all your threat at the perimeter level So this is what we have been trying to do So these are the next step Forward looking, uh, now the, 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 the last five to six months Uh, primarily around, uh, compliance, around enterprise security So on the same lines, we are actually looking forward for Judo's framework We are actually towards moving that So Judo's framework is, uh, in nutshell, it's basically a chain of trust Where in, um, think about an employee using a device to access a resource Right, so how do you ensure that there is a chain of trust between an employee, a device And an application that an employee is trying to access that, right? So this is the whole concept on a very high level about Judo's framework SOAR is basically, uh, SIEM plus your, uh, whole automation Where in, say there is some incident that is detected by your automated platform That you have implemented What are the next steps? How do you actually go ahead and, you know, respond to that incident? So the whole automation framework could be built 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 takeover 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 So the whole, whole thing actually started with, uh, So I don't know how much, how many of you know about Kunal Sir But, uh, the company is from, uh, a very seasoned entrepreneur Kunal Sir And he's very much, uh, 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, uh, 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, uh, so we actually solve for people, uh, in the tech Then the second thing was, uh, 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 POC, they want to do some AB And so how do we actually enable them? What are the problems that you actually identify And how we actually, you can actually prioritize and solve in the background The third thing that we had kept, uh, as our basic principle Was to develop some self-suff system where in, you know, there is no dependency, right? If I go on a vacation, uh, for a week, uh, there are systems Which are actually running, uh, 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 Uh, that's about my talk, uh, I have references here, uh, whatever things I have used on my slide I have kept as a reference here, uh, thanks to one of my best team I think the team has been, uh, very helpful for me, uh, to ensure that, uh, I get everything done, uh, from tech, from infra, uh, even from our company's CEO That's about it, thank you so much I'm open for any Q&A Any questions? Hi, it's Hello, yeah, great talk So can you give me another example of where you, uh, enable something And solve 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 A, B, R They wanted to do a beta of it, right So we're on a very early stage where we wanted to actually see Amongst the 100 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 I'm thinking about how are we going to scale From 100 user to 1000 user in the next few days Right, so this is how we actually went ahead and We're actually enabling people in the tech and business Yeah, uh, 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, uh, the whole CICD pipeline is role-based driven, right So say, uh, you can obviously go to AWS console And go to AWS code pipeline as a 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 not supposed to Uh, so this is what, uh, what we actually ensured and how ensured We get an alert on the mail, right So entirely based on reconnaissance So, uh, so time's up We'll take questions offline so, yeah You'll be around here on the credit booth So you can catch him later So, yeah Thanks a lot Thanks, Imanshu, for the talk Thank you so much Have a good day ahead So now there will be a 20, 30 minutes I guess, beverage break And after that a CNC, a BOF will be here In the same order Thank you It will be about how you can bring your Homebrew project to the CNC of Umbrella