So hi everyone, if you're here, you're seeing these slides, you're probably here to learn about how to achieve proactive security and compliance in your software development life cycles. We're going to cover a little bit about how to deliver fast and improve security posture in a highly regulated industry, how to make proactive security decisions around risk and third party code, how to leverage some new tools and automations to help developers optimize cloud native application security and from Samir's perspective, learn a bit about how to make a case for a business case for developer security operations within your own organization and teams. So I'll let Samir introduce himself here. Thank you, Megan. Thank you, Lauren. Hello everyone. Good evening. Good morning. Good afternoon. I am Samir. I am head of engineering for equity knowledge partners. Equity is a leading research analytics firm. We have been in the business for 30 years now and by the nature of our business, we work with financial services companies. So therefore, this is a very strong case for why we take security very seriously, not just in the way we do business, but also the way we have been designing and building applications. As head of engineering, I am responsible for most of the security and development best practices that we have brought into the organization and I will love to speak about some of those with the developer today.  I am the product marketing manager specific for Sneak ISE, so sort of the voice of the product externally and specifically focused around securing your telephone code and configurations. So before we hop into the topic, I'd like just Samir for you to talk a little bit more about the technologies in your stack and what sort of challenges you're first facing and your journey. Absolutely. Thanks. So talking about the technology stack, so we have been mostly in our Microsoft shop for a few years. We have been working with different versions of .NET framework in the past, but for the last several years, after the advent of .NET Core, which is the platform independent cross-platform version of .NET that came out, we have been using it quite a bit. So that is the primary backend framework that we work with. On the front end, since everything that we're building is mostly web-based service or an application, we are working with either React.js or Angular, as our single-page application frameworks. And in terms of the databases, there is a variety that we use. So SQL server, MongoDB in many cases, and then some of the cloud mid-tips ones like Amazon Aurora and so on and so forth. But yeah, mostly it's Microsoft heavy stack that we are generally working with. Okay. So Microsoft heavy, you also understand are using Terraform for your infrastructure's code and containers as well. Yeah. So when we, if we talk about the infrastructure that hosts everything that we've been building in these years, we are deploying them mostly as containers today. And then we are deploying all in cloud. So there is basically no on-prem deployment for the technology that we have been building. So we are fully hosted into AWS. And the way we set up our infrastructure is we have brought in infrastructure as code automation using Terraform. So everything essentially gets deployed using the code. So there is very little manual intervention in terms of setting up creating environments and then deploying applications.  Gotcha. So it's good to hear a bit about the technologies in your stack. I'd love to hear next, starting in on this question about the journey. What got you thinking about making changes and how you handle security operations and integrate sort of DevOps with security out of security? Okay. So I would like to take a minute to talk to you about the journey and equity with respect to technology. So as I mentioned that we have been in the business, we've been in the market for close to 20 years now. And technology was always something which was for at least 10 years, technology has been an important piece of the puzzle of how we take our services to the customer. However, for up until 2016, early 2017 also, the setup that we had in technology was not very formalized. So we were building technology, but it was being mostly done in isolation. So one team here and there or any other team somewhere else, they were building something, but it was within silos, within isolation. So because of that, everybody was essentially following their own set of practices, their own set of ways and means of doing things. There was also a diversity in terms of the technology standard we were using and so on and so forth. And I think the biggest factor that was kind of resulting into these silos was that we were not deploying into cloud, we were deploying on-prem. So there were a number of servers that our IT used to be managing and maintaining for us to enable these technologies to be given to the customer. But then in 2017, essentially we took a leap of faith and then decided to make or take technology mainstream. When we say that, it means that we started to think about how technology is going to be the edge for us. When we look at ourselves, our services and compare those to the competition, so we decided that technology is going to be the leverage that we would like to enhance, take benefit of. And then when we did that, we very thoughtfully decided to do the right things. So we did not want to move into identifying things that we were supposed to build and then think about how do we take them to market. We started to devise a plan, how do we remain in compliance with the very regulated industries that we work in, which is financial services, with respect to the software and the technology that we will start building and we will start offering our customers. And since everything was revolving around things to be built that were to be used by our customers, there was very little room for us to really make any mistake. So the traditional DevOps process where you build something and then you get it into the security hands, let them scan it, find out the issues that you fix, that reactive approach was not something we were comfortable going with. So we started to think about the entire pipeline and then we essentially found that there are obvious gaps, both in skills, processors and then how do we system together. So we took some time to figure that out and we started with the secure SDLC as the process from the WorldGo that we wanted to really follow from day one of when we start to build these products. And then that's when we started to look at who is doing what, what are the different teams that are going to be involved, how do we bring them together and make them agree to our process implementation, which is going to guide us through the rest of the journey that we were taking the plans in. So yeah, so that's how we basically started and I think when we reflect back today with 50,000 plus users on our applications, we feel pretty good about that decision because we were not, we are not really, we never find ourselves in a situation where we are regretting that decision, whether it was architectural or inter-regulated and then trying to solve it. We essentially have very clear view on what could go wrong, so we should not do this, right? And then essentially developing things right from the first go. So we, so yeah, this time that we spent initially in 2017 in figuring out things has been pretty useful. Yeah, that sounds excellent. You were thinking much more preactively and so you no longer have that putting out the fire sort of mindset when it comes to fixing vulnerabilities. And so this sounds like a massive undertaking, like you were both thinking about a cloud migration project and also smartly so thinking about how you could embed security throughout the process, the sort of like modern way of thinking about cloud application security. But how did you get everyone else on board with your transition to this more formalized DevSecOps approach to security? Was there a learning curve there? There certainly was because as I mentioned, this was the leap of faith. So there were gaps in our understanding of how different tools work, if essentially what are the tools available at our disposal really that can help us to streamline the process, reduce spectrum, help us create a process where everybody knows whose responsibility is what and then not to land into a situation where security is somebody else's problem. So we did have a steep learning curve certainly, but I think what's really great about equity is that people are very open to learning new stuff, learning new things. And so when we put together a blueprint of how we want to run this program together, we basically involved the CTO who essentially is the head of enterprise IT and in which essentially we're going to be taking care of both the on-prem setup, the clouds, infrastructure that we run on, how does the on-prem communicates with the cloud and how do we ensure the larger perimeter security of all the infrastructure. So that's it through the CTO. Then obviously from the compliance side, there was a CISO, the Information Security Officer and his group. So these folks will be the ones who come when you have an application where you're going to deploy it to finalize and sign off on the last bit. But we very clearly wanted to do this differently. We did not want to wait till the time developers have finished building something and then go into the CISO and then for some information security set up for certifications, for getting it through so that we can deploy. So we basically brought in all these different parties together. We told them, shared our vision of how do we want to build this engineering function, what are the places, what are the areas or what are the workflows we think are going to be requiring their involvement. And then with their assistance, we were able to put together a GRC process which essentially is something which was that communicated to other different stakeholders. People were made aware of the different requirements, different stages of that process and where somebody has to get involved. And then tools required for managing this workflow, etc. They were agreed upon. It took us a while. It's not that we did not start working, but we did not take things to process before this setup was in place entirely. So with regards to the question that you posed, there was a steep learning curve, but I think the intentions, the way everybody got together understood what we were trying to solve and committed themselves to it. I think that really made it not so difficult to do. Yeah, it sounds like it was a lot of effort applied, but for a pretty high payout, you're able to bring the teams together and break down some of those silos that you spoke of before to have a much more efficient, painless process. I just one follow up question. I'm wondering, you talked about bringing leadership together, creating a vision, developing a process to make procurement and mutual understanding of what you were signing up for throughout your teams. But how was it on the sort of developer adoption side of things, communicating to the people that maybe would be taking on and using these tools in the day-to-day? So one of the things that we were specifically doing in equity was that we were not really going out in the market and hunting for the talent because we were trying to do something different that was never done. Our approach was always that we were helping the existing teams scale up, understand, pick up the skills that they are not comfortable with and then take them along in the journey. But we never wanted to really go out, import somebody in who will bring a different mindset, a different culture, and then try to impose things on the world. So I think that was one of the decisions that has helped us to bring the developers together on this journey. Now, having been a developer myself for 17 years, the usual mindset has been that as a developer, I am responsible for building stuff. Security is something which comes last. So if I find something in a VAPT, I will fix it. But I want to really focus on building the functionality. So that mindset is what we started to talk to developers early on. We started to share, as I said, the vision with all the stakeholders, including the developer staff, told them why this is important to be handled at, in fact, the concept of shift left is what we started to talk to developers from the beginning of the program. We very specifically gave them these cases, help them understand why is it important? What is it that it will help us achieve? Why is it important to test before you start writing the first code? Why is it important to ensure that the third party components that you are going to be using, they are the ones which are not having any vulnerabilities and how can you validate and how can you test those? And in that sharing of vision, that also imposing faith into the developers that we trust that they will be able to understand and pick up the process that is eventually going to be put in place, helped us to really sail through that process. So it will be unfair to say that we were able to address this on day one, that went on the case, but we were able to identify specifically actions that were supposed to be taken on our side. For example, specific developer trainings, resources to be given to the developers using which they can speed up this particular learning curve and then still giving them time so that they can make mistakes and they will be able to correct it as we were moving along the journey. I think that has helped us to buy and get the buy-in from the developers particularly and I think which was the most important buy-in to be able to bring about the adoption to the secure SDLG that we have here at RQD. It was that they could, it was really about mitigating that risk early and that developers could make mistakes but they would have the resources to them to be able to apply, learn, understand and apply their own fixes in the process. Exactly, yeah and I think one of the important benefits that we have kind of been from cloud adoption is that we can afford to make mistakes because with the help of tools like IAC and Terraform, it's really very easy for us to put something together up, deploy application, see if we run into any problems and if we did, on our click of a button, we can terminate the instances, terminate the infrastructure and create it back again without having to get involved into delays, days, days will be smaller compared to the weeks and months that it used to take when setting up instances around them. Yeah, you can deploy much faster but you have to have just the same amount of security in those processes. Yeah, so you gave me a kind of perfect segue there mentioning your how IAC and Terraform played into the change with your migration to the cloud and your DevOps processes. We have a question for the audience here. Sarah is going to flip the slide. Just a quick poll here, you can answer one, two, three, four in the chat. Are you implementing infrastructure as code at your organization or within your teams today? Let's see, about 56% of our audience has answered. Oh, it's going up. I'll let for a couple more people answer the poll. So it looks like we have the right crowd here today. Roughly half of you are implementing IAC today and about 20% planning to in the next year. Okay, going to close the poll now. Our next audience question here is around IAC security. So how or when do you handle IAC security today? Is it catching misconfigurations and deployment like Sameer was talking about or is it configurations during development? The newer process that Sameer was talking about. There's also the painful process of manual security reviews or just not dressed today and it's something you're interested in learning more about. Okay, so results are looking like a mix of things. So all sorts of different variations for how IAC security is handled. And it's a relatively new concept. So I feel like everyone sort of figuring out what is best practice or looking into new options for how to secure their configs. Okay, with that, we're going to wrap up the polling for a bit and talk about one team's security as a shared responsibility. So Sameer, another question for you. What's the best way, I guess, to shift left to get others involved and integrated in security without creating friction between all these different teams? Security operations and developer operations and the actual application developers themselves? Yeah, great question. Thank you. In my experience where I have been part of teams where security was always considered to be somebody else's problem, usually because the way organizations have been set up, generally, the departments that are made responsible for ensuring the security posture of the organization are the ones that are really not into building applications. They sit as silos, generally, and only are the ones that are going to be sending across policies and documents your way, generally. We were not any different, at least we were in the same boat really. Okay, but we were very sure from day one that if we have to deliver stuff faster into production without making our customers wait for either a feature or a patch or a fix when things are in production, we cannot afford to keep the responsibility to be with a different team and out of the developer groups. So the fundamental principle that we started to think about, talk about with different stakeholders, including the developer teams, the information security functions, the enterprise IT functions, and even the executive, we started to talk to them about security being a shared responsibility. So when we said that, we say the first line of code that we will ever write, whether to make sure that that is not going to cause any security vulnerability, either to the application or to the infrastructure that could be hosted on, has to be something which the developers will have to start owning. Having said that, we also started to talk about that the responsibility and the ownership of information security functions will only not be limited to giving us guidelines and directions. They have to come together and get involved into helping us identify flaws early on in the process, not when things were ready to go live. The way we started doing that was we started to implement programs like security champions. Now, when we say security champion, it's a fancy word. I see this doing rounds on internet all the time, but what we really started doing was that since most of the developers will take some time to ramp up, understand security and understand information security requirements and compliance requirements, we decided that so the way we have structured our product development groups, these are teams of anywhere between seven to 10 people. The concept that Amazon followed, we can feed these groups by two large leaders, not more than that. So these groups will have a group anywhere between four to five developers, one or two testers and another holds. So we brought security to the pod directly. So we started to invite nominations from developers who would like to become security champions for the pod with very specific clear KRS that they will have to own security posture of the application during building, during writing the code and before it goes to the production. And then this particular role of security champion was then the point of contact for information security groups who can pass on requirements like guidance, directions, policies that we had to adhere to so to say through this particular person into the product and groups directly. So with this, I think the biggest benefit that we got that the silo that was otherwise existing between the information security and the developer groups immediately started to shorten. Any change in information security requirements, for example, at the org level, were immediately transitioned into the pod by means of this security champion. And we have seen that over the several years that we have been doing this now, these champions have essentially started to own more than just that. For example, they will become point of contact for external vendors when we get our applications pentested annually. So they are the ones that become bridge between the pentester and the product group and the information security functions, thereby being able to maintain one single golden source of truth in terms of the findings and so on and so forth. So I think this is one aspect of how we were able to bring about the sense of security being a shared responsibility. Because we were able to bridge and take the developer teams to the information security teams and bring the information security teams into the developer group by means of creating such bridges between the two. Security champions within each other teams. It's very smart. And so I think after we wrap up this topic, we had one more audience question. Where does the responsibility lie? So who is responsible for securing your IAC? I just launched the poll here and we'll give it a couple seconds for everyone to submit their answers. Okay. And it looks like the results are mixed, but definitely leaning towards the developer, SREs, infrastructure engineering teams, people that are maybe directly managing Terraform files and making changes in those configurations or people that just make slight modifications or are building their applications on top of IAC. Okay. And this brings us to our final topic here today. It's the impact. So proactively improving security and compliance at Acurity. What was sort of the business value of implementing these changes with sneak to Acurity? Right. So as you can imagine, when we work with I think the largest of the banks in the world, who many of whom are still not very comfortable with Cloud, I'm not saying that they will not be because they are getting there, but it's still something which is supposed to be not a bank's thing. So the, and then since the decision that we made with respect to the technology that we were building to have it deployed into Cloud and then have no negotiations on that front, we were to remain prepared for the compliance and regulation related questions coming from our customers, because essentially we're going to be asking them to bring over their data into our systems and not the on-prem, but on the Cloud. So the usual process remains that we are sent multiple pages of due diligence questionnaires around the security posture, how do we manage data residency requirements, how do we ensure that the data and procedures remain in compliance to GDPR, for example, right in the context of Europe and so on and so forth. So with regards to things like those, you were able to very confidently answer and then convince the customers that the infrastructure, the application and the data flow process that we are implementing is kind of food proof and there are auditability, there is observability built into this and then we can respond to any requirement either today or in the future that they may ever have to respond to their regulators with regards to anything. So bringing security into the DevOps process, into the development process and we were taking over bringing the different groups responsible for managing security together has helped us go out in the market and then confidently tell us was that the technology that we're building is not just only user-friendly, but it is secure to on every aspect that is ready to pass the test of regulations anytime. Yeah, you were able to improve not only your security posture, but the confidence that your customers had in you for just being so much more secure. And was there sort of any impact you mentioned there that the processes got a little better, the security development team started to understand that security was a shared responsibility there and the technology was able to sort of correct the skills gap between I know out of code, but I don't know how to fix my code in the security sense. Was there any sort of impact on developer productivity or feedback on that sort of process adoption of developers starting to handle a bit of security issues? Yes, so I think so this was one of the areas that we thought would be challenging how do you continue to expect and ingain the productivity that we wanted from the developers because we wanted to deliver fast, we wanted to be able to roll out features very frequently into the production, but how do we do that if the developers were to remain fixated on identifying security issues and validating and fixing them before moving to anything else. And then therefore platforms that were capable of doing this we started looking for them and very gladly we've finalized SNEAK as our world platform for that. So what SNEAK has enabled us to do really is the different integrations possible. So SNEAK has a CLI option available, SNEAK has APIs, SNEAK has plugins, the developer environment plugins that we can use and add in. So we have actually brought in all of these integrations into the process. So for example, Visual Studio is our primary developer environment. So SNEAK interface, SNEAK plugin for Visual Studio is available. So developers really don't have to do anything extra to be able to write better code because the SNEAK is monitoring, SNEAK is monitoring what we are writing. So anytime we write something, there is a problem, it gets flagged, the SNEAK plugin will tell us. So we were able to reduce the time that was otherwise supposed to be spent by the developers into identifying security problems by introducing tools like SNEAK. And therefore not having any significant impact on productivity. And then people can actually go about doing their development work business as usual. Because in our case, identifying security vulnerabilities or license compliance problems with regards to the third party components or open source is really part of the process. We don't have to do anything extra to start addressing or start looking at those aspects. And because of the tools like SNEAK, I think this is true for not just the dotnet code that we're writing, it is also true for IAC. It is also true for the Terraform scripts that we have been creating because we are able to scan Terraform on the go. So while we are writing it, I think we get feedback at the point when we have integrated it into an execution environment, we get feedback through the CLI. And then there is the API option. So we were able to find these smart ways of making these integrations possible and work for us by not really having any impact on the developer. Yeah, that sounds excellent. So embedding it early.  Yeah, so the way we work with tools today is that even when the developers are sleeping, SNEAK is doing its work. So when we log in for the first time next day, we would see if anything has gone wrong or if there are new vulnerabilities that were reported as a Slack message. So we have integrated SNEAK, for example, and Slack, which is the primary communication medium for all the developers. So we don't even have to open the code base fairly. We will know what to do, how to fix those and so on and so forth. So yeah, so I think these integrations that are available as part of the technology set that we're using have really made a big impact on the way we do software development now. Yeah, and I'm going to ask you a sort of hard question here because we talked about how this was a journey and you put enormous amounts of effort in engaging all the different stakeholders and communicating to developers with the security champions that security would be a shared responsibility and help closing the skills gap between security knowledge and actually applying finding and applying the fixes. But given what you've learned in this whole journey of modernizing and formalizing your software development practices with security and security, what sort of top line advice would you have for other engineering leaders? I think from my experience, the advice that I have is don't leave security out of the mix fairly. It may sound to be daunting at the beginning, I guess, because you have to bring along different people with different priorities into the mix, but it is best at rest at the beginning rather than late in the process because then once your manufacturing lines have started to deliver output, then it becomes really difficult to start addressing these problems. So I think the one advice that I have is do not leave security out of the SDNC. It has to be you know, affected from day one and I think shift left is the way to move forward. All right. Okay. And now we're going to just thank you so much for everything you had to share, Samir. We're just going to open it up to questions from the audience. Okay. Well, it looks like no one is curious that we have, Samir has spoken so eloquently and so comprehensively that we are all prepared. So with that, we can just move on to the next slide, giving you some useful resources. A couple of these are specific to ISE security, but we have a resource here on ISE security best practices. You can check out a written version of what Samir talked with us about today in a Q&A case study written up nice that concisely summarizes the points of today, saying what Q&A was interested in securing with their cloud native application and exactly how they went about doing it, what successes they found. And we also want to offer you guys some free stuff. So coming in with Sneak, you can sign up for a free account. We hook up to all your Git repos and tests up to I think for ISE up to 300 tests a week are free. Our IDE plugins are available for Visual Studio Code and JetBrains. And we also have a service called Sneak Advisor that can scan your open source code and find if there's any vulnerabilities in your packages. So all that can be found on the Sneak site or in these resource slides here. Thank you all for joining us. Thank you to the Linus FAC Foundation for being wonderful hosts. Anything else you'd like to add Samir? No, it was a pleasure speaking with you and the wonderful audience. Hopefully, the content we talked about is useful. And I would like to wish everybody the very best in their security journey. Wonderful. Well, thank you so much, Lauren. And thank you so much, Samir. And a big thank you to everyone who attended and participated today. We hope to see you back at a future webinar. And you can look for this recording on the Linus Foundation YouTube page later today. Thanks, everyone. Bye-bye.


