The Road to Developers' Hearts

welcome everyone hope you all are enjoying the event and uh staying hydrated and also thank you for coming to my talk speaking of my talk it is the road to developers heart a quick introduction to what I'm going to talk about for next 20 minutes and why am I talking about it I've been a software developer for a quite a long time now and I've been in the security space and building security products since 2017 I have had hands-on experience in both side of things during this journey I get to see how different the perspectives are from both sides on how to solve a problem or what problems to solve even on top of that every

project comes with certain constraints it may be limited resources or time when you add those constraints to the difference in perspective Sor okay yeah thank you yeah when you add those constraints to the difference in perspective it creates challenges challenges become friction and things get escalated in this talk I'm going to talk about how to reduce those challenges and share some personal experiences towards the end we will have some Q&A and if time permits I would love to hear what worked for you in those similar situations before we go too far you might wonder why is it important right if there is a security issue you can escalate push people to get things done and it works

most of the time why does it matter how security teams and software teams should collaborate in my opinion it is not about solving one or few problems at hand at the end of the day we need to protect our customer Safeguard their data and keep our system secure in order to do that software and security teams need to work as a same team to achieve a same goal that's why I'm I'm I'm talking about this topic I kind of split this talk into four categories people process technology and cultural aspects I'm going to start with the People based one which is building trust this is an obvious thing to say but it it is really hard to do consist L

if you work together as a team day in and day out it might be relatively easy to build trust but most of the time software teams work with security teams on a short-term engagement there is not much time to get to know each other so security teams work with software teams for a short period of time mainly towards the end of the project and you identify some issues and you make the development feel like you are blocking their delivery this whole combination of things do not help build trust so what can we do about it right unfortunately there is no one's standard checklist to build trust I'm going to talk about few things in the upcoming

slides that may help build trust but at this point in time I'm going to talk about few crucial benefits of building trust ear in my career I used to be very hesitant to share some of the things I thought might be wrong with my security counterparts mainly because I might get into trouble or it might backfire and things like that after working in security space for a while now that I know the teams are here to help and I trust them uh whenever I couldn't prioritize some of the nice to have security things in my project I go talk to my security friends and I ask them to advocate for it it helped my case a lot

of time so Developers know the product in and out sometimes they know where exactly the issues are and what issues are in the backlog once you build the trust they will bring you some issues that you did not even know existed it is also a really good reconnaissance opportunity the next one is being available there was a time when it used to take years to sorry weeks to get any of of the security consultation done if not months thankfully things have changed now by the time you finish the back and forth communication sometime you even forget what the initial ask was or you might have moved on to different project thankfully uh organization started to prioritizing security more

now than before having easy access to security teams during project development or when fixing issues is extremely helpful than you think it reduces a lot of overhead cost and rework and re-reviews it makes both software and security teams more efficient this is another thing that is very easy to say you know but everybody is busy and it's very hard to do in real life so find your Avenues it could be weekly offic hours are setting up a design reviews or getting involved with the teams development processes from the initial stages or establish ing a asynchronous communication Channel through which your response velocity is a little bit faster without impacting your productivity obviously so also staying engaged with

the teams through uh periodic security events or sending newsletters and letting them know that you are available to help is a great way to build trust and also it make them make you feel like you are part of development team as well all right I'm going to move on to a couple of process based Things Early detection of issues comes with a lot of well-known benefits I'm not going to get into that preventative controls are even better but be cautious of Shifting to left especially in the product develop early in the product development early in the stages developers want to move fast build something Scrappy and I trate on it if your organization have lot of process

proces or red tapes around you know project initiation or setting up the initial infrastructure it can be disruptive at the same time I'm not advocating for putting test envirment on the internet there needs to be a balance it may require customizing some of your processes and that should still be within the limits of your organization's risk profile the other aspect of it is program Management in the past uh one of the audit teams supposed to do a review of our software and they couldn't time until end of the year they started the review in November they did a great job they gave us a bunch of issues to fix before they go on vacation and some of

those issues were expected to be fixed by end of the year and obviously some of some of us were not happy things like that could have been avoided or at least a advanced notification might have been helpful ful we all understand things like log 4G happen but if something can be done in advance please do not let that be a surprise next I'm going to move on to couple of autom Technology based aspects doing manual things over and over again is time consuming and it is annoying it would be really helpful to identify or build some tools and integrate that with continuous integration process it's going to save a lot of time for both teams once I was

