 Welcome everyone to the session from Neetu Tripathi. She is here with us to talk about championing security for your agile development. So without further delay, what do you think? Thanks Manju. I'll start sharing my screen. Hi, welcome everyone. Today we'll be talking about championing security for your agile development. A little bit about me. I'm heading security for ThoughtWorks India. And my area of interest is the continuous security, assessments, fit modeling and everything in between. I have spoken myself at a few conferences earlier. And yeah, let's dive into the topic. So today with respect to championing security for agile development, I wanted to touch upon a few things. With respect to that, what does the attack surface look like for agile development teams today? What do we mean when we say security in layers? How do we leverage the agile rituals? In fact, the tools and rituals in agile to make sure that security itself is also agile in our context. How do we build security in and get agile development teams to that level of security maturity? And finally, with respect to security programs that you have in your organizations, how do we design that keeping agile in mind so that we can make it effective? And we'll also be discussing the program outcomes for one of the programs that I designed and I do at scale for our agile development teams in ThoughtWorks. So in the past few years, in fact, in the past many years, we have been seeing a lot of attacks, data breaches, ransomware attacks and whatnot that keep happening from time to time. But in the past couple of years, particularly you will see there are specific categories of attacks that have gained a lot of prominence. And one of those is mostly and which we are talking a lot about today is the supply chain attacks. And out of a lot of other attack categories, I believe that from an agile development standpoint or in fact from a development standpoint in general, it's important to understand why these things are happening and what are the causes for some of these when they're happening in the real world. So for example, and it's just not a specific thing that is leading to supply chain attacks, because it's a very complex sort of an issue which gets exploited and successfully so in many cases in many organizations. Sometimes the reason would be for example, insecure pipeline components which are in use, which could then be exploited. So for example, in case of code curve, it was the credentials in the Docker image, which then led to attackers modifying the bash approach script and going ahead from there. And it did impact hundreds of their customers. And this was one component in the entire development setup as you can imagine. Similarly, in case of Kaseya, it was an insecure product and there was an authentication bypass which was the first sort of the exploit point for the attackers, which then eventually led to other issues and eventually led to the code execution. This again had a direct impact on their 50 customers and then hundreds of customers down the line. And in case of Uber, it was AWS credentials that got checked into GitHub and very soon exposed to the attackers and were abused by them to gain access to close to 57 million customer and driver records. And then there was a lot of direct financial loss also millions of dollars lost there, a lot of impact to Uber as an organization. And this was unmanaged secrets. So while we are talking about a few of these, there could be many, many reasons for these but mostly you will see how closely they are related to a lot of things which are under the control of a development team that way. So the attack surface itself reflects what's happening in our development environment many times. But when you look at it, there is so much changing in an agile development environment that it becomes very difficult to pinpoint on one thing as such. Now there are other challenges when it comes to agile. When you look at it, the whole landscape itself has changed, which has completely become microservices landscape. A lot of development happens that way. It's a lot more distributed now. The attack surface if you look at it from an attack perspective, it's quite distributed, it's scattered. And that increases the possibility of getting something that might be vulnerable or loosely configured, so to say. There are also other things with agile development, there are faster releases happening, a lot is changing, the environment is quite dynamic for all of us. There is new technology coming in, a lot of new tech stacks that keep getting introduced from time to time. Even the adoption of agile is not complete for some of us. Some of us are still in the journey of becoming agile. So that is also, we were not purely there, completely there. Then for many of us, many of our businesses, the need for compliance is also there. It is a regulatory requirement for securing data, for securing assets in various geographies. And then when you think of all of this amalgamated to scale it across different teams in your enterprise itself can be a challenge as well. So, when you look at your development setup today, I just wanted to show a sneak peek of what it looks like and what do we talk about when we will look at it in different layers. When you look at the development setup, typically you will see that you have a developer pushing in code to your VCS. It gets built with your CI and then you turn out the artifact or the container artifact, push it to production and deploy. There are also a lot of other things within the supply chain that you are interacting with or consuming from, for example, there are public reports from where you are taking your libraries or dependencies. There are images being pulled in from different registries. So a lot of things are being ingested to perform the software that you finally have or that application that you have hosted. But apart from these components or code, these are all essentially codes in different formats. So all of this automation that we use for development, we also have a lot of people surrounding this automation setup. So with respect to coming back to the supply chain attacks that we were talking about, while you will see that I have highlighted a few components here just for you to understand that all of these can be different points of compromise as a development component. All of these could be compromised depending on the vulnerability which are there, vulnerabilities which are there in these systems. But there are also the entire set of people surrounding it who could be compromised or could be tricked into doing a lot of or accepting or installing things which they should not. So whenever you talk about security of agile development or it tends to the discussion tends to be about DevSecOps and we tend to focus a lot on having security tooling on the pipeline. Many times that tooling may not be enough. Now the security tooling on the pipeline helps you identify and detect vulnerabilities in the code that you're writing. And essentially in different ways with the CEA with SAS and all of these other tooling which are there in the pipeline. But that may not be sufficient for a lot of these other attack scenarios that you keep hearing about today or which are so successful today. For example, logic issues in your product which can be exploited, session issues, supply chain attacks that we keep hearing about social engineering, phishing, endpoint issues, hardware, software issues are there. There are zero days which cannot be accounted for. So all of these, for all of these we need to look beyond the security tooling which might be there in our pipeline. So how do we look at it? As a development team, in fact even as a security team, the idea is that you look at it in terms of layers. And I've tried to loosely break it down into different layers here. So you would have the people there, network or cloud, excuse me, the environments which are there, the infra components which are there, your supply chain, software and your custom code itself. Generally, the layer on top impacts or is and when it is compromised can impact the rest, one or more of the layers below. That is also one of the reasons why the people there becomes one of the most important and most crucial when you're trying to have security in place for agile development. So with keeping people in mind what it is that we should do, this is particularly for security teams that I wanted to call out. When you start setting up security for your agile development teams, it's important to understand first of all their development goals. What are they trying to develop? What is the business about? What is the time to market you're looking at? What are the OKRs or business objectives that are defined? What are the performance markers that the team is trying to get to? Apart from the business side, also understand what are their technical challenges and constraints? Those would be a lot of things, particularly some crucial ones from a security standpoint will be to look at. For example, how do they manage dependencies? Do they have secure pipelines? What is the kind of tooling that's available currently? What automation is missing for the teams? Where is the PR process? Are there any gating constraints for them already in place? Things like that. And I think one of the most crucial things to understand particularly for security teams is that agile development as a process is very informal. So whatever solution that you come up with or you introduce for the teams should be highly optimized and it should also be very lean. Think of it from the perspective of what they can do on a daily basis. When they take things up, they take up controls or establishing controls in their development environment. The other thing to look at is now this is something that all of us can look at whether your security or your dev teams is to leverage the agile rituals. One of the most prominent and best ways of making security agile in an agile development environment is to leverage whatever it is that you follow in terms of agile rituals. So, for example, if you are looking at sprint or iteration planning meeting, this is a ritual that generally happens at the beginning of your iteration. Think of what it is that you can tie up with this particular event which invariably will get done in the course of the iteration. So for example, this is an example from the SECCHAM program that we were driving. We had taken the teams through the entire process of performing the agile threat modeling, coming up with the right kind of threats from it and so on and so forth. But then we had the question of when do we do it? So it's good that we know how to do it, but when do we do it in the entire iteration? So this was a time when we figured out that in the iteration planning meeting will be the place where we will actually schedule the threat modeling. We'll pick up a bunch of features and schedule the threat modeling for the team to do. Similarly, you have other things like stand-ups. You could use it for prioritizing security tasks or thinking about or talking about the acceptance criteria with respect to security. In sprint reviews, if you're doing manual reviews, for example, manual code reviews, you could also combine them with security code reviews where you could look at logic issues and other things which your tools will not catch. Or vulnerability scanning results and things like that. In retros, you could think about looking at dentist findings if you have any. And also any recurring threats because, for example, entire iteration would have done threat modeling. Now, is there any recurring threats that are happening? This might be a time to look at it. When you're doing your showcase and you are, for example, demonstrating the stories that you have already developed, it might be a good time to look at edge cases from a security standpoint. Or security integration issues with other components at that time. And in fact, we have seen this work wonderfully, especially when you bring that mindset also for the business teams. For example, when you're doing showcases, you would have your business teams also or your clients also alongside. It should not be just the security expert or the sec-camp asking these questions. The group should be collectively thinking of, you know, what if scenarios where something could go wrong from a security standpoint. If you are into black log grooming, also look at prioritizing some of the high critical security bugs which are there which may not have been picked up until then. Or any foundational security tasks which you may not have picked up by that time. Apart from agile rituals, it's also good to leverage some of the agile tools. And I think one of the best tools in terms of agile development is the project dashboard. So it looks roughly like this. This roughly put it together. Like you will have a backlog and then you will have in progress items. You know who's working on what and you will have your bunch of stories or tasks or bugs or, you know, features called out in this dashboard. Now I typically you will have all of this form from a functional standpoint. You need to think of whether as a development team are you looking at security as a part of the project dashboard or not. So for example, if you are so it would look something like this where you have the stories that you have already developed would have taken care of your acceptance criteria from a security standpoint. You'll have your security validations all not just coded for but also tested, you know, by the time it moves to run. Similarly, it would also be a place where you have prioritized any critical or high risk security bugs that you have identified any threats that have been identified. And all the stories features would take care of you know security validations if that needs to be a part of it. Now typically in a real scenario you will not have each and every story having this the set of validations required in that context. But there's still be many where this is required and it should be complete only when all of that has been taken care of. So now we'll talk about building security into what are the things that the development team that we can do when we are trying to build security into the product. You know, rather than have a pen test team come towards the end and you know, do some testing and go away and then you know, next time they come in in the next quarter or maybe the next year. This is also what I have realized is one of the fastest ways of doing security in agile is when you start thinking of it much earlier from the very beginning itself because there is no designated separate timeline or period for security to happen. So from that perspective, if you look at your development setup, like we discussed, we always talk about vulnerability detection and one of the items is one of the fundamental, you know, parts for you to look at. So you would have maybe your SAS or tooling that's tooling a CA continuous scanning and so on in place to be able to detect vulnerability in the product itself. But there are some other practices which generally we consider as functional that will help immensely with security. So for example, starting with a secure source is very important, like having secure baseline images from where you can pick from when you're doing development. Or for example, you have a repo for your private repo for your dependencies, which you can pick from. In some cases, although you need to be careful because when you pick from there, it could be that so for example, many times we have seen that we are doing dependency checking and then there are dependencies which are not upgraded yet. So if you have such private reports that you're using, it's important to keep it updated over a period of time. Then you will also ensure that you have, you know, software set inventory or, you know, a bill of materials that gives a very clear visibility of what you have in terms of libraries and dependencies for your product. And I'll give an example of the recent or not so recent block per day issue that happened for many of us. And specifically in this case, you would have realized that mostly organizations which are teams, product teams where they had this kind of a setup, it was much easier for them to figure out what is affected, what is not vulnerable and what needs to be addressed. Having things like secrets manager is also very important in developing that practice of not even checking in secrets, for example, and this tends to be very preventative than detective, which is a more mature state of being. Artifact signing to help with the integrity infrastructure as code if you have it makes it much easier to have a secure configuration, for example, and also make it repeatable in the long run. And also engineering metrics like, for example, your mean time to recover or, you know, time to push particular partial production. These things can be very important, particularly to limit the blast radius once, for example, there is a critical issue that's been found. So the lesser the time you need to push a partial production, the lesser exposure you will have from that vulnerability. So these are none of these are exhaustive. So just a disclaimer there. Security when you look at it as a part of development process, there are again a lot of other things which will help other than just having security tooling is, for example, tying it up to a change management system, where you can, you know, identify, for example, just few examples here like security incidents or your card, which are related to security incidents which have been addressed and integrated to your project dashboards with respect to code. One of the most fundamental things which I would like to call out which a development team should pick up and can easily do is defining acceptance criteria and stories from a security standpoint or addressing all the security requirements for that story or set of stories or features. In terms of hardening, generally we tend to think of just, you know, in terms of network isolation, you know, across our environments and things, but the idea is to look at, do you have clean set of images to start off with when we are provisioning infra or if we are the ones managing and handling infra then are we looking at the right set of benchmarks or CS benchmarks to secure what we are provisioning. Vulnerability management itself is a big area like I mentioned, and this is actually way easier to do with the help of security tooling that's available today. There's a lot of variety for various tech tech that's there, which can be picked up. But as a development team, what adds that extra edges to be able to define clear set of test cops KPIs for yourself, or SLAs for for example addressing or fixing any high critical issues that are identified from the security tooling. And of course, adhering to that over a period of time. And monitoring generally because that tends to happen towards the end of our development life cycle. Often a lot of things are ignored. Some important things, which I commonly see are missing are you know, making sure that you are capturing the right kind of security events or auditing events, which in the case of an incident will prove to be helpful for us. But also looking at targeted alerting. So are the alerts going to the right team at the right time with the right set of parameters identified. Now at the project level, this can mean different things. So generally, you will know in a product you will have business objectives that are defined and which are tied to the results that they're looking for. Many times it would be the business objectives or you know performance objectives, which are clearly called out in the beginning itself, which pertain to you know, the product releases. The idea is here to go one step further, and if possible define so depending on what is the need for how much security is required for your product also and the kind of data you're dealing with and kind of product you have. It might be good idea to also define your objectives with respect to security at the product level. If not, at least have the KPIs defined for security in terms of what you want to meet in your in your own time lines. One good way of map to also structure and look at security that way because there are certain things which are better started at a certain time. For example, we're talking about security automation to be in place or securing your pipelines with adding the right kind of tooling. It's best to do this in the initial few iterations itself. And then later on you can have continuous scanning going on in the entire or the rest of the lifecycle. In terms of awareness that is something that should come much early on. But depending on for example when new technology gets added, it's important to also keep repeating it from time to time for the teams. Threat modeling can come in when your development almost sort of starts and can stay till the end when you keep looking at threats iteratively from time to time. And then also account for more milestone specific security events. For example, you may have pen testing performed prior to release. You may have audits which will happen for your product and all of that need to be accounted for. Not just for the event itself, but also for the preparation because practically these things require some level of preparation as well some level of self review. And then afterwards when there are issues or findings from there also time is required for fixing them, you know, addressing them. So talking about championing security and we looked at you know how do you look at the development process how do you look at the product level how do you look at it more from a micro set of metrics that we were talking about with respect to people. It means making security a part of the mindset so that everybody is doing it in their own respective roles as a day to day activity rather than as a one time activity. That will mean that of course awareness is a part of it. But making sure that you're looking at role specific training rather than generic security training to make it effective. So for example, in the section program that we were driving one of the main goals we had with awareness was to make it as hands on as possible and to enable teams to do it on their own. The second thing is to have the right resources shared with all the development teams. The development teams can also reach out and ask for some of these. Generally security teams would come up with these resources. All of these as handy as possible is the idea so that the dev teams can take it and then run with these. It should also be actionable and timely because time is of essence in a real development. So having frequent touch points with security is a good idea and vice versa with the development teams is also a good idea. Keep it evolving so all the so whether it is awareness and the idea of for example, latest patches coming in for any vulnerabilities issues with new technologies that you're going to adopt and all of that it needs to evolve over a period of time and keep getting updated because a lot is changing on the security side as well. And lastly, it's important to create a community of everyone in this space. So for example, for the SECTRAM program that we were driving, we created the community of SECTRAM where all SECTRAMs could come together, talk to each other about security challenges that they may have when they're actually doing, for example, enabling some automation or performing threat modeling and all of that and be able to discuss that with each other and that helps solve a lot of problems and helps it scale and be sustainable over a long period of time. Because there's only so much that a small security team can do at the end of the day in a large enterprise. So this is a very good and efficient way of actually scaling your security initiatives across the agile development teams. So to put it simply and a little more visually, when you start off with your, you know, the development life cycle, essentially have education as early as possible, you have the right kind of awareness for different roles in the team. It could also depend on the tech stack that you are going to pick up, right? So it could also be language specific. So when you're talking about code security training, it could be based on specific in the code that you are or the language that you're going to pick up. In the design phase focus on identifying threats early on in the life cycle. When you are creating your backlog for the stories, it's important to also add everything from a security standpoint there. And this should include, for example, the threats that you might have identified. Generally, what we do or what we did for the program was once we identified threats, we would convert it to the right kind of story or, for example, security tasks or bug or, you know, a different category because not every issue needs to be a story or a feature. And then add that to the project dashboard. This needs to be prioritized and then addressed by, for example, by allocating a deaf pair who could then fix or address the issue. During development, leverage as much as possible, all the security automation security to tooling that you may have that could be your size to your SCA DAS container scanning, you know, and even in for security review and all of that in a in a most automated fashion. But the idea is that towards the end of all of this, you are as a team come together and, you know, retrospect on or reflect on what are the issues. Analyze, see what are the recurring, for example, threads recurring findings from these scanning tools and all of that, which can be avoided in the next iteration. This could be so this feedback that comes in from this tooling or from the set modeling and other things that you perform can can be added as a part of security unit tests in some cases, not in all cases. In some cases, you could add it as an acceptance criteria in these kind of stories to that right kind of validations, take care of the issues in the from the get go. So, finally, with respect to the security program that you may have in your organization. How do you keep agile in mind when creating that so many times of your different kind of program in different organizations. So it in your context, it might be different. But essentially, it's important to look at different kind of teams. For example, if different teams are using different text tags or have different compliance requirements, that's possible for different products. Then pick up a variety of that see how your program suits or is effective for each of those to have the right kind of things and when you are designing a pilot, particularly in your program. When you're thinking of the awareness aspect, make sure that you are you're thinking of awareness which is more effective to create that critical thinking with respect to your program goals. And it is very practical for the development teams to pick up and run with it. When you are at the execution phase for your program. You look at of course implementing of controls, but how can you do that collaboratively with the developers or deaf teams. So there in security need to work collaboratively when we are specifically talking about security programs being run for deaf teams. And it's also very important to keep it lean so that you can be picked up by the team themselves. When you're doing the governance and you're looking at the metrics, keep the metrics simplified with respect to your program. Metrics should be such that can be measured by the development teams themselves and also by the security teams. But the idea is also to keep it transparent in a way across teams so that drive the sense of competition is healthy in a way that you can see and measure it on your own as a development team. And then of course improve it over a period of time. It's important to keep getting feedbacks because the agile development context itself keeps changing a lot from time to time. So for security teams, particularly, it's very important to keep getting feedbacks from time to time. Lastly, when you are thinking of scaling your security program across the development off. It's important to simplify it as much as possible to make it very handy to have the right processes in place, which can be right processes in the right tooling in place, which can be picked up and the teams can own it on their own, but also make it a part of the culture, make it a part of the practice so that it can scale evenly effectively across all the teams in your development off. When you're looking at the maturity of your own team, for example, your own agile development team, or as a security team if you're looking at the maturity, it's one part of it is to look at the specific metrics that you've been talking about. So it typically it would be number of vulnerabilities which are being detected through the tooling that you're adding, or you know, number of critical high risk issues that are being fixed and how frequently by these teams, a rate of implementation and all of that. But one of the good things to focus on with respect to the program or with respect to your security program will be that if this metric that you are trying to measure is driving a behavioral change or not. So I'll give an example. So when one of the main things that that was at the heart of our the section program was set identification. But we tried to, when we were setting the metric, we did not keep the metric as a number of threats found. Rather, the metric for us was the frequency of threat modeling. So how frequently are the teams actually getting into the activity of doing set modeling. And that is what is what we wanted to do. So the practice of looking at threats or analyzing threats was, you know, the one that will drive the behavior change eventually. There could also be some non measurable parameters, for example, how proactive are the teams with with doing security. So, for example, in our case it was while they are doing they're looking at threat modeling in the design phase. Some of them would proactively go out and ask the businesses or the client around what are the specific security requirements around a set of features or in general for the product. So overall, all of this together will give you a unified picture of the actual security posture of where you stand in terms of security maturity. So, to quickly discuss some of the program outcomes of this exam program that we were driving. This was for close to 200 sections at that time. There are certain things that we focused on in every phase in the kickoff or onboarding we focused on nominating the sections, which was to be, you know, the exams who are actually passionate about security so that it became more sustainable for us with awareness we focused on keeping it hands on and keeping the threat modeling is way more agile. So we reduce the timelines to you know, close to one hour, one hour, one and half hours for project level threat modeling, and for features specific threat modeling to 45 minutes. In execution we mostly focusing on having more concrete actionable tasks for the depth teams to look at or in this case for the sections to look at. In case of governance we made sure that we are collaborating more with developers we are meeting them more often. And what we are measuring points to a behavior change, like I mentioned. And when we were scaling the idea was to build a community where they can interact with each other, share those their own security challenges, help each other solve it and also own their journey as a security champion. So, this led to us through actively uncovering hundreds of threats. Very soon, addressing and addressing most of these high critical issues that were identified as a part of that identification. The secchamps became the security point of contact so they were no more just doing that identification because once, once they matured to a certain degree they started looking at a lot of other things like security automation. What needs to be put on the pipeline and a lot of other things. And eventually, the push model changed to the full model for us where the earlier we were reaching out to teams for enrolling in this exam program, but soon once this got established. We started all the new teams that that were forming were actually started reaching out to us to become or enroll into the program itself, which made the job much easier. So as a small security team, it's much easier if you know people are reaching up to you for all of this than you reaching out to all different team, depending on how many teams you're dealing with. So, yeah, that's the benefit that we saw of driving it in this manner. So lastly, with respect to agile in mind, how do we champion security focus on individuals and interactions over, you know, following set standards, traditionally we have been doing security in a very slow fashion. In an agile setup it's important to focus on the interactions that you have focus on a working security model than having elaborate processes or elaborate documentation for things. It's important to go via the route of collaboration almost always helps and it's almost always effective in an agile development setup. And lastly, it's important to respond to change because the agile development environment is quite dynamic, particularly from a security standpoint. So you should be able to adapt and work with the dev teams to come to the right working security solution for your agile development teams. So yeah, it's pretty much taken from the agile manifesto and I think all of that really works well with agile security as well. So that's all from me today. Thanks a lot. No questions on the Q&A right now. I mean, it was a wonderful session. I mean, like, I think I think security in and out has been covered right from the execution to mindset.