In today's video, I want to show you how you can probably make a mistake and start writing a new future in the wrong branch. What do you do at that moment? How do you transfer it into the correct branch? Maybe you are working on master and you realize I should have been working on this new feature in a completely other branch. If this is the video you're interested in, then you are going to be able to learn how to use git stash and git stash pop. Let's jump into the coding. So let's say I'm working on this file and I change this to about page and that's a change that I've made. I come here, I will add my commit, git commit because I've made something really inspirational. And I will say added title. And then after doing that, maybe I add a couple of divs. And those divs have a URL which has a number of lists. So let's say we had items in there and I've done that so I want to git add. So now my particular new commit that I've made has been staged. So let's say I realize I'm actually working on the wrong branch. This is not where I actually wanted to have this particular feature implemented. So this git stash, which is a very, very nice tool to use. So all I need to do is type git stash. And what it's going to do is that it will pick up all those changes after this commit of about page. So it will get those and hide them in memory. Then what I need to do is say, OK, now I need to check out of the branch that I wanted to have, which is the new futures branch. And since I'm now on the right branch where I should be having my new feature, I'm going to type git stash pop. And when I hit enter, it brings the new changes that I hadn't committed, but I had stored in memory. So it brings them, it puts them in the right place. So now can actually git add that git commit and write a message and say new feature added. And that will allow me to have my two different branches. When I hit git branch here, you'll see that I have my two branches, which is git master and git new feature. And if I git check out of my master, you'll see that we don't have that new feature in here. But if we go to the new branch, which is git checkout new feature, you'll see that we have our new feature in here. So you can be able to actually work with some particular items that you hadn't committed, but you didn't want to lose and you wanted to transfer them to a new branch. So this is how we use git stash, git stash pop to make sure that we don't lose our changes, but rather we can transfer them to another branch. Otherwise, don't forget to give this a like, a subscribe and hit the notification bell for any new videos.