part of a team that was heavily using database programming language for which there were no open- Source static code tool analysis tool available uh we were spending a lot of time uh manually reviewing things and eventually we found a tool we procured it and we integrated it and we all were super excited that it's going to work unfortunately the tool was bought line unusable mainly because of the false positives so we spent a lot of time uh fixing the false positives and eventually made it work and it was it was a lot of time we spent a lot of time initially but it was one of the greatest investment for software and security teams at that time so as a security

practitioner you have visibility into a lot of security automation tools if you can bring that into development team's attention help them automate and also find tunit to reduce the false positives it would be a great win for both software and security

teams few years ago I was part of a security team um and there was a development team came to us for a consultation at the time we had a really good network security engineer in our team and he started and he was new to the organization as well and he started providing some Advanced networks solution that some of us here it for the first time and we did not have any prototype done or we didn't even know how that would fit into our ecosystem the teams left with more questions than answers ideas like that are great it pushes us to innovate but it might be a good candidate for running as a separate project because it is very

hard for software teams to build a new security solution when they are still trying to solve the software problem so provide realistic recommendation that uh that you might have to consider some trade-off decision but uh it it is really meaningful and helpful to the development teams being specific most of the security questions can be answered with it depends uh it can be vague at times and uh honestly it can be annoying at times sometimes too so it is a instead it's a really worthy exercise getting into the specifics and understanding all the various options available and you know providing a meaningful and specific uh solutions that will help a that will help a lot um

in terms of like in terms of the communication with the development team and then in terms of the efficiency of the teams as well you you could even do some lightweight tabletop exercise in the advance that teams can use as a framework throughout their development and then they can use that during their sdlc life cycle the next one is escalations most Organization for most organization security is job zero or job one however you see it if there is a security issue you will have to escalate and need to be treated appropriately there is no question about that but when escalating things having a well-defined mitigation plan or success criteria again being specific about those things will not

only help avoid lot of back and forth communication and Chaos it will also help hundreds or thousands of developer hours depends on the size of your organization the worst thing that can happen is I get a issue in the middle of the night and I try to look for an answer and if the answer is something like it depends this is not fun also you might be part of a larger organization with multiple security teams trying to run multiple initiatives or campaigns or smaller organization trying to do multiple things with good intentions in both cases software team is going to receive all the issues at once and if the team is resource constrainted they're going to prioritize

some issues versus others and some some of the issu is going to wait now the question become if it can wait now why not do it before right so ruthlessly prioritize security initiatives or campaigns within and across your organization it will not only help protect the security teams brand within the Builder Community it is also Alo very essential to build trust across the Builder teams finally I want to end with couple of cultural things changes take time when you try to introduce new processes or practices you might feel like developers don't listen or like you know they are not um you know they don't care about security but most of the time that is not the case

because security was an afterthought traditionally now we are trying to bring that into mainstream now it's going to take some time and practice for teams to get used to it the one best thing you can do is besides doing your organization Security Programs find your allies within the development teams so they can act as your eyes ears and eyes and ears out there they can ask questions like hey have you consider security when doing things so reminders like that are very crucial for changing the security culture across the development teams I have seen organizations change their security culture over the period of 1 to two years through constant reinforcement and reminders so changes do happen this is my final slide and my

favorite one until 2017 I learned about absolute minimum security that is required to do my job job at that time I started working with one of the security engineer and for one of my projects and he taught me about lot of cool security things and he advised me to go to lot of conferences like bides and take some trainings and I really enjoyed security side of things and eventually I ended up joining their team that helped me expand my knowledge across various security areas ever since whichever the development team team I am part of I always look for opportunity to do security improvements and advocate for security things and also I look for people with security interest and asked

them to take similar trainings I took in the past so if it is not for that one security engineer I wouldn't be here and also I would not be doing any of these things so building security communities and mentoring people at work goes a long way you could potentially influence the entire organization through the people you mentor and Coach I think that is end of my talk and once again I really appreciate everyone for being here thank you thank you sing