Sutapa Sarkar - Rise of Risk Ops teams - A solution for reducing cognitive load on DevOps teams.

This talk covers the concept of RiskOps, a framework aimed at reducing cognitive load within DevOps teams. The speaker, Sutapa Sarkar, who leads a RiskOps team at ING Netherlands, discusses how these teams collaborate closely with DevOps to manage vulnerabilities and security risks effectively. By implementing practices from the Team Topologies framework, the RiskOps team helps alleviate the burden of risk management from DevOps personnel, allowing them to focus on software delivery. The session highlights the benefits of this approach, including improved vulnerability management, reduced evidencing overload, and enhanced risk and security awareness among team members. Additionally, the speaker shares her insights on future trends in risk management, particularly the role of AI and automated solutions.

Hi, everyone. We are a bit late, but uh welcome to my session. Are you guys able to hear? Yeah? Perfect. Thank you. Uh yeah. So, uh um today I have a very interesting topic. It's called Rise of the RiskOps. Well, a bit Yeah, Rise of RiskOps, a solution for reducing cognitive load in uh DevOps teams. Now, uh before we start, I would just Let's Let's just introduce

myself. Um my name is Sutapa Sarkar. I am uh I'm from India, as you see. I was born in India, live in Netherlands. I've done my master's in chemistry, and um I have I am currently working I've worked in different roles in uh IT industry for 18 years, and currently I'm I am an IT chapter lead within an ING Netherlands, and I'm leading the RiskOps team in

my department, and hence the talk about RiskOps and how it worked out in our department. And one of my personal mottoes, or, you know, the guiding star in my life, is never give up. And I think as uh you know, IT risk engineers or security engineers, you often have that. So, this is my guiding motto. If you guys want to connect with me after the talk, please

uh that's my LinkedIn. Feel free to connect with me after I'll be around, so just grab me if you have questions. So, now that we have intro- I have introduced myself, let's uh look a bit into the agenda. Well, I'll go free flow, but still, to give you a idea of what you're supposed to expect in this uh session. So, first I'll uh try to explain what

is RiskOps and what I mean by RiskOps, and then uh I'll go a bit into what is cognitive load, what is team topologies. Maybe many of you have heard about it, but I'll try to explain a bit. Then we'll see the situation how it was before and after we introduced the risk-of-steam in our in our department. What are what were some of our highlights, some of our

achievements. In case you want to introduce you're very excited after my talk and you want to introduce such a team in your department, you're facing similar issues, then I have some tips and tricks for you. And last but not the least, a bit look looking ahead and looking into the future of risk-of specially giving that we are in the age of AI, right? Okay, so further ado,

let's go into the topic. Now, I would like to start with an analogy. If you look at the picture on the left-hand side, you see people exercising, right? >> [gasps] >> Now as as as humans, we were we always we always do different you know physical exercises in order to keep us fit and strong and in order to keep up with our resilience and to make sure

that we are not vulnerable to different kinds of diseases. If we if you look at the picture on the right-hand side of my screen, it is it is a you know a child undergoing a medical examination. So we know that um we have different kinds of medical you know check-ups in place that we have to undergo periodically or at a certain you know interval of time. And

these health checks are actually there in place to make sure that you are able to detect the imbalances in your system. They are able to make they are able to detect any threats to your health, they are able to protect you against the different kinds of vulnerabilities that may cause risk well, that may risk your health. Now, if I extend this analogy to our topic today, the

DevOps teams, you guys, you are the ones who are developing software, you're developing resilient software, you always jump in whenever there's a problem with your software, you try to uh uh you know, solve issues, also react when there's any vulnerability to the And it is it you are like, you know, like probably we also have personal trainers. So, it's like the DevOps teams are working hard and

they are to deliver secure software, secure as well as resilient software. Now, if I look and now if we draw the analogy of the of the child undergoing medical examination, now, the risk audits or the security um scannings that we have, they are more like the health checks. And uh if we extend this to a risk ops team, what is the difference is that risk ops team,

they are the teams who are working uh very closely with the DevOps teams. They consist of a group of security engineers, risk engineers, security champions, and they are working closely with the DevOps teams to detect, monitor, and to uh help them resolve all the vulnerabilities and the threats. Now, tradi- we also know in our in our uh you know, in our department, we also Not in our

