 Good morning. Good afternoon. Good evening everyone wherever you are in the world My name is Vikram Rao and I'll be the moderator for the session and we'll be now starting with a wonderful session called security practices for developers and Very happy to welcome Prima Virani on stage the speaker for the session Hey, Prima. Are you all set to take over? Yes Hello, everyone. Good morning and good evening to anybody who is on my side of the world I'm in San Francisco at the moment. So it's about 10 o'clock for us that night and 10 30 in India. I think So yeah, today my session is going to be about secure coding practices particularly for developers and I'll start by introducing myself a little bit. So I'm an information security professional I've been working in this industry for the last eight years now I've worked in various industries. I started working in oil and gas and then You know have been working in tech various types of tech companies for the last five years now, so Yeah, that's a little bit about myself and I think I'll dive right into the presentation Because it's going to be a little long. We're covering, you know whole range of topics here today And I hope you enjoy it as much as, you know, I enjoy Preparing it and you know working on it. So I'll start with some of the challenges that Companies face while trying to you know, do security work most small to medium-sized companies have this you know attitude where fixing security issues sometimes comes as an afterthought and Most of us who've been in the industry for a long time know that fixing security issues after the code is live is You know a little bit of It's a difficult task. It's not easy at all and then, you know, if the attackers exploit The particular issue and if it results in a breach, then that's you know, even bigger of a problem And then you know attackers as we all know it have Virtually infinite amount of time to find bugs in the code. Whereas, you know developers who are on the Creative and defensive side of things have an infinite Time and sorry a limited amount of time and limited amount of resources that they can put towards development So the what I'm trying to say is the attackers have a significant upside In trying to win this battle against the, you know, good folks that they speak And the thing is most small to medium-sized companies don't manage to survive through public breaches They it costs them so much Especially if they are in, you know, financial space and if regulatory bodies come into the picture then A breach can be extremely expensive So, you know, the best kind of prevention of the best cure in this case is prevention and Secure coding practices is one of the preventative ways. I mean It's a very broad term and there are so many Sub categories underneath it. I'm going to talk a little bit about how exactly we can achieve it And you know some specifics So I think the biggest overarching principle to follow here is this principle called security by design And that, you know security and secure development has to be embedded into the development process itself and Not come, you know, it shouldn't come as an afterthought And security by design Can, you know, be further divided into Smaller more manageable more achievable chunks such as the, you know, less here input validation output encoding Authentication management session management communication security and you know, there are a bunch of other topics such as System security database security file management and memory management as well. They are equally as important As the ones highlighted the five highlighted on the left However, the latter the last four system security database security file management and memory management Are going to be a little bit out of the scope for this particular talk because You know those areas are more relevant to sys admins and Sres more than the developers themselves. So today I'm going to try and stick to What developers specifically and you know people who are Creating an application or an application ecosystem can do And so, you know, the four let latter four are going to be out of scope here So let me start with, you know, um talking a little more about security by design and you know, what it really means um So the role of any security team um is to Enable other teams to write more secure code. Um, in a lot of cases security teams, um are Not necessarily part of development, but they are part of review Um in the you know the entire development life cycle and sometimes what tends to happen as security gets this reputation of being the no sayers, you know, the people who are saying no often more often than not and I just want you all to know that even when the security teams do that they're You know the intention there is to try and you know be Um as thoughtful as possible of the company's overall security posture and so on At the same time us as security people we try to Always at least good security people always try to make sure that um, then you know with even if no is the answer Uh, we always try to come up with an alternative instead of just saying oh, no, you can't do that The right approach to take generally is to go and say oh, you can't do this But there are you know these three other things that you can do instead potentially Um, so think of your security team as the brakes on your car. They are intended to you know help you go faster and That's the you know job of a great security team in my opinion um, so i'll start with um some of the security by design practices and you know This is a prerequisite for all the other principles To be followed appropriately um design applications of features with security top of your mind invite your security team to collaborate um, if you can If you have the resources if the team is big enough, um, I know those can be challenges sometimes Define the security policies in the architecture itself So this is a very good way of making sure that Security doesn't come as an afterthought and it's embedded in the development process itself um threat modeling is a very useful and uh, very You know a kind of It's a very giving exercise To go through that Gives the team a lot of opportunities to try and Mentally map and model scenarios in their heads about What to anticipate in the kind of application that's being built So i'll talk a little more about threat modeling because it's a very interesting as well as a very Involving subject. Um, I won't be able to discuss Everything under the sun, of course, but I can discuss kind of some of the high levels there So how to do threat modeling is basically, you know, there are four main Things that you can try to do number one is identify and note down the most valuable assets You can't protect what you don't know. Um, it's always, um, you know, great idea to know exactly What is it that you're trying to protect and why exactly you think it might be on the threat? um, create an architecture over your overview of the Particular ecosystem that you're trying to protect. Um, and there's an optional step here where you can decompose the application um, what that means is that you decompose the architecture of your Entire, you know, underlying network your host infrastructure design Create a security profile for the application And the aim of the security profile is to uncover vulnerabilities in the design Implementation or deployment configuration of your application Again, I know that sometimes this decomposing part can be a little bit of an overkill So, you know, it's um, of course your and your security team's discretion to choose Whether or not to go that route um Then the next very important step is identifying the threats. So, uh, you know when Identifying and documenting the threats can be a real interesting thing Where if there's the approach of, you know, fear uncertainty and doubt what we call fud Everything looks like it could potentially come and harm you That's not necessarily the most practical approach because in any given scenario, uh, there'll be maybe like two or three You know most high priority things that would actually qualify as threats When it comes down to, you know Thinking about what's the likelihood of you know, that's that that threat actually exploiting my network So for example for a financial company a more likely threat would be Someone like, you know, your regular kind of hackers cyber criminals external threats versus, you know for a I mean Hacktivist or what you call, you know, environmentalists and state sponsored Hacks might not be as vigorous as your regular, you know, script kiddies and Opportunistic hackers might be so, you know those think about those things can inform the approach that you Can take in the strategies that you devise in terms of what to protect and how to protect it The last and the most important thing as I mentioned earlier is to read the threats Not every threat is going to be the top, you know, top most high priority And of course document each one of these Using a common template that defines the core set of attributes that, you know, that captures Each threat so that will give you an opportunity to evaluate And stack rank these almost against each other And last but not the least There's a lot of information available on how to do threat modeling On, you know, there's a popular very amazing useful guide published by microsoft they've also Published a tool that you can use for threat modeling and I've provided a You know, long list of resources at the end of this presentation at the end of this live deck that I'll make available later once, you know, we are Done discussing everything and you can hopefully, you know, find some of those resources useful and valuable as well So identifying the most valuable assets Is basically, you know, identifying And partnering on the following questions Does the app or feature deal with personally identifiable information or financial information or healthcare information The reason I talk about these three Before, you know, anything else is because These three are scrutinized. They are regulated by policy by law of most of the countries In the world that, you know, attack businesses are currently established and or are running in So it's very important to protect these three at the very least Of course, there's your after you're done, you know, thinking about these three. There's your employee data to protect There's your customer data to protect and so on But if, you know, you're dealing with any of these three you should especially be careful Um What are the most valuable assets? So, you know, uh, clearly record and track Things like subsystems trust boundaries. Uh, trust boundaries can mean, um, you know, something as simple as, um Basically, where does the data come into? Um, uh, where does the data come from? Where does the data go to and within your application? What kind of processing happens what should come in and what should go out and what should absolutely not Leave your, uh, specific ecosystem that you're trying to develop or protect It's very important and very, um, useful to think about those things. Um, then, you know, think about how is the data protected Violets and transit, um, are your networks encrypted? Uh, can you know, um, anybody On your network practically sniff, um, all of the sensitive data. If that's the case, then, you know, You might need to think about a strategy there to, um, implement and to an encryption between those two sources, um, in between which data is flowing and then, um, design is something that, you know, You need to think about network and host infrastructure how it all Talks to each other and so on. So at the top most important things to think about are data and transit and data at rest And how it's how exactly it's protected. It's very important for a team to know that, uh, especially when dealing with sensitive data Identify and document threats again. Um, and you know, internal threats are equally as important as external threats and I want to highlight that because, um, you know Often when carrying out this exercise, um, in of course, you know, we again within the company itself We don't want to create this environment of kind of fear uncertainty and doubt as well. But at the same time, um, we must always kind of, um, leave that room for doubt of, you know, so of an occurrence like that, um And so on and internal threat plus external attacker is generally the most widely used, uh, strategy, um, in a lot of the successful massive public breaches. So there is this, um, You know, very public breach that happened a couple of years ago. Oh, actually four years ago now. Um, It the victim here was a company called shapeshift.io. It's a popular crypto company and, um, the their story is fascinating and, um, you know, this is one of the quotes from that article that, um, in this case, the Hacker, the external third party hacker was so surprised and appalled by the internal person who was trying to help him basically hack into the company successfully that in one of the correspondences with the company employees, um, the hacker said that even the You know, I said cease communication. Can you still send me an email when bob gets sued because that bob person was the internal person who, uh, helped this hacker Get into this company's network successfully and this was the hacker saying that I feel really shitty That I feel it's really shitty to steal from your own employer. Something that this internal person did, you know, so, um, Go out and read this story. It's a very fascinating read. Um, and it's full of drama Uh, but yeah, always be mindful. Uh, and you know, make sure that you capture the inter possibility of an internal threat at all times because No matter how trustworthy everybody is you just never know and As I mentioned earlier rate the threats not every threat warrants an action Um, so prioritizing is a very important task to do here. Um, generally the priorities are determined by, um, Likelihood and impact of a particular threat. How likely it is that something like this can happen And if it does happen, what's the blast radius? How much damage can they make and this damage can be, uh, You know in form of the you can assign a dollar amount to it. Um, if it's, um, you know, if the organization is Of course that mature and the, um, assets that you're trying to protect are so well defined. Um, That's one of the best ways of identifying impact. Um, of, you know, A potential threat manifesting itself into a breach at any given point and of course, you know, work on the most significant first The highest priority should be addressed first, uh, followed by the Next priorities and so on So, yeah Security by design. Let's talk about input validation. These are, you know, these five, um, main line items are some of the Most important key areas to think about while trying to implementing these security controls in the Design cells and in the architecture itself while trying to develop an app or application ecosystem so input validation is, um, you know, the Basically craft the art and the craft of making sure that your data When whenever you whenever your application is taking in input from Your consumer, it's always properly formatted. Um, it helps make sure that SQL injections LDAP injections and So on don't happen. So what an attacker can do is basically they can, um, you know And enter garbage Like looking text, um, followed by some, you know, special characters and so on in order to Basically gain access to your back end Using just the front end. They don't even need to hack into any of your the database the Host that hosts your database or anything like that. They can literally the front door The front end can be the front door through which they entered into your back end So, uh, making sure that for input validation, it's important to make sure that, you know, there's syntactic validation as well as there's semantic validation and, um, you know, The structured fields. So for example, social security number or tax file number These should be, you know, digits only. Um, this should be limited to 12 characters. For example, um, and date time should always be, you know, The two letters for two numbers for the day two letters, two numbers for the month and two And four numbers for the year and so on and restricting this make sure that, you know, The attackers aren't able to enter special characters in the form fields that they're trying to Exploit and also make sure that there's, you know, you check for the correctness of their values So the start date should always be before end date and never after And the price should be with an expected range and so on because the attackers can manipulate that to get an error Which can be, you know, which can reveal a whole lot of interest in sensitive information and that error dump can be then used to, um, Exploit something further. So You know, just be aware and mindful of it and this is an example of an sql injection attack where, um The attacker is able to Basically in the password field, they are able to enter the password or, you know one equals one and then, um Enter the script that they want to enter in order to get the data the dump of their entire database and so on and, um In a lot of cases, this is not only good security practice. It also optimizes your code for performance. So, you know, this is Input validation is it saves you both, you know, in some cases computing cost and also helps you stay secure Use native data tape validators that are available in various web application frameworks. Um, those are, you know, optimized for performance and for security generally and remember the JavaScript needs both client and server side validation because If you're doing only client signed validation, then, you know, an attacker can bypass it using a web proxy and, um, Or a web browser where that disables that Using which they can disable JavaScript and so on, uh, refer to ovasp is a very very useful resource, um, to, you know, refer to For great security practices, they have a ton of cheat sheets, uh, that they publish that you can follow It's literally a checklist of things that you can do, you know And I have provided everybody with a link, uh, for those at the end as well So let's talk about output and coding quickly. Uh, this is the, you know, process of converting Untrusted input into a safe and formatted input. This is You know, this practice always assumes that your The, um, consumer is going to enter garbage data and when they do Uh, this is I'm already pre defining the logic of what I do with the garbage data. That's and that's being entered So, uh, this also, you know, helps make sure that the display input to the user without executing it as code in the browser and, uh, without putting coding, um The developers can make sure that they always translate special characters. So that again helps, uh, Prevent those SQL injection possibilities and so on and this is a very good mitigation against, uh, cross site scripting vulnerability as well Um, let's talk quickly about authentication management. This is one of my personal favorite topics to talk about as well because it's very thorough It can seem complex, but it's uh, kind of some of it is very common sense Um, so yeah, um, let's talk about authentication management The this is actually the most, you know, popular and obvious of all controls as well. Um, it's all about verifying identity Making sure the app always knows who it is that who's trying to get into the ecosystem What kind of access that they're trying to, um, you know, what kind of access do they have to the resources that they're trying to access and, um, of course do not allow logins with sensitive accounts. So for example, uh, Admin logging in with admin should if possible should be, you know, prohibited and so on and even if it is allowed, um, The interface that and the options the functionalities one gets when logged in as an admin Should ideally be different to the functionality that one gets when logged in as a regular user This helps make sure that even if somebody is able to exploit, um, the admin, you know, login credentials, for example um, they are not able to Do too much damage. So this helps narrow down the blast radius and then implement proper password strength controls as well. Um, there should ideally be different authentications Solutions for internal access versus public access. So, you know, with internal employees It is usually possible to implement Keybase authentication and so on. Um, and that ideally, you know, uh, should be done It helps make sure, uh, it helps the company make sure that, um, the employees are always so And because in order to authenticate, um, one would always to authenticate This is an internal employee one would always need these, uh, set of, you know, private keys and so on Which are slightly More difficult for attackers to compromise as opposed to passwords And remember encoding is not encrypting if you can revert it. It's encoded if it's if you can't revert it It's encrypted. That's the, you know, easiest way to remember What is encoding and what's encrypting encrypting will almost always be one way and, um, Only store, um, you know, uh, salted hashes Don't never store plain text passwords, um, ever Um, display, you know, generic authentication error messages. So, uh, your error message should never show Exactly what went wrong. It should be just generic enough for the, um, consumer to know that something has gone wrong This kind of this is a little bit of an security by obscurity technique, but it really works and, um, enable multi factor authentication You know, I know in india at the moment, it's particularly popular almost every app that you're trying to use Has, you know, this thing where they send you an otp Before successfully longing you and and that is the, you know, very good security measure But at the same time with, you know, uh, all these attacks on the telephone providers and carriers themselves Um, it can be really easy to transport, you know, the The sim transport attacks, uh, can be really easy to carry out. So, um, solution to that is to make sure that, um, The users can use, uh, authentication application as well. So something like do or google authenticator Um, and, you know, providing the consumer with the choice of using either otp Sent through text message or through generator through this authenticator application. Uh, can be really useful And, um, make your application, you know, password manager friendly people should be able to You know copy and pay basically paste passwords into various form fields and so on, uh, your, um People using, you know, password wall should be able to quickly fill out the form from within the world itself You can enable all these functionalities to encourage users both internal and external to use the password management tool Which helps them create really long, uh, secure complex passwords. Um, again, account lockouts and captures also increases friction for Attackers, uh, and you know, helps, uh, hope hopefully helps keep them at bay From exploiting the application successfully. Um, let's talk a little bit about session management here. So Session management is basically, um, you know Once the consumer or any user is established a session with your application by, you know, authentication Authenticating successfully and so on. Um, the app at all times should be aware of Who that user is and how, um, you know, they can prove that they are who they claim to be So, uh, the session ID session IDs are, you know, popular way of conducting session management and Session ID names used by the most common application development frameworks Um, uh, tend to be, you know, it discloses the Technologies the names of the technologies and programming languages used by the application. So, um, uh, if possible, you can You know, change that, um, and make it more generic so that it doesn't kind of Give out all this information and then, uh, minimum length session IDs, uh, prevent, you know, uh brute force attacks and so on. Uh, session timeouts are really important. Um, implement idle timeouts Absolute timeouts and, you know, renewal timeouts. So idle timeouts are basically it limits the chances of an attacker Um, for guessing, um, and using, you know, valid session ID from another actual user who successfully logged in at the moment Um, absolute timeouts limit the amount of time an attacker can Use a hijack session for in case they are able to hijack a session. Uh, so this is a, you know, what you'd call an onion model This is a layered approach where you prevent one measure But you also allow for that measure to fail and have like a what you'd call a backup measure in case measure number one fails Um, and that is generally a pretty good security strategy overall So, yeah, um, session management again, uh, mitigates again session riding and cost site request forgery attacks. Um, Help, you know, manages session IDs appropriately and then, uh, change session ID names as I mentioned earlier From default to generic, um, minimum length of session ID should be 128 bits, um, or 16 bytes at least and the entropy should be 64 bits at the very least um Use pseudo random number generator as well Um, and then, you know, for sessions, uh, make it strict never accept user generated session IDs Treated like any other input basically validated and implement timeouts as I mentioned earlier So that's kind of, you know, summary of, um, everything that we've covered earlier and um, a simultaneous session law burns um Use built in, you know, session management frameworks use web application firewalls simultaneous session log on should be, uh, kind of, you know, limited as well in nature Um sessions are usually managed through cookies cookie management is a topic of its own and, um, you know That again is out of the scope for this particular talk But I really recommend you go online and, you know, read about it or ask again It's a very good resource to look up this information log all the authentication and session activities This really helps, uh, if an attacker is successful if an attacker successful, um, it really helps If you have logs available and ready to surf through of all the activities that went on In order to trace, um, your steps back to when, you know The attack might have started what might have happened to recreate that entire story that unfolded essentially logging, um, all your sessions is if you can't go wrong with it as, um, pretty much And communication security that's kind of, you know, the last of the methods that I'm going to discuss today here, um, implement TLS for all communications So this is basically making sure that your data is always protected by let's and transit from point A to point B And, uh, implementing TLS is a very good way and a very popular way of doing that There's a website called let's encrypt it. It's basically an open certificate authority and it lets you obtain a TLS certificate for free So this is basically if you want to make sure if your website is always on HTTPS Let's encrypt let's you do it for free. Of course, there'll be, you know, um, manpower and, you know, uh, Sysadvent's time that potentially goes into it and into implementing it, but the actual resource itself is free and disabled TLS compression reconsider, um, You know the use of wildcard certificates um Try and limit it as much as possible wildcards are, you know convenient, uh, but you know the likelihood that the private key or the certificate is gets compromised increases and As the key may be present on, you know, multiple systems. Additionally, the value of the key is Significantly increased because suddenly it's giving you access to, you know, 10 resources instead of giving you access to maybe two resources So makes it it makes it more lucrative and an attractive target for the attackers And the attackers generally can see if you're using the wildcard certificate If you know your chrome web browser has that little padlock on the left corner Through that they can actually see the entire certificate chain and who your certificate authority is and how they you know, um Basically should your certificate they can see that all those details. So be mindful of that and You know, you see a records Restrict, which uh, so c a record is a certificate authority authorization dns record um It can be used to define which certificate authorities are permitted to issue certificates for domain So what this makes sure is that a chinese company or like a attacker is not able to issue a certificate under your name from a dodgy third party chinese certificate issuing authority for example um and That you know first helps you stay protected it narrows down who can issue certificates for your company for your domain and A page that's available over tls should not include any resources such as you know JavaScript or css files which are loaded over unencrypted at issue degree because then it kind of you know Defeats the whole point of you're using the same resources Both in you know, while encrypted communications are there and unencrypted and These unencrypted resources could allow an attacker to sniff sessions a session cookies Or inject malicious code into the page even on your HTTPS pages so be mindful of that And again, you know These are some of the kind of general other general good practices system security Be mindful of these things database security patch Patch all your systems all your databases follow the principle of least privilege the employees also should Only be able to access the minimum amount of information that they'll need access to it any given point of time to be productive And make sure you do file management appropriately protect the local file system from unauthorized access And perform memory management. So these four Topics were the ones that you know, I couldn't cover today because they were out of scope today but These are definitely for you know, very important things to be mindful of and discuss with your sys admins or sids so with that I will open it up to questions and Again, I hope you found the session, you know useful All the resources are available at the end of the slide deck, which I will Make public at the end of this conversation. So thank you so much Hey prima, thanks for the session. It was wonderful. Um, You know, I've been in this space as a developer for a long time. So I had a question I'll invite the audience to you know through their questions too So you said about wildcard certificates or not, uh, you know think about it, right? So what is what could be the wrong problem with wildcard certificates, right? So, uh, the one of the biggest problems with wildcard certificates can be that, um, it so They are generally used on multiple resources, right? And uh, that makes that means that if the certificate is That one certificate is compromised. It's compromised in n numbers of your system that you're using the wildcard sets on and also, you know through, um, the Any kind of what you call it a season smart attacker will always examine your website's Certificate chain who is the issuer because they can always try and compromise the issuer directly as well And that actually has happened in the past. It doesn't happen so often anymore But, um, it does happen. So, um, they will examine whether or not you are using wildcard sets And if they see you do that even publicly then, you know, they will probably it'll be more of a motivation For them to try and compromise it because no because they know that, um, there are multiple Potential resources that they could get access to potential sensitive resources versus, you know, just one and That is a good enough motivation for somebody to go after it and chase it and Not using wildcard sets, of course Make sure your blast radius is narrow and that you're not giving out that motivation to the attacker to come after you Okay, so we have a question from harpal sing, uh, if you want to check that or you want me to read it Yes, I am actually reading it right now. So I think harpal is saying What basic competence is needed for a developer to understand the need of embedding security in day-to-day work? Is this specified anywhere? Yes, it is and I'm so so grateful and glad that you, you know, ask this question So, oh wasp is something that I mentioned through my kind of presentation quite a bit as well Oh wasp is an organization that specifically Creates resources for Developers people who are not full-time security professionals They create resources for developers to use that, um, you know, they can potentially kind of leverage while you know while in the process of Creating their own applications and can be mindful of and they give it to me in a very palatable like checklist format So you're not, you know reading through a wall of text at any given point of time It's just a one or maybe like two three pages Of you know checklist to go through and you can just quickly glance through it and Make sure oh, yeah done this done this done this done that And wherever confused they also provide you with you know detail kind of information and examples of What a particular attack entails and What it would look like and what you can do to mitigate it. So go check it out I've included the link to these resources at the end of my slide deck There's actually a resource section I can quickly show you that as well. So this is microsoft microsoft guide to start modeling There's a jango validator apache validator. Oh wasp cheat sheets Then you know all the different very specific cheat sheets as well So please go check it out. Um, I hope you find it useful Can you explain? Um, I'm reading bird of verma's question Can you explain more on accessing accounts admin should avoid logging in with admin account? No, that's uh, not what I meant at all when I said that so there are kind of multiple you know things that um We can make sure that uh to make sure multiple things that we can do to make sure that uh Your admin accounts function. So the one of the most important things To do is to make sure that your admin accounts are, you know, there are no generic just admin account so every admin account even should Be traceable to an individual at every given point of time We should be able to trace an individual's identity with every admin, you know login attempt That could be a part of uh, how you design the admin account. So for example, um, you know Each admin account should be associated with an actual user with a unique username and password That's one way of doing it another way of doing it. If you know, this is not possible Another way of doing it is to make sure that the Log on, you know attempts are recorded and it's recorded Where you know each Uh admin session is coming in from from which ip and so on and you should be able to go downstream and associate that particular ip's identity with a user confidently and You know successfully. So that's one thing another thing is that every um, so admin account doesn't always Need the same level of functionality As a regular user account. So for example as an admin, I might only need to make sure Who different users are and whether or not their accounts are enabled or disabled and I probably need the functionality to enable a disabled account For example, whereas a regular user account. Um, that's not an admin account. They might have the Uh capability of carrying out the you know actual what happens to a particular consumer's data and so on so if you if you can to separate those two functionalities out And make sure that you know admins are able to access the bare minimum they need and then the non admins are able to access the bare minimum that they need That's usually a good practice. Again. I understand it can be a little complex to implement and so on But that's the this is the generic idea that I'm describing. So I hope that answers your question um Do we have time for a couple of more questions or maybe one more question and Then people can go for a break Yeah, uh, we can take uh, maybe another five minutes. So whatever we can cover in that time for sure, um Is there any tool developers? Um, I'm reading atreish Uh, krishna pa's question. Is there any tool developers can use and ensure all of us checklist items are addressed and uh piece of code he has written is compliant with security requirements um I I don't remember them on top of my head at the moment But i'm sure they exist. But I also know that um, even the ones that exist are not very mature yet So, you know, the rate of false positives in terms of what a little flag that you know, you haven't implemented That tends to be really high. So at the moment, unfortunately, the best way of doing it is to do it manually Um, but that sounds like a great area of opportunity for, you know, the next kind of wave of starter founders I'd say and try and make that more efficient more automated um, but you know, it's also harder to implement because um, each of these functionalities are implemented differently in each different frameworks So the way jam you implemented in jango might be very different to how you implemented in node.js And to you know, create a solution for every single one of these stacks Can take a while. So yeah, that's kind of the scoop on that um Okay, um Could you touch upon very few basic security practices that DevOps engineers should practice Where they are involved in continuous deployment? Yes, I can talk about a few things. Um in context of AWS particularly because you know, that tends to be the platform that's um, the most kind of popularly used by a lot of DevOps engineers and uh, one of the ways of making sure that you know One of the most kind of basic ways of making sure that security practices are adhered to is to make sure that you You know, none of the changes that are being made on the platform itself can be made directly through the console And they should all be probably pushed As code through, you know, third party to like terraform or something equivalent of it And whenever these changes are pushed, um, you know A security should probably be one of the mandatory peer reviewers. Um, if it's not, you know, too much of a kind of Time suck or a hassle Then, you know, security teams can then kind of jump in and glance through the particular piece of code or change that's You know being pushed and see if they can, you know, see any kind of Security issues with it and that's one of the kind of easiest and quickest ways of doing that So make sure that all of your infrastructure is or as much as possible of your infrastructure is written as code And modifications to them are being done in, you know, github not on aws directly um okay for Transferring large files over ftp. What security threats we should be mindful of so ftp inherently is insecure It's not encrypted and it can be slept very easily Try and use sftp wherever possible for large file transfers another somewhat of a hacky, but slightly more secure way of doing it is Use apps like dropbox google drive and so on they are literally made for this purpose And there is an entire team working on securing these transactions and these connections so so that you don't have to worry about that implementation yourself and It's kind of done, you know out of the box for you It's you know, they are very easy to use tools and everybody it's very intuitive as well So try and you know advocate for those where possible because you know to build everything that every time is A not possible and B not feasible It might cost you knowing the time that you're spending and trying to implement those versus the benefit you are getting out of those So always consider that kind of cost benefit Okay, um, thanks prima. I think we kind of have run out of time. Um So it was a wonderful session and uh, thanks a lot. Thank you so much