Hello, Warren, welcome from Switzerland, even if it's quite cold outside. So it might be interesting for you that my role in the SFS group is a combination of digitization and security. So I'm heading that department and I'm with SFS for 14 years already. So I did my career in the infrastructure department. I was heading that and probably it's interesting to have some figures and information about the SFS group. So we are an international manufacturer with a Swiss heritage with more than a hundred locations globally, close to 11,000 employees. And the revenue of about 1.8 billion Swiss Frans. So it might be a little bit curious that digitization and security is with the, in the same department, but actually it's a, a good thing to think about it because we are talking about incident response and I'm going to talk about HR methods and I would explain why this fits excellent together.
So one of the main reasons for that is that in both situations, let's think about the incident response cycle from the N framework, or if we have some agile framework like scrum or design thinking, what you see in that diagrams is always there cycles. So cycles are in the NIST framework. You move forward, come back and move forward. So this is exactly the same at scrum or in a design thinking cycle. So this is what tells me something has to be in common there. But my understanding of, of the business is that they are familiar with scrum or design thinking, but they are not familiar with an incident response cycle, which is more an it part or a security part. And this is why the idea came up to have it combined. So the initial question was, could I manage a cyber security incident with agile methods?
So, but let's have a look to it, agile methods first. So there is a matrix called Stacey matrix. Actually, it's a tool to think about what method fits perfectly to a problem situation. And let me introduce that first for you. So you see a matrix and you have at one scale, the certainty of a problem, and the other one is the agreement. So if we have a situation where we don't have any certainty and we don't have any agreement, what happened? So we are talking about chaotic situations. So it's very uncomfortable probably to be there. So this is like we have in, in situations at, at the beginning of an incident and the recommendation is to have a design thinking approach applied to code situations. So if we have more confidentiality or you have more experience with a situation or a problem situation, then you might apply scrum to that complex situation.
Complex is a little bit more than complicated. And if it goes down to the blue area, then the Kaban methodology would be a good recommendation for the problem situation. But actually why I'm telling you that is that an attack differs or evolve over the time. So out of more than one experience we have with a with averse situation, the question was what is the right method that fits into the problem situation we are in? So let's do some example first for the chaotic situation at the very beginning. So it's the, the call you get, and you do not have any clue what really happened. So you do not have any clear understanding what the situation is. You have to engage teams, you have to establish an organization, you have to mobilize. And it's quite obvious that this could be quite chaotic at the beginning. There is a high demand of information could be from external parties, could be from your executive board, could be employees.
There's so many questions and you do not have any clue what really happened at this very beginning. I'm quite sure you have very motivated employees, it staff, but you really have to think about to organize that because you don't want to destroy evidence for example, but this could be quite easily that in this chaotic situation, somebody restarts and deletes a lock file with that or any other situation. So you have to be organized. So this is why the recommendation, what is initial challenge is to go with design thinking because it's made for that. So I come to that point once again, later. So the second phase you might have, it is more a complex situation. You have limited resources, you have conflicts in priorities, you have dependencies, you have probably technical issues. You have to deal with. You have to onboard external specialists, you have to extend your work bench.
You have to engage forensics. And there is a really high demand of information. So could be from official govern organizations from public or media news stock exchange. So that is the situation we are in. So we are listed and there could be some questions from the cyber insurance company. So to deal with that is really a complex situation. And if you are in that situation, you really feel the pain of this complexity. The third one is the common methodology is very good to go back into a normal operation or go back into normal because then you have to deal with a complicated situation quite often. So as we were dealing with averse situation or more than one, so we had established a clean network. We had restore devices, service and services. We had to restore all the data and applications. So this is, this is a must work.
So you have to deal with a lot of tasks. You have to organize that you still have to communicate. And at the end you think about pushing back to the regular organization. So this is just to give you a little, a little bit sort of understanding what three different situations could be during a ransomware attack. So, but let's do it again. So as we were talking about cycles, let's do it again with a real world example. So this is how we did one time. So at the beginning, if you got get that initial call, you are in that chaotic situation. And the recommendation is to apply a design thinking approach in that initial situation, because the first point there or the first step is to understand. So there's some questions I listed. So what happened, what really happened, not only the obvious things, what happened again?
So you still have to ask questions because you really wanna understand what the attacker did or threat actor did. Was it just a one time shot? Was it a planned initiative? And I, I always want to understand what motivation of an attacker is. So this is like the emphasize approach in design thinking. So go into the mind of the threat actor and think what could be the next step, what could be done by them? What probably has, what is the next step they're going to do? And so this is just on the attack side, but the same thing is for the business level. So as an incident response situation is not only an it thing you really have, or the ability or the, the need to understand what happens at the business level, because then you are prepared to the business need for the next steps on that, on that side.
So, but another question I would bring into that is what about your response team? How they feel, what the mood is, do they gain progress? So a lot of questions you have to raise a lot of answers you have to do, and it's quite hard to stay in that problem space. So as individuals tend to move to the solution space and want to do something or implement something, probably it's very good to hold on a second. And I called it unlearn that because you have to be open. So the initial understanding could be really different at the end of week one while talking with forensics while talking with engineers, and then a very hard question is, do we need another cycle or do we have a real good understanding what happened?
So this is for week one. So it is a very chaotic situation. And now probably you see why those questions are relevant at the beginning. So moving forward with our incident in week two or three, so actually these are real numbers. So it was not days, it was weeks in, in that organization. So by the end of the first week, we could have like a revenue meeting. So this is a, a standard element from a scrum mental. So what happened? What is the current status of investigation? What is the restoring process? And then we might answer questions. What went good? What could have been done better? So the first retrospective could be held and the very important information or question from the business side is what can we expect for the next week? So at the end of first week, we moved from the design thinking approach to a scrum approach because we wanna get confident with a commitment in the, in the incident response team, what can be delivered by end of second week by end of the third week.
And this is a quite a common understanding with the business units because they also understand or applies scrum methods in their own innovation projects, for example. So this is more talking a business language and not an it part of it. So we could translate the incident response challenge into a business language. And the other thing is if your nose scrum, the idea is that the team is working on the goal on the commitment and they don't wanna be disturbed during the week. So with a good commitment, with a good trust level, let us work and we are going to move forward. And then we could deliver by end of the second week or the third week last but not least, I was talking about the Kaban principle. So it's more about task management and in, in a situation where you have to restore from scratch, you have to do all that hundreds or thousand reinstallation.
You have to do all the service implementations. You have to change all passwords, for example. So this is real a mass production you have to go into. So this is at the end, and for sure you wanna do a handover back to the operational organization and you don't wanna stay in the incident response process. So this is the idea of not producing bad quality at that point. So at the beginning, you can deal with it, but at the end, you wanna push back and you wanna get trust or gain trust again with communication. And you wanna move forward with a new infrastructure. So as we did, or you wanna move more forward with new measures, new security measures applied in infrastructure. So this is a very traumatic change probably for users because they have a new passport policy. They have a new system, they do not have their local data or something like that.
So it's all about communication and all about planning. And there's so many work to do that. K one could be a good idea for fourth week. So let's put that together into a summary, a summary, which is in three steps. It's quite obvious that at the very beginning design thinking could be a good idea to be applied in that chaotic situation, to bring in more structure, to really understand what happened. Then the next period would be about sprints and how to build the infrastructure from scratch could be with new ideas, with new protection measures, and this has to be done at scale. So at the end, you wanna apply to all the applications. You wanna apply that into production and this in a very short period of time. So actually the four weeks are a real example. So it could be that with your preparation work or with training, you are faster than that, but I'm quite sure you go through all the steps.
And if you do training, do exercise. And if you think with agile methods, probably you get into time to market that is shorter than just dealing with any other methodology. One thing at the end, it's it was really beneficial to talk at the, the business level, with their own methodologies. They are applying. So it's not a thing for development department or infrastructure departments. So agile methods are at least at the SFS group, common known in business units. And so it is more, it was more easy or was easier to talk at the business level with agile term terms and an understanding that fits into their own understanding. So that's actually what I prepared for you as a presentation.