department, but in our company, we also have the traditional risk structure, wherein the risk teams are very far apart from the uh from the main team. They work in silos. They create policies. They create, um, uh, they create different kinds of, uh, guidelines that the DevOps teams must follow. But, they are working in silos. But, a RiskOps team works very close to the different teams. To the

DevOps teams. The second advantage or the second, uh, you know, uh, usefulness of having, uh, RiskOps team is that they help to translate all those guidelines that are coming from the central risk team into items, into, uh, things, uh, into actionable items that are more palatable and can be understood by the DevOps teams. And third, but not the least, they also take ownership of actively monitoring the

different risk and the security vulnerabilities and they are also in control and, uh, they take ownership of all the monitoring and the tooling related to risk or security. Now that we have got a taste of what is a RiskOps teams, let's, uh, you know, see where a RiskOps team sits. You know, where it Where can we place it? So, you have Dev and Ops and a RiskOps

team, it in between the res- Dev and the Ops team. So, it sits at the intersection of the Dev and the Ops teams. And as I mentioned, they actually work with the DevOps teams in order to help them, uh, fix vulnerabilities as well as help them monitor threats as well as risk-related items, uh, for the DevOps teams. cognitive load, right? Now, the picture, I think, um, yeah,

uh, it's a it's a bit, uh, you know, something that I just wanted to put in because I found it really funny, but it I think very applicable to the topic. So, as you see, people are the kids are actually pushed into this small space, right? So, if we if we try to explain what is a cognitive load, we have to go to a bit into the

cognitive psychology. So, what in cognitive psychology, cognitive load actually refers to the um amount of working amount of effort that you're putting in your working memory when you're trying to learn something. And most of us think that we can do a the working memory is always it it is not infinite space. It has a limited space. And most of us we think we can always multitask and

handle a lot of stuff together, learn a lot of new things, but cognitive psychology says no, you cannot. You can only handle very small amounts of data in that let's call it data, small amounts of effort in the cognitive memory. Or in the working memory, my apologies. In the working memory. because of that, if a person tries to learn a lot of things simultaneously or wants to

try work on multiple things, learning a multiple new things together, then they actually tend to impede the efficiency at which they are learning the particular the particular items. Now, this analog this can also be extended to a DevOps teams. Now, as DevOps teams, we know that we are forced to handle risk, we have to handle development, we have to handle testing, what not. And when a DevOps

team has to work multiply on many things and constantly switch the context, then it leads to a very high cognitive load in the teams. risk also risk and security also can increase the cognitive load in the what is the solution? We also experienced the same in our department. So, what's the solution? Now, the solution to this is we found our solution in a framework that called team

topologies. It was created and it was popularized by Matthew Matthew Skelton and Manuel Pais. So, according to them, now the according to this it's a framework. So, team topologies is basically a framework that organizes the different products teams as well as the technical teams. They're called stream-aligned teams, which you'll these streams it organizes these different teams in such a way that they are able to deliver faster

with while their cognitive load is minimized. So, we try to maximize the flow at which the stream-aligned teams deliver their their products. Now, looking at the time because I'm a bit late today with this session, so I'm just going to skim through the different types of teams that we have, but if you have questions, please reach out to me later. So, in the in team topologies, we

generally have four different types of teams, a stream-aligned team, then we have the enabling team, complicated subsystem team, and platform Now, the risk of team in my in my department that we created is actually an enabling team. And what is an enabling team? As the word as you read, an enabling team actually is consist consists of a group of experts. They are basically experts in a particular

domain. They can be experts in a domain, in a particular field of technology. And they are they come with a certain expertise, and they can work together in such a team, and they help solve a problem. They help to bridge a capability gap, as we call it, in the DevOps teams. And they are also able to make a lot of choices around the tooling in order to

improve it. And hence they help they remove the cognitive load from the DevOps teams. And that's why we had we chose this model of having an enable risk of steam as an enabling team, which took care of all the risk and security related evidencing, as well as the vulnerability management in my Now Now that I have given you a rough idea of what we did to solve

this cognitive road on our DevOps teams, let's look at some of the situation Look at the situation that was there, some of the, you know, pain points we had before such a team was introduced in our department. So, the first thing that we the major trigger for creating such a risk of steam in our department was evidencing overload. And by evidencing overload, I mean risk evidence. Now,

