
okay so we're going to get started Mr Sing here um he's actually a software engineer who specializes in security and compliance all right sing take it away thank you welcome everyone what a fantastic two days I know this is a pretty much the last talk after two days and I'm surprised to see there are so many of you here I really appreciate that my talk is the road to developers heart I thought of naming it as B things but if I could write a wall of texture here that would be how security practitioners and software developers can work together peacefully productively to safeguard our business and customers or something like that what I'm going to talk for next 20
minutes I've been a software developer for more than 14 years and I worked as a security security jobs and responsibilities for a few years in that during this journey I get to see how different the perspectives are from both sides and like on how to solve the problem or what problems to solve even on top of that every project comes with certain constraint finite time and budget when you add this constraint to the difference in perspective it creates challenges challenges become friction and things get escalated in this talk I'm going to talk about few things that help me and my team in the past to reduce those friction and in the talk with Q&A before we get any further why does
it matter right if there is a security issue or a security requirement you can escalate push people to get things done why not do it like but in my opinion it's not just about solving one or few problems at hand in the long run we we need to protect our customers and data and you cannot do it alone you need allies you need get help from wherever you can get so for the long-term success security and software teams need to work together and feel like they are part of the same team can we reduce all the challenges maybe not but we can at least try so first off building trust this is a very obvious thing to say but it's
really hard to do consistently when everybody work together as a team day in and day out it's relatively easy to build trust because you see them every day but most of the time security teams work with software teams on a short-term engagement and U it doesn't give them much time to get to know each [Music] other okay sorry I was supposed supposed to have a gif here it's not there but yeah um so you work with the team for some uh at the last minute work with the teams for a few um you know few weeks and you've identified some issues and sorry yeah you worked with the team for a few weeks and you identify some issues
and you tell them that you know this thing cannot go live it doesn't really help build trust [Music] so how can we fix it there is unfortunately there is no one right answer for this one because there are a lot of human elements involved here but I'm going to call out some of the things that we can do in the future slides but at this point I'm going to call I'm going to tell some things how things have changed once you establish the [Music] trust early in my career I used to be very hesistant when working with security professional to share some of the things that I thought might be wrong but once I establish the trust and
I I once I establish the trust I now I go to them whenever I couldn't solve any of the nice to have security feature in my product root map I go to my security peers and ask them to advocate for it and it really works so developers know the the product in and out and they know where the backlogs are and sometimes once you bu build the trust they will get bring you some interesting stuff that you didn't even know existed that's a very good Recon opportunity all right there used to be a time when it takes months to get any security consultation done and thankfully things have changed now which is forther better having easy access to security
teams helps reduces the development velocity when building things or you know fixing bugs and it it it it is more helpful than you think again it's one of those things it's very easy to say but you know it's very hard to do when everybody is busy doing something so find your revenues you know it could be periodic office hours or you know uh review review forums or like establishing a asynchronous communication mechanism through which the velocities are a little bit faster that would help teams to build faster also staying engaged with the teams through various events like you know periodic monthly learning series or something like uh sending even a big Weekly Newsletter or something like that
letting the team know that you are available to help make them feel like you are part of the team and it helps build trust so cool unfortunately I I want to just uh just a disclaimer I had a lot of gifs in the final presentation I'm not seeing that here so I'm kind of a little bit uh you know surprised but um that's on me though so engaging early so early detection of issues help reduce the cost and that's for the very reason organization started shifting left which is a great thing but at the same time shifting to left might cause disruption to the product development especially in the early stages because early in the stages
developers want to build fast Bill Scrappy fast iterate on it faster but if your organization have a lot of rate tapes and you know processes then it might be hard to move faster so at the same time security should not be an afterthought so we need to have a balance here by working with software teams to customize the processes so that they can move faster but still it is safer there was a time when I was part of a security organiz when I was when I was part of a team what one of the teams supposed to do an annual audit but they couldn't find time until end of the year and they decided to do before they go on
vacation and they did a great job we had a bunch of issues during December first week and some of them were expected to be fixed before end of the year fun right so things like that could have been easily avoided or if we have given advanced notice that would have helped us prepare better unexpected things happens like lock 4J but we cannot do anything about it but if something can be planned let's not let that be a surprise I talked about uh couple of soft skills and program management skills that we can use uh in the past through slides now I'm going to talk about how we can leverage technology and you know practices to make life better
for both teams automation doing things over things over and over again is a chore obviously nobody likes to do it it could be things like running automated score scanning tools or you know checking for software misconfigurations and things like that so finding a way to automate these things can be helpful once I was a part of a uh team that was heavily used using database programming language for which there is no um widely available static code tool tool available we were doing a lot of manual reviews and it was error prone finally we found a tool uh that was like we we procured the tool and then we were all happy that you know it's going to fix all the
problems once we integrated it we realized that it's borderline unusable because of the false positives so the we we spent a lot of time working with uh developers specialized in the language to fine tune the uh you know custom rules and then we made it workable uh it was a lot of work initially but it was a great investment for both software and security teams so this is one such example you could do similar things with other tools like you know um maybe software configuration misconfiguration checks or even coming up with the mandatory security test cases and then you know integrating with existing um cicd integration good once I was part of a security team
and one of the teams came to us for a consultation application team came to us for a cons consultation we had a really good specialized smart uh infrastructure security person who started giving deep down networking Solutions and some of the solution we didn't even know at the time and like it was not prototyped and then the uh we don't even know how that would fit into existing ecosystem and the team left with more questions than answers so things like that and ideas like that are great but if you are not able to integrate with the developers not able to integrate with existing ecosystem it doesn't really help or it is bit unrealistic in my opinion
so this that that solution could be the right long-term solution but if that is a long-term solution that should be a separate initiative because it is very hard for developers to build a new security solution when they are still trying to solve the software problem so providing realistic recommendations are very helpful for the software teams most of this security questions or even software questions can be answered with it depends which is vag at times because without getting into the details of things or nuances of things just answering it depends uh it's kind of make lives harder for many people at the same time as a security professional you don't have to find all the solution it's it's just that work
sitting with the software teams and understanding all the various options available and helping them don't find the right solution might be super helpful also you could do some tabletop exercise kind of lightweight tabletop exercise kind of activities in advance like before the project initiation and kind of talk through all the foreseeable scenarios and how to address them and that might set the Baseline for software teams to apply some of the security things when they start building the pro product and the process and they can embed that in the
process security is a job zero for most of the organization or job one however you see it so if there are any security issues you should escalate and you know U that there is no question about that but avoiding unnecessary escalation and having a consistent risk assessment framework goes a long way and also when you escalate having a defined mitigation or success criteria helps a team tremendously the worst thing that can happen is you get called in to fix the issue in the middle of the night and you go see you know the solution and the solution is along the line of it depends it doesn't really help the case also if you you are part of a large
organization you might have a multiple security teams trying to solve the security problems and they might have their own priorities and trying to do the right things and at and they might be running as campaigns at all at once but at the receiving end of it there is one team that is going to get all the issues and that is not fun and when the team is very Source constrained and they get all the issues at once they going to prioritize themselves on which problem to solve first and basically now the question become if it can wait now why why don't we do it before right so ruthless prioritize issues within your team and across the organization so that
it is escalated based on the impact
cool finally I want to talk about uh couple of cultural things that we could do uh to make things better as a as a security practitioner when you try to take when when you try to change the culture organization culture or you know introduce a new process you get to see things you get to when you see teams do the same thing over and over again it's kind of frustrating because you know you feel like teams are not listening to you but that is not the case in general because security is always considered an afterthought and now we are trying to bake that into the mainstream system so when when you do that it takes time and practice for team
Team to you know get used to it so changes take time sometimes you don't notice the changes that's happening but it doesn't mean that the changes are not happening so the one thing that you can do is find your allies within the team so they can be part of the team and during the process project planning meetings they can ask question to the teams like hey have you considered time for doing security things in this or have you this doesn't sound right can you go talk to a security person right things like that and reminders like that is makes a huge difference I have seen organization change their security culture over the period of you know 12 to 18
months uh through constant reinforcement and reminders so keep pushing changes will happen it's just matter of when finally I want to end this with my uh one of my personal story almost off of my career I was I just learned bare minimum security required to do my job and in 2017 I started working with the security engineer for one of the projects I was working on and he recommended me to take some uh trainings and I took them I really enjoyed it and I started talking to to him about more about security and I eventually ended up joining their team then I was recommended to go to various um events like B sites and everything and I get to see whole life
cycle of security things like from appsc to infrastructure to cloudsec and everything and then I I expanded that knowledge within an outside of work with that knowledge I wanted to contribute in my day-to-day job and I have been a security Advocate ever since in in my day-to-day job and also I started scouting for people to take similar training so that they can make a difference too so if it is not for that one security person I wouldn't be here so um mentoring and uh you know coaching people in workpace and creating communities makes a big difference also you can't possibly possibly in all the rooms where you want to make the difference so you can force
multiply through people you mentor and Coach all right that's all I have once again thank you so much for coming to this talk and [Applause] yeah that was amazing okay Singh we do have one question for you sir um can you give us an example to what you meant by be specific yeah exactly so yeah thank U this this is something like um we run into a lot whenever we go and ask for uh whenever we work with security teams sometimes the teams U it could be developers try to explore a lot of new Frameworks and things and sometimes the answer become very generic based on what they already know like without getting into the specifics oh I have seen this
before maybe you could do this to you know fix things and like without understanding the nuances because whenever we go to security people to get some opinion sometimes we would we might have spent like reading through the uh framework document or like we we might have like you know tinkered with the whole uh initial one we we might have taken the oneone classes and you know played around with that when we when we with that knowledge when you go talk to a security person and they're not understanding what we are working on the internals of it and giving a generic recommendation on hey go go do this go do that that is kind of you know um it's
not giving us you know that confident that like okay he that person is not understanding and giving generic solution so that's what I mean by like you know being specific on things that you want to you know address
yeah okay well that was fantastic we appreciate you sing and we have a little something special for you from socket security thank you all for coming we could not we wouldn't be here if it wasn't for you and I just want to thank all of our volunteers of course all of our sponsors especially um socket security for giving every presenter a gift that was lovely um we look forward to seeing you next year we're going to wrap up a little bit early you can just uh take your flow relax a little bit before the next and last presentation of the day thank you all so much thank you