In January 2022, we, at Kaspersky, released our first mobile game – Disconnected. The game was designed for companies that want to strengthen their employees’ knowledge of cybersecurity basics. Even though game development is not something you would expect from a cybersecurity company, our motivation was quite clear – we wanted to create an appealing, interactive method of teaching cybersecurity.
Over our many years of experience in security awareness and experimentation with learning approaches (e.g. online adaptive platforms, interactive workshops and even VR simulations), we’ve noticed that even if the material is presented in a highly engaging way, people still lack the opportunity to apply the knowledge in practice. This means that although they are taking in the information, it won’t necessarily be applied.
To solve this problem, we decided to create a mobile cybersecurity game that allows players to immerse themselves in familiar and lifelike situations. The main objective of the playable character in Disconnected is to complete a work project choosing the correct cybersecurity-related actions while also maintaining good relationships with colleagues and loved ones. Long story short – you must behave securely, but not at the expense of others.
With a clearly defined goal in mind, we figured, what could possibly go wrong? Nearly everything it turns out. Making a game for the first time presented challenges – let’s talk about the most critical and difficult aspects.
We didn’t understand why we were struggling and even felt incompetent until we came across Blood, Sweat, and Pixels by Jason Schreier. The book gives insights into the inner workings of the gaming industry and showed us that every problem we faced is typical of the game development process, whether a blockbuster like Diablo or a small indie game. We hope our experience will be interesting and useful for companies outside of the gaming industry looking to develop their own game. Maybe it will even help make the game development process a little less overwhelming.
Game development is an art form. No matter how big your initial budget is or how many resources you have, when you start this kind of project you have the idea of creating the best game in the world. This type of thinking is a trap. When we started Disconnected, we planned on making a 40-minute exciting cyberpunk adventure, but we also wanted to make the game as tricked-out as possible. However, we came to a point in the development process where we realized that, with all the enhancements and additional elements, the gameplay duration had ballooned to ten hours and it wasn’t even finished yet. This, combined with issues with the developers, has led us to a year’s deadline overdue.
A game isn’t interesting if the player has no autonomy or control over the end result. We wanted players to see that their actions affect the plot and can lead to different outcomes. So, we thought up four different endings of the story: from the best possible, where the main character manages to save their company while maintaining good relations with others, to the worst, where the character faces catastrophic failures on all fronts.
Another aspect that made development more difficult was our decision to implement a set of built-in interactive elements to mimic the digital tools we use in our everyday lives. Such elements included browsers, mobile apps and messengers, which characters could use to help solve cases throughout the plot while simultaneously practicing related cybersecurity rules. For example, there is a password recognition module where the character has to come up with a password, enter it and remember it. If they forget this password, they have to go to technical support and lose valuable time for completing the project. Adding this pretty simple action to the game required a whole separate subsystem for its development.
Messenger, mail and task tracker…modern people need these tools, as do the game’s characters
Everything worked great when our developer created these elements separately, but when they were assembled, the interactive modules clashed. It was impossible to finish playing the game because of bugs. For example, the game would crash after pressing the built-in application buttons. The developer wasn’t able to fix old bugs, meanwhile, we kept finding new ones. At a certain point, the developer asked us to slow down and stopped responding to our emails for a while. Initially, we treated this with understanding, however, with yet another broken version of the game and yet another excuse, we started to feel that the project was getting out of control. As we came to realize this and started thinking of ways to save the game, the developer admitted that their team couldn’t fulfill their commitment and would abandon the project. This happened at the final stage, just a few months before the game’s release.
Source.
To understand this, we need to talk about the industry in general. According to our experience, almost all game developer companies, at least in Eastern Europe, unequally subdivide into two parts: the smaller is represented by highly skilled professionals and the larger consists of inexperienced amateurs. Those with the experience won’t work on an indie game because the tasks and budget don’t meet their expectations. The amateurs are not an option because you don’t want to risk your project in the hands of someone vastly inexperienced. The challenge is then to find a contractor that is competent enough to handle your game but is also interested in working beyond big mainstream gaming projects.
Our first contractor seemed like the perfect option – a small, new company founded by people well known as brilliant specialists in the gaming industry. Although they didn’t provide us with a large portfolio of their own completed projects, big names along with recommendations from their employers assured us that we could trust what seemed to be a promising team. So, we placed our confidence in them and left them to develop the project in alignment with our goals and objectives. In the beginning, the team performed well and we enjoyed working together. Some of us even joked that there must be a catch because communication with a contractor couldn’t be so smooth. Because Kaspersky doesn’t specialize in game development, we didn’t have our people check if the technical part was going right until we got an assembled version.
After the first developer gave up, we launched a new tender to find another contractor, which proved a challenge because of the industry subdivide mentioned above. We hardly managed to gather enough competing offers from potential suppliers. So, we ended up signing a new contract with Coderaptor, a company that we had already worked with on our VR project. These guys have a proven track record of expertise, but redoing someone else’s code is much more complicated than developing a game from scratch. Especially if the code is not systematized and is written on outdated software (another unpleasant surprise).
We chose Unity game engine to create a structure of the game
Articy helped us to implement interactive storytelling
Guys from Coderaptor not only had to complete the game’s development but also had to restructure the body of the entire game’s code. To ease and speed up this process, we had to abandon almost half of the modules and significantly shorten the gameplay (it was six times longer in the beginning). All of this forced us release the game almost a year later than the planned release date.
When you start a gaming project to create an engaging experience that teaches the basics of cybersecurity, but the final product can’t even engage your colleagues who work in the field, there’s a problem. When our team tried to play the first reassembled version of Disconnected, it was clear that something was wrong.
After the new developer helped us fix the main technical issues, we started to show the game to other people. They didn’t understand the story or the actions a playable character could take. The plot fell apart throughout the game, game details were useless and some crucial links were missing. This demotivated users from completing their missions.
For example, the main character works for SmartFrames, a start-up that is developing human implants to help people be more productive. This small company wants to make their innovative gadgets accessible to everyone. Globis is a large international corporation that wants to buy the startup and the player must stop them. We missed that a simple acquisition is not going to be perceived by most as an “evil” purpose that needs to be fought against.
Initially, when we worked with the first contractor, there was a narrative designer in their team who was responsible for the plot. However, the storyline flaws, including the lack of character motivation and logic behind their actions were only uncovered when the game was shortened. Since the new team from Coderaptor was only in charge of the technical part of the project, there was no specialist available to help us fix the plot problems and, at this stage, we couldn’t hire a professional screenwriter because that would lead to further delays and budget increases.
So, we became narrative designers ourselves. Our team recreated the plot, rethinking each scene and story arc. We studied the principles of storytelling using resources like Robert McKee’s “Story” to better understand what was wrong with the game’s plot and how to improve it. We looked at other dramatic theories, including Aristotle’s “Poetics,” and the storylines in other games (the principle of a plot structure was inspired by Detroit: Become Human) to learn from and compare the best examples with our product. We discovered that the creation of a game plot is a very interesting process. Even though the game is just pictures and text that pops up on the screen, you get to create a whole new world and determine the laws that govern it.
In only a month we rewrote every chapter of the game in alignment with proper dramatic structure. The plot outlined motivating reasons why a player would want to work towards completing the goals. Supported by logic, the story started to actually engage players. The subsequent feedback from colleagues showed that they had become immersed in our ‘Disconnected’ world. People became more emotionally attached to the game. They wanted to learn what happens in the other possible endings and asked for our recommendations on how to unlock other plot lines.
Translation of the thread:
When you work – fatigue increases
When you are suspicious of some activities – awareness increases
Empathy, I guess, increases when you treat other characters with compassion
And what about concentration? When does this increase or decrease?
I sincerely believe that there is a way to find a chocolate for Phil, but I failed
During the AMA session, Denis Barinov said there is a chance to get good endings on all fronts
What do these endings look like?
I suppose a successfully signed contract is a good ending for work
And what about the other areas?
As for relationships — Sasha seems to stay with my character. I guess this means that this is ok
But I’d like more details 😊
I think it would be more convenient if a player could skip the dialogue by pressing a single button, not by tapping any part of the screen. Because then you can miss dialogue and parts of the content by an accident click.
For example, sometimes I didn’t manage to close the lens and skipped the dialogue instead.
In addition, during the playthrough the game crashed like four times. I hope there are some automatic logs for searching issues because I didn’t find repeating ones. The game just crashes from time to time.
And on another device the task tracker didn’t load. But that was in the previous build. I didn’t have the same problem with the current one.
Reloading helped.
Reconstruction of the plot was also a good move because, while upgrading story, we were also able to implement more cybersecurity cases, making the game more useful for our clients. As a team specializing in security education, we are much more aware of real situations that pose cyber-risks than a third-party screenwriter, and we didn’t miss a chance to utilize this knowledge.
As for the main motivation, in the final version, Globis tries to buy the startup with the intention of putting an advertisement into implants. Their plan seems worrisome and worth fighting against. We also decided to start the game by foreshadowing the end with a short scene. This made the game interesting from the beginning, piquing players’ curiosity about what happened during the plot, which encouraged them to play to find out.
Another difficult task was creating characters that a player wanted to interact with and play for.
Although we ran out of budget and had no internal game testers, we decided to utilize the full Kaspersky potential and turned to our colleagues for help. To get feedback about the game in general we showed it to workmates across different departments, including HR, marketing, finances, etc. Meanwhile, professional testers from Safeboard helped to check our product for bugs. Initial feedback showed that people from different audiences felt that one of the main heroes was toxic, which made it clear that our characters were far from perfect.
When a game consists mostly of dialogue and you work on different parts at different times, it is important to look at the whole picture from an outside perspective. When we did this it turned out that the partner of the protagonist didn’t come across as a good person. He or she (you can choose) constantly gave tasks to the playable character, did nothing by themselves and was easily offended. This behavior didn’t make people want to associate with the character. To fix this, we studied the character from the beginning, edited overly reactionary phrases and redelegated some requests that this character gave to the main hero received to other characters.
A character coming across unpleasant is bad, but when they are also artificial and don’t evoke any emotions, it’s even worse. Especially when your game is meant to be a visual novel. We all know novels are driven by their characters, so it is important for them to be compelling. To make sure our heroes were engaging, we created a life story for each of them – even the minor ones that only make a couple of remarks throughout the game. While these stories are not directly included in the game and the player likely has no idea that they exist, they are instrumental to creating complex and relatable characters. While these stories are not directly included in the game and the player likely has no idea that they exist, they are instrumental to creating complex and relatable characters. When there are back stories behind each character, players somehow feel it and are more inclined to interact with our game’s heroes. We still don’t know exactly how this works, just that it does work.
The appearance of the characters also caused issues. A lot of time was spent on Sasha, a female character and the partner of the main hero. We spent days defining what she looked like, changing her appearance quite a few times. In the beginning of the character’s development, it was hard to explain to artists what the right facial details were and what clothes would be the right fit for her character. This only became clear after numerous iterations, as we gradually adjusted details of the closest sample options provided by the artists.
Let’s look how this happened in practice:
One of the initial variants…Have you ever heard about the uncanny valley effect?
Which option would you choose for the main female character in the game?
Here is our choice (Sasha in different moods)
The good news is that once you've decided on the style and appearance of one of the key characters, working on the others is a much faster process. Artists will keep on drawing heroes based on the approved character for reference, aligning all of the characters' images to fit the general design concept. That said, some significant elements may need more attention and it’s okay to spend time on these. In our case, the second most discussed item was the prosthetic arm of one of the heroes.
This story does have a happy ending. In the end, we managed to create a game with an engaging plot, interesting characters and found the right balance between entertainment and education.
If you want to know some of the game development lessons to be drawn from our experience, here they are:
This post is written by:
Denis Barinov, Head of Kaspersky Academy
Oleg Ignatov, Senior Product Manager, Kaspersky Security Awareness Trainings
Alexander Lunev, Product Manager, Kaspersky Security Awareness Trainings
Over our many years of experience in security awareness and experimentation with learning approaches (e.g. online adaptive platforms, interactive workshops and even VR simulations), we’ve noticed that even if the material is presented in a highly engaging way, people still lack the opportunity to apply the knowledge in practice. This means that although they are taking in the information, it won’t necessarily be applied.
To solve this problem, we decided to create a mobile cybersecurity game that allows players to immerse themselves in familiar and lifelike situations. The main objective of the playable character in Disconnected is to complete a work project choosing the correct cybersecurity-related actions while also maintaining good relationships with colleagues and loved ones. Long story short – you must behave securely, but not at the expense of others.
With a clearly defined goal in mind, we figured, what could possibly go wrong? Nearly everything it turns out. Making a game for the first time presented challenges – let’s talk about the most critical and difficult aspects.
We didn’t understand why we were struggling and even felt incompetent until we came across Blood, Sweat, and Pixels by Jason Schreier. The book gives insights into the inner workings of the gaming industry and showed us that every problem we faced is typical of the game development process, whether a blockbuster like Diablo or a small indie game. We hope our experience will be interesting and useful for companies outside of the gaming industry looking to develop their own game. Maybe it will even help make the game development process a little less overwhelming.
Game development is an art form. No matter how big your initial budget is or how many resources you have, when you start this kind of project you have the idea of creating the best game in the world. This type of thinking is a trap. When we started Disconnected, we planned on making a 40-minute exciting cyberpunk adventure, but we also wanted to make the game as tricked-out as possible. However, we came to a point in the development process where we realized that, with all the enhancements and additional elements, the gameplay duration had ballooned to ten hours and it wasn’t even finished yet. This, combined with issues with the developers, has led us to a year’s deadline overdue.
How did we get there?
A game isn’t interesting if the player has no autonomy or control over the end result. We wanted players to see that their actions affect the plot and can lead to different outcomes. So, we thought up four different endings of the story: from the best possible, where the main character manages to save their company while maintaining good relations with others, to the worst, where the character faces catastrophic failures on all fronts.
Another aspect that made development more difficult was our decision to implement a set of built-in interactive elements to mimic the digital tools we use in our everyday lives. Such elements included browsers, mobile apps and messengers, which characters could use to help solve cases throughout the plot while simultaneously practicing related cybersecurity rules. For example, there is a password recognition module where the character has to come up with a password, enter it and remember it. If they forget this password, they have to go to technical support and lose valuable time for completing the project. Adding this pretty simple action to the game required a whole separate subsystem for its development.
 |
 |
 |