you as you know, I'm representing ING. So, as a bank, we have to follow a lot of internal and external audits. We have to make sure our vulnerabilities are in control, and we also have to evidence them at a very periodic basis, maybe quarterly. At a So, at a point of time, this was this evidencing Earlier, we did not have risk of steam. So, what happened is

that the DevOps teams had to directly try to evidence all the you know cater to all these evidencing requirements as well as solve vulnerabilities, solve pen test findings, etc. And it was such an overload in our department that they we ended up having a dedicated engineer who was actually a DevOps engineer. He would like to do DevOps work, but he was forced into do all these risk

evidencing and he was like he or she was appointed. So he lost interest because this was not his domain, but yet he was forced to do. And sometimes when there were regulatory peaks, when we had to cater to a lot of evidencing, we actually found we we actually observed that the teams dropped everything and they just totally focused on doing risk and security related items, which caused

a lot of unhappiness, let's say, in the DevOps teams. Now the second thing was lack of risk automation. So since we did not have any dedicated risk engineers or security engineers in our department, you know, fixing fixing vulnerabilities was also done manually as a one-time job. It was I call it more like a band-aid solution. Whenever things arise, it was it sometime most of the times it

was an afterthought not all the engineers, even though we had security champions, but not all the engineers you know that in that in that mindset, they always want to deliver. That's the prime you know idea of of a DevOps team. Now, so we had a lack of risk automation every many things were manual, which actually eat up a lot of time without the DevOps team realizing it.

Then we had a alert fatigue. So we all we had a lot of security alerts, different kind of alerting mechanism related to risk and security, but they were just implemented without, you know, optimization. So, there were a lot of false positives. And that often led to a lot of unhappiness because the DevOps teams were always busy in trying to fix these alerts and deal with them. The

next one is low vulnerability management. >> [laughter] >> As I mentioned before, we did not have a dedicated risk or risk or security engineer and hence vulnerability management was also manual. We had different kinds of automation available, but because of the lack of prioritization, the teams did not implement it. Low The next point is low risk and security awareness. Of course, I think this is something that

you might already realize because we do risk and security engineers in the team. And of course, we have different trainings. We do have everything, but the teams are so busy in DevOps teams are so busy in delivering their um their delivery that they they do not have ample time for learning these topics and hence it always seemed like an overhead. And lastly, well, as a result of

all these risk management was most of the time reactive rather than proactive. And a combined effect of all these items that I mentioned here, the combined effect was that risk management was considered as an overload on top of their daily work. So, this was before. After the risk of steam, we found that there was a 70% So, all the evidencing after the introduction of the risk of

steam was done by the risk and security engineers who were actually in very close contact with the auditors, they were actually able to get the right context. They were able to answer all the different questions that were asked by the auditors and hence we actually saw 70% reduction in the evidence load overload because the risk and their risk ops team took care of it. Also, that led

to 100% satisfaction in internal and external audits because we were constantly in contact with the central teams. There was an improvement, 30% improvement in vulnerability management because we were able to nudge all the DevOps teams and work with them to automate all this, all the vulnerability management, and we were able to increase the frequency which led to lesser vulnerability lesser vulnerabilities. Improved risk and security awareness. Well,

that that comes because we organized a lot of sessions, knowledge sharing sessions. We have periodic sessions where we bring all the updates that are happening in the risk world, happening in the security world, different tools that are being ING wide, and we try to help the engineers, enable them so that they are able to understand, you know, they are able to get a feel of risk and

security tooling that exists around them. Next, because of the improved risk and security awareness, we also saw a proactive risk management. So, the engineers started thinking more about how they could build risk and security into the SDLC earlier. And we also have a constant contact. We are involved in every stage of SDLC now. And last but not the least, hey, we have removed the cognitive load and

our team has been operating since 1 and 1/2 years now. And in all the different surveys, we find really happier DevOps teams. So. Now, I will quickly go go the achievements. One of them was Eudora compliance for the ones from the who are aware of the digital operational EU digital operation resilience act. Well, being a financial being a bank and a financial organization, we had to close

