Amazing. Um Let's get started. Um Respecting everyone who you know, came on time. Great. Um Hi, everyone. Uh In this discussion, I will share how we at INFOSEC introduced a new security approach to empower.Product teams enable accountability among leads and ensure teams as well as leadership are jointly informed and responsible for security risks. So, you know, whatever role you are playing, be it a developer, business analyst, quality analyst PM or an AEC specialist on your team.

And at you're at a lead level or, you know, someone starting off and passionate about security, the journey I am about to share can be incorporated by you for your teams in your team to start off. Uh a quick intro, I'm Nazneen. Uh I've been with thoughtworks for the last nine years. Currently playing the role of a security um consultant responsible to shape and lead the ABS program for Thoughtworks internal operations. I've played diverse roles uh ranging from a developer to a program manager change lead and uh I'm extremely passionate about the security domain. It's, it's an often repeated mantra around here that security is everyone's responsibility. Unfortunately, it's easier said than done.

And given the reputational and financial impact we've seen across industries, I, I fail to understand why security always an afterthought. Um, you would have observed, uh, security is still unfortunately seen as a gate or, you know, a checkbox within some organizations just before final, finalizing a new vendor or get going live with a new application product. Um, you know, functional teams recall. Oh, we have to do a security review, uh, to get a final go ahead and you know, need the blessing of infosec team. And, and we started observing similar patterns too when teams de delivery teams uh get stuck on their security journey, they look to infosec for help. And it is usually after key decisions are made and too late in the feedback cycle to add to it. Um capacity is limited and we end up end up becoming a bottleneck. So the security teams are like we need security and then we are the bottleneck attempts have been made uh to work with teams dedicated, but, you know, dropping ad hoc requirements into already full backlog for product teams gets them even more stuck. So, so overall strategies, you know, um thought of to get a person co located with the team, a specialist to have some regular calls with the team did not work to make a change in perspective. Let me let me zoom into a few uh details.

Let's talk about ownership and accountability. So the accountability of building security within the delivery teams was falling on the infosec team outside the product team. Um because the meetings we had with the teams right fueled the established notion that requirements are coming from infosec.

So ownership and accountability is infosec problem, the specialist problem, they are giving us the requirements. Therefore, it's their problem. And that was not working out building capability around security engineering tooling practices was just limited to the assigned sme the subject matter expert.

And uh you know, that doesn't scale. Well, um the team expands grows and just one person, it will not scale. Well, the connect I talked about like one of the strategies to have regular half an hour connects did not work well. It was so transactional, they were not rich technical discussions around, around security architecture or practices. Um It was, it was very transactional status quo. Have you finished this uh security control? Have you completed this security control? And that is not what we wanted to, you know, have a conversation with teams about. Um And, and we realized without the bigger picture, teams found it difficult to integrate the controls even if they were passionate, they were like sudden ad hoc requirement. How do we integrate this?

So a few of these observations that uh you know, I've shared on the slide here, let us to understand that product owners leads, do value progress, but they need context, teams value autonomy. Uh But they need help, infosec value security. But we, ok. So uh we knew we had to make a change. Ad hoc way of engagement was not working skills and capabilities were still lacking within, you know, the internal it, uh internal it organization. And to top it all, no dedicated team existed who had the passion and excitement to take the teams ahead on this journey. And that was a clear indication that a center of excellence is to be established to move the needle. So, so the center of excellence um basically was established to challenge the previous setup to embed security. We decided to help the teams to plan the road ahead by harnessing the curiosity of the delivery teams. So to move from checkbox curiosity leverage the power of why keep hammering, why we need it instead of, you know, what you need to do. So harness the curiosity, get the, you know, help the team's plan for the road ahead, make it feasible and scalable to support the team. You don't wanna wear a bottleneck and and, and to scale the teams, um think about how do we make it feasible for them.