Everything worked great when our developer created these elements separately, but when they were assembled, the interactive modules clashed. It was impossible to finish playing the game because of bugs. For example, the game would crash after pressing the built-in application buttons. The developer wasn’t able to fix old bugs, meanwhile, we kept finding new ones. At a certain point, the developer asked us to slow down and stopped responding to our emails for a while. Initially, we treated this with understanding, however, with yet another broken version of the game and yet another excuse, we started to feel that the project was getting out of control. As we came to realize this and started thinking of ways to save the game, the developer admitted that their team couldn’t fulfill their commitment and would abandon the project. This happened at the final stage, just a few months before the game’s release.
Source.
Why didn’t we notice the incompetence of our contractor earlier?
To understand this, we need to talk about the industry in general. According to our experience, almost all game developer companies, at least in Eastern Europe, unequally subdivide into two parts: the smaller is represented by highly skilled professionals and the larger consists of inexperienced amateurs. Those with the experience won’t work on an indie game because the tasks and budget don’t meet their expectations. The amateurs are not an option because you don’t want to risk your project in the hands of someone vastly inexperienced. The challenge is then to find a contractor that is competent enough to handle your game but is also interested in working beyond big mainstream gaming projects.
Our first contractor seemed like the perfect option – a small, new company founded by people well known as brilliant specialists in the gaming industry. Although they didn’t provide us with a large portfolio of their own completed projects, big names along with recommendations from their employers assured us that we could trust what seemed to be a promising team. So, we placed our confidence in them and left them to develop the project in alignment with our goals and objectives. In the beginning, the team performed well and we enjoyed working together. Some of us even joked that there must be a catch because communication with a contractor couldn’t be so smooth. Because Kaspersky doesn’t specialize in game development, we didn’t have our people check if the technical part was going right until we got an assembled version.
After the first developer gave up, we launched a new tender to find another contractor, which proved a challenge because of the industry subdivide mentioned above. We hardly managed to gather enough competing offers from potential suppliers. So, we ended up signing a new contract with Coderaptor, a company that we had already worked with on our VR project. These guys have a proven track record of expertise, but redoing someone else’s code is much more complicated than developing a game from scratch. Especially if the code is not systematized and is written on outdated software (another unpleasant surprise).
We chose Unity game engine to create a structure of the game
Articy helped us to implement interactive storytelling
Guys from Coderaptor not only had to complete the game’s development but also had to restructure the body of the entire game’s code. To ease and speed up this process, we had to abandon almost half of the modules and significantly shorten the gameplay (it was six times longer in the beginning). All of this forced us release the game almost a year later than the planned release date.
It is boring
When you start a gaming project to create an engaging experience that teaches the basics of cybersecurity, but the final product can’t even engage your colleagues who work in the field, there’s a problem. When our team tried to play the first reassembled version of Disconnected, it was clear that something was wrong.
After the new developer helped us fix the main technical issues, we started to show the game to other people. They didn’t understand the story or the actions a playable character could take. The plot fell apart throughout the game, game details were useless and some crucial links were missing. This demotivated users from completing their missions.
For example, the main character works for SmartFrames, a start-up that is developing human implants to help people be more productive. This small company wants to make their innovative gadgets accessible to everyone. Globis is a large international corporation that wants to buy the startup and the player must stop them. We missed that a simple acquisition is not going to be perceived by most as an “evil” purpose that needs to be fought against.
Initially, when we worked with the first contractor, there was a narrative designer in their team who was responsible for the plot. However, the storyline flaws, including the lack of character motivation and logic behind their actions were only uncovered when the game was shortened. Since the new team from Coderaptor was only in charge of the technical part of the project, there was no specialist available to help us fix the plot problems and, at this stage, we couldn’t hire a professional screenwriter because that would lead to further delays and budget increases.
So, we became narrative designers ourselves. Our team recreated the plot, rethinking each scene and story arc. We studied the principles of storytelling using resources like Robert McKee’s “Story” to better understand what was wrong with the game’s plot and how to improve it. We looked at other dramatic theories, including Aristotle’s “Poetics,” and the storylines in other games (the principle of a plot structure was inspired by Detroit: Become Human) to learn from and compare the best examples with our product. We discovered that the creation of a game plot is a very interesting process. Even though the game is just pictures and text that pops up on the screen, you get to create a whole new world and determine the laws that govern it.
In only a month we rewrote every chapter of the game in alignment with proper dramatic structure. The plot outlined motivating reasons why a player would want to work towards completing the goals. Supported by logic, the story started to actually engage players. The subsequent feedback from colleagues showed that they had become immersed in our ‘Disconnected’ world. People became more emotionally attached to the game. They wanted to learn what happens in the other possible endings and asked for our recommendations on how to unlock other plot lines.
Translation of the thread:
When you work – fatigue increases
When you are suspicious of some activities – awareness increases
Empathy, I guess, increases when you treat other characters with compassion
And what about concentration? When does this increase or decrease?
I sincerely believe that there is a way to find a chocolate for Phil, but I failed
During the AMA session, Denis Barinov said there is a chance to get good endings on all fronts
What do these endings look like?
I suppose a successfully signed contract is a good ending for work
And what about the other areas?
As for relationships — Sasha seems to stay with my character. I guess this means that this is ok
But I’d like more details 😊
I think it would be more convenient if a player could skip the dialogue by pressing a single button, not by tapping any part of the screen. Because then you can miss dialogue and parts of the content by an accident click.
For example, sometimes I didn’t manage to close the lens and skipped the dialogue instead.
In addition, during the playthrough the game crashed like four times. I hope there are some automatic logs for searching issues because I didn’t find repeating ones. The game just crashes from time to time.
And on another device the task tracker didn’t load. But that was in the previous build. I didn’t have the same problem with the current one.
Reloading helped.
Reconstruction of the plot was also a good move because, while upgrading story, we were also able to implement more cybersecurity cases, making the game more useful for our clients. As a team specializing in security education, we are much more aware of real situations that pose cyber-risks than a third-party screenwriter, and we didn’t miss a chance to utilize this knowledge.
As for the main motivation, in the final version, Globis tries to buy the startup with the intention of putting an advertisement into implants. Their plan seems worrisome and worth fighting against. We also decided to start the game by foreshadowing the end with a short scene. This made the game interesting from the beginning, piquing players’ curiosity about what happened during the plot, which encouraged them to play to find out.
Nobody wants to play with your characters
Another difficult task was creating characters that a player wanted to interact with and play for.
Although we ran out of budget and had no internal game testers, we decided to utilize the full Kaspersky potential and turned to our colleagues for help. To get feedback about the game in general we showed it to workmates across different departments, including HR, marketing, finances, etc. Meanwhile, professional testers from Safeboard helped to check our product for bugs. Initial feedback showed that people from different audiences felt that one of the main heroes was toxic, which made it clear that our characters were far from perfect.
When a game consists mostly of dialogue and you work on different parts at different times, it is important to look at the whole picture from an outside perspective. When we did this it turned out that the partner of the protagonist didn’t come across as a good person. He or she (you can choose) constantly gave tasks to the playable character, did nothing by themselves and was easily offended. This behavior didn’t make people want to associate with the character. To fix this, we studied the character from the beginning, edited overly reactionary phrases and redelegated some requests that this character gave to the main hero received to other characters.
A character coming across unpleasant is bad, but when they are also artificial and don’t evoke any emotions, it’s even worse. Especially when your game is meant to be a visual novel. We all know novels are driven by their characters, so it is important for them to be compelling. To make sure our heroes were engaging, we created a life story for each of them – even the minor ones that only make a couple of remarks throughout the game. While these stories are not directly included in the game and the player likely has no idea that they exist, they are instrumental to creating complex and relatable characters. While these stories are not directly included in the game and the player likely has no idea that they exist, they are instrumental to creating complex and relatable characters. When there are back stories behind each character, players somehow feel it and are more inclined to interact with our game’s heroes. We still don’t know exactly how this works, just that it does work.
The appearance of the characters also caused issues. A lot of time was spent on Sasha, a female character and the partner of the main hero. We spent days defining what she looked like, changing her appearance quite a few times. In the beginning of the character’s development, it was hard to explain to artists what the right facial details were and what clothes would be the right fit for her character. This only became clear after numerous iterations, as we gradually adjusted details of the closest sample options provided by the artists.
Let’s look how this happened in practice:
One of the initial variants…Have you ever heard about the uncanny valley effect?
 |
 |