all the compliance gaps by 17 Jan 2025. No exceptions. And in that case, we were earlier we were able to close close all the compliancy gaps because the risk of teams was in lead of fix of analyzing them, finding the gaps, fixing them together with the DevOps teams, and also evidencing because evidencing is also a part of DORA for the auditors. So, and all this with minimum

involvement from the stream-aligned or the DevOps teams. Now, the next one as I already mentioned, improved satisfaction in internal and external audits. This again because the risk of team took care of all was in the lead of doing all the risk evidencing, the security fixing, and they were really able to make sure that the updates in the security in the risk templates, etc. were actually included. They

all One of the major advantage of having our own risk of teams was that we were aware of the different applications that we were working on. We knew the intricacies, and that actually helped us to be able to, you know, answer to all the functional many of the functional related questions that came over from the security from the auditors. So, therefore, we actually closed age-long audit findings

after the risk of of teams started working in our department. Lastly, something that I've already mentioned before, we were able to help us we were able to nudge all the teams to come up with vulnerability management and we actually saw a huge improvement in the way the teams were managing vulnerability. Happier teams because they have patching, they have more automated than before. Now, as I promised, some

tips and tricks for you. So now, maybe I don't know, but after this, you know, after seeing the benefits of having a risk of steam, maybe you in your department are also facing such an issue and are thinking, "Okay, I would also like to introduce such a team in my department." Then I have some tips and tricks for you. Now, though how do you go about it?

The first thing is you need to identify the capability gap. And by capability gap, I mean whether you actually need a risk, whether you actually have a risk or security knowledge gap in your teams that is impeding the speed at which the different teams are uh are uh delivering their So, in case you have uh So, in order to do that, you can rely on OHI on

uh different kinds of retros on the departmental level and about the different surveys that happen on the departmental level. you have identified your capability gap. You think there's a gap in risk and security knowledge. The next thing is to set up a risk of steam. As I mentioned, a risk of steam could consist of risk engineers, security engineers, and they could also consist of security champions. Very

important, the risk engineer should have a bit of knowledge of edit auditing. Cuz that helps in the different audits. And last but not the least, helps to know your application well. When you are trying to evidence or you're trying to solve vulnerabilities about your application, so people who are very have good functional knowledge and they are also security champions or are interested in risk and security would

be valuable for your team. The next is to support, guide, and coach. So, once your RiskOps team has been created, the next step is to find ways of facilitating the DevOps teams and help them, enable them support your risk and security-related activities. The next thing is empower autonomy because one of the main ideas of having a RiskOps team is to empower the teams to be able to

suck in that risk and security knowledge. So, you will have to work very constantly with the RiskOps with the DevOps teams. And last but not the least, you would also need to measure the knowledge or the changes that have happened, improvement in knowledge of the RiskOps of the DevOps teams. And once you have that, could all again be the different kinds of retros and the surveys, organizational

health index, etc. that you can use for this. And last but not the least, once you have detailed idea of where again the risk the DevOps teams are missing the knowledge, you would actually need to go back and again re-align your strategy for having the RiskOps teams hey, the main goal of having a RiskOps teams is to enable to be able to facilitate the DevOps teams. Last

but not the least, and there's a final slide. So, now that we have set up a RiskOps teams and you know, the global landscape is changing a lot, right? So, we have the complex the way we build architect the way we architect our software, the way the global regulations are changing, ever changing landscape, ever changing complexity in our global, you know, global complex in the complexity of

the global environment. And last but not the least, also AI, right? So, we have heard a lot of news about AI being automating your vulnerability management. So, how would a RiskOps team look like? So, one of the main things that I would like is that it would we would see a more re uh proactive risk and security management than proactive as ever before. We might even have

AI agents in future, not now, but maybe in future we have AI agents who are able to monitor, they are able to uh detect vulnerabilities and even solve them. But then, RiskOps teams would be the human in loop there who is probably validating whether these agents are putting in the right thing in as solutions. Now, the last thing is uh in addition to that, we would also

see that uh arise. We already have a lot of policy as a code and compliance as a code. But, the future would see uh more increase in policy as a code as well as compliance as a code. And in addition to that, we would also probably see more and more uh automated uh generation of of the evidencing. And with that, I leave you guys. Um that was

all from my side about RiskOps. Thank you for being patient and listening to me. Thanks a lot. And if you have questions, please uh reach out