And one of the very important things make progress visible and measurable because data driven security is very, very important. If you want to talk about security risks, security is all about, you know, maintaining a state of acceptable risk and we cannot do that if we do not have data. So keeping these three key principles in mind, let me de delve deep into the journey uh as we work towards this um in the right corner, you could see um we use the DV Cops Manifesto as our guiding lights. We ask the question, what will make the process effective for teams? And we try to understand the team's first touch point drawing from previous change management experience. So we were careful not to execute, you know, external triggers trying to do something, trying to make a change like externally by pushing uh change. So first we planned the security champion program. Any role developer BAQ A could be part of this program and to enable and empower them to critically question you know, security uh repercussions, security impact. We planned a few more steps. Let me outline them.

We understood that teams pick up requirements next priorities, bugs defects from a project management tool. And this is how, you know, team members follow these rituals to deliver products and features. So we went ahead and visualized all the requirements by providing a snapshot of priorities to this, allowed the team to plan for the security journey. So instead of ad hoc requirements, we give them everything upfront, asking them. Can you incorporate this in your longer road map?

It's something that cannot be done today already, full fee backlog. Again, adding requirements is gonna be push back. So helping them plan for it in their road map, the controls were created to, you know, follow the same process which you, you, a few of you all uh uh quite a few of you all would resonate, you know, starting from the analysis and development and then sanity check to completed link.

So this supported the team's current working style. But when the security champions came into picture now, they could lead mentor and train the team. They had a framework, they had a backing playbook with what they could work with, with, you know, we're using what we using, what they could work with the team. This workflow uh that was introduced uh for the controls, resonated with the team's way of indirectly, um you know, uh working as, as for the team's way of of already uh churning out stories and it supported the journey of the security champion too. So, um this is at a high level, let me, let me dig deep into the, a few of the requirements. So let's talk about one of the controls, security, uh secret handling, these requirements can be considered as an epic, for example. Um first part, the control card had context about breaches that, you know, led to reputation and financial losses across industries. Very common name, very big name, very big companies. So those were listed down the common mistakes if development or delivery teams avoided that could increase the confidence of the stakeholders. So those were listed in the part of the high.

And once the context is given of why this is important, then we dealt or went into the details of the house. So we talked about password manager, setup, setup of tools like talisman setup of tools like whisper, which you know can be set up as your cli tool or your pre commit hook and, and it gave links on how to do. So. So uh a few other examples like, you know, segregate your secrets for environment and and a few more were listed, these all were listed as acceptance criteria. So we spoke, we gave context with the why and then there are also uh a CS that could be implemented. Let's talk about another control. Now let's take threat modeling for an example. So I won't go into the extreme details of the card but it follows the same flow of how and why. It highlights the practice of thinking of threats using the Stride methodology. So Stride stands for your spoofing, tampering, repudiation, information, disclosure, denial of service and elevation of privilege and the acceptance criteria included doing a threat modeling for the upcoming feature. So instead of thinking at the end, oh what are the threats, what are the risks we have not catered to as per the phases, right? In your product, take off phase, you're thinking of doing a threat modeling and thinking of the threats uh that should be mitigated.

Of course. Um You know, we never, we never gave this control to the teams and said, figure it out there was conscious upskilling. Um There were workshops with the security champions that went into, you know, doing threat modeling. But once you do it for the teams like as a security community, then they can continuously do it for number of their features, number of uh the releases uh I in the future. So um uh we, we try to make sure the, the teams keep doing threat modeling, but also for the first few paired with them, um make sure that, you know, they are comfortable doing it. The question probably in your mind is why put so much effort in adding the context, what made, what was the difference? Um And why we hammered the why II A as a developer, right? Um I am able to deliver a quality product when I understand the context when I understand my code, what value is it bringing to the business? So security controls were created to illustrate the context and value of each requirement, its outcome, the threat it mitigates and how it can be achieved.

So then the teams really understand how they are delivering a secure product and how it is helping in the bigger goals of the business. And that is what made a huge difference when we work towards uh sharing the context rather than telling how to do it. So instead of, you know, dropping ad hoc security requirements, this list was useful for the teams to navigate the security journey. Um The controls were divided to map the delivery phases, uh you know, like right from, right from kick off to building to, you know, sanity check to deployment. And we also make sure this resonates with the build security in cycle. So there's a connection with them. Overall, the big difference was, or the difference is that the team did the work. So they had a sense of fulfilled accomplishment which the team carried. And that was the biggest difference in motivation and morale. Um Where, where the retelling them and doing something versus they being able to self plan their journey, getting things done was a big boost. And that is when we saw the, you know, journey of culture shift um start to change. So that, that, that is the start of a journey of the culture shift. Um You know, uh let me share with you the actual snapshot of the board. Um The creation of this board is automated. We wrote a small script in Python.