Here is our choice (Sasha in different moods)
 |
 |
 |
 |
 |
We made it
This story does have a happy ending. In the end, we managed to create a game with an engaging plot, interesting characters and found the right balance between entertainment and education.
If you want to know some of the game development lessons to be drawn from our experience, here they are:
- If you are not a game development company, don’t make games — unless you are 100% sure that you can’t complete your goals without one. This kind of project requires too many resources and too much effort and nerve that you will only be able to succeed if you really need it;
- Don’t give up (if the first recommendation didn’t scare you). Development of a game differs from any other project. Even if you are an experienced manager, when starting to work on a game you should build a project roadmap and take into consideration unexpected delays and time-consuming challenges. You will never be fully satisfied with the final version of your game, but that’s okay;
- Keep it simple. Sometimes the simplest game elements work better than a bunch of complex additions. This applies both to the technical and narrative parts of the game. The issue is that, even when you are making a small mobile game, you can’t help but to carry the notion of creating something like Mass Effect. However, if the game is targeted at non-gamers, simple mechanics are enough. Otherwise, you risk the game logic not being clear for the average user. The best way is to create something simple first and then progressively make it more complex;
- Be careful with contractors. The game development industry is full of risks and to minimize them you have to be confident in your developer. A contractor should be able to provide several examples of completed projects and the contact details for their previous customers. Any contract with a contractor should divide their services into small milestones and include the opportunity to terminate the contract at each milestone if something goes wrong;
- Question everything. Even if you are working with a trusted developer, you still must be sure that each aspect of the game’s creation goes as planned. If you don’t want to face unsolvable problems in the final stages of the project, you need to understand what is happening during the whole development process;
- Use an outside perspective and don’t forget your target audience. As soon as you get the first test version, show it to colleagues and friends and ask them to share their feedback. This is essential to developing a game that appeals to people other than its creators;
- Study best practices. Determine what games best reflect your goals and aspirations for your game, then try to find as much information as possible about their processes – uncover the logic by which these games function. Additionally, there are some must-read books that contain crucial information about the main aspects of game development. Among them, as mentioned earlier, are ‘Blood, Sweat, and Pixels’ by Jason Schreier and ‘Story’ by Robert McKee;
- Work with like-minded people. A good team is a key component of success and our example proves this. Every time a problem came up, we consolidated our efforts. Even with the fact that we aren’t game development specialists, teamwork and support made up for our lack of expertise here.
This post is written by:
Denis Barinov, Head of Kaspersky Academy
Oleg Ignatov, Senior Product Manager, Kaspersky Security Awareness Trainings
Alexander Lunev, Product Manager, Kaspersky Security Awareness Trainings