Um We have a template and depending on it's a homegrown service or, you know, um uh uh just an API or, you know, uh integration between two other systems or it's a s a tool like something you just, you, it's configured for you and you need to pull data from it, push data to it, the controls differ and we automated this process by making sure depending on the team, the controls are also planned accordingly.

And we did not stop here. So we made sure this can improve the monitoring of the teams security posture. So we use Trello in this case and using Trello Web hooks, we pushed all events, say a card moved of a particular label or a particular category, moved to completed or progress state and such events. Uh We pushed to a collector and we made dashboards against the various categories to highlight the progress of teams under one account. So this view was missing, then we started off and then it helped the teams to self assess their progress. That how long are they taking to complete a category or where does the risk in an ecosystem lie? If all the teams or most of the teams are still, you know, pending to finish the controls and infrastructure site, we need to buck up, we need to, you know, make sure uh we're thinking of risks in this area. So it gave us an understanding of where we stand in terms of security, maturity. Um And the controls were categorized, um you know, as, as a few listed as a few listed here, but additionally, design controls are during for the designs.

But uh you know, uh category, secure delivery practices, uh incident management, uh defensive, security logging monitoring. Um And, and um this gave a very good view to the tech principles and leads. But in this progress at each category level or each control level was too low level for a steering committee or governance group. Hence, we derived insights made per team using a maturity model. So we got all the stakeholders together to discuss the security posture and um getting them together was a crucial point, right? But to help them make informed decisions, um help them take accountability for risks. We highlight started, you know, ma mapping the teams as per the security maturity, which team is still reactive, which ST team is, you know, proactive, they have controls that are repeatable or which team has all the controls set up and you know, it's repeatable and defined and, and you know, they have set up processes in place or security tooling in place um and so so on and so forth.

So um this visualization help the risk based decision um making, making the making sure that, you know, uh the decisions by the leadership can take decisions on, you know, which team is slow to respond. How can they be supported? How are we having any mission critical teams that are still at level zero and so on and so forth? So, um overall going back uh to the journey, um we wanted to make sure that data should lead to decision making and it should be scalable and consistent. So the visualization of the maturity model was a big step to augment the journey by data driven security as well as at the same time, I for the team members uh who are using these controls, they saw every visualization connected to the controls. So it reduced, it reduced their cognitive overload, uh which was a big, big boost in usability and effective adoption. Imagine if everything I'm doing, I see the results pinned to that particular way of uh you know, um categorization, I will be able to effectively understand where I have to process or where I have to progress. Um And this visual monitoring gave a clear and transparent picture.

So it was simple automations um but effective uh to think about how do we do it. Um With that a final step, let me quickly with the time, get here. Um nominate versus voluntary. Uh We instead of asking security champions to volunteer for this role, we, we asked techs to nominate them and that made a big difference being nominated. Uh put a lot more um you know, effect or a lot more morale boost for them to take back security to their team. So a few takeaways, a few key principles of our approach, but a few takeaways for y'all um keep it human centric, collaborative use workflows that reduce friction. Um very simple uh workflows, but they can be automated and it can then help to derive data. Um Our role remains to make us self redundant. So whatever you do, um your, you know, work towards either becoming a security champion or, or you know, uh seeing how security can be thought through in your current workflow. Um It's, it's, it's, it's overall um you know, reinforce the power of high.

So, um in, in that sense, if you're playing a tech lead or you're playing a security champion, you're playing any role in your team and you're passionate about security, please make sure that you can resonate with the team's current way of working. Ask them, um you know, uh share with them why they need to work on something and you can use this approach to, you know, uh let them think about the road map way in the beginning. So that's it. Thank you so much. Please uh leave your questions and comments uh in the chat or feel free to connect post that on linkedin. Thank you.