Eva Belyaeva, Security Vision
How we got here
Last article touched upon the topic of such a format of interaction for tasks as business games. In fact, both we as a company and some of our employees have our own history and experience in participating and conducting such games both for customers and internally.
This methodology can primarily be to teach people a skill, to prepare for an emergency situation, or simply to get employees within a team to get along with each other.
Let's break down how we define these games for ourselves, and then I'll tell you how we've built this process for ourselves and beyond - even in higher education for our students.
Retrospective
How do I know about this? Some time ago, a few years ago, my colleague took the training and exam for CISM certification - and there, among other useful knowledge, she came across the phrase tabletop exercises. Formally, it means a round table meeting of specialists who could potentially face, for example, an incident; during this meeting people talk about and sometimes imitate their behaviour within the given roles. In other words, it is training and replaying emergency scenarios.
We applied this format to ourselves often, especially when it came to SOC work. Such meetings were attended by people of different levels - from ordinary analysts to top management. The usual questions on the agenda - what to do if we are hacked? What do we do if the data is encrypted? What to do if there is no connection? What to do if the database has leaked to competitors? In addition to such problems, training sessions were also conducted with more private incidents, just complicated at that level of customer maturity - how to react and interact within departments if you have DDoS, and you provide health and safety of people with your services? Even if all of the above didn't happen in real life (and thankfully), people were more confident in what they were doing.
Let's look even further back in time - once upon a time, as part of our undergraduate training, my colleagues and I had an idea about how to diversify our workflow. At that time we didn't know about any methods or anything else, but acted intuitively - and one of our first thoughts was:
- let the students try on the roles of hackers and defenders. On the one hand - for fun, on the other hand - it is much easier to memorise new terms and approaches in a game;
- Conduct practice interviews for students so that they understand what will be waiting for them when they go looking for a job. But then they will already be prepared for the questions and how exciting it can be, especially the first time.
The experiment was successful, judging by the results of the exams of those years and the further employment of the guys we trained. But maybe they were the ones we found so capable :) Anyway, I tried to replicate this successful experience wherever I could.
Business for business
If you search for information about what these ‘business games’ are, the first thing you'll come across is all sorts of team-building and so on. Such variants of games did not suit our purposes - we learnt to trust each other sufficiently to solve problems within the team, and the problems were work-related, not personal.
Less common are training formats of games for employees, where they can try themselves in a new role. These games are simulations of the work process and solving work problems. This can have different goals:
- To understand how the person you are communicating with works. It's simple - you get the context and motivation of the other person. That surrounds, say, your system administrator, and you can better understand why he/she answers you the way he/she does.
- Understand the work of a manager/subordinate. This is a bit more difficult, as it is hard to immerse a person entirely in the context of work tasks in a short period of time. In such a case, it is common to call in a communications consultant who teaches listening and hearing, negotiating rather than arguing. But in case a person wants to be promoted to a lead, and he doubts - such a test drive will help him to make up his mind.
- Training students, interns and juniors. At the beginning of the career path, it is very difficult to get an idea of the ‘inside’ of a particular profession. How quickly can you realise whether sales, implementation or support is the right fit? The key here will be to strike a balance between ‘here are your frequent tasks’ and ‘here are your frequent problems’, as it is very easy to both romanticise and demonise a role.
- Preparing for rare but very important situations. The context is not so important here - it could be a visit from an inspection body, or it could be the sudden serious incident I mentioned earlier. You need to make sure that every employee understands what they are going to do, who they are working with and what resources they will need to utilise.
- Training for experienced employees. When introducing new processes, personnel changes and other pleasant and not so pleasant things, the challenge is how to switch everyone over painlessly. Timely training can help here, too.
- product development. I will tell you more about these goals, for now I will just note that to develop any product you need to understand your target audience and how you will be perceived by the user or business.
Our humble contribution
Product Development
All the knowledge that we have learnt either from experience or from very smart and expensive re-qualification courses, we have gathered within the team and transferred it to our processes.
In particular, this applies to product development. We have two directions for such work: on the one hand, when the work is just starting, we want to understand our customers, extract from the interview what they are concerned about and what can be automated and universalised. And on the other hand, when the framework is already ready, we need to run it before handing it over to customers. Here we need to find a balance between the fact that we provide our expertise and offer our vision of processes, and the fact that on the other side of the screen will be the same people whose format for solving familiar tasks has changed. We wanted to simplify someone's work, not complicate it and force them to retrain.
For this purpose, on the one hand, we practice interviewing - ‘imagine that you are a customer and you do this and that in this way’ - this helps to sort out the pool of further questions, discarding irrelevant ones.
In addition to the interview, it also helps to put yourself in the position of a person for whom the tasks we solve are his working routine. We generally try to automate everything around us (yes, this is a professional deformation), so it becomes clear at this stage which way to dig.
On the other hand, and this is the most interesting thing, we train ourselves to use what we have created ourselves.
Often we apply several strategies to solve any problems related to UI/UX or even internal logic:
- We take our colleague who has never heard of such a product. And we offer him a game: imagine that you, comrade, for example, are a risk taker. And now you need to prepare a calculation for your management according to such and such a methodology in this system. Where do you want to press? How do you understand this button? Or here's an example - now you're a SOC analyst and this is your first day on the job. This is an incident. What did you realise by looking at the card?
- Bringing in someone with relevant experience. We have a lot of people with diverse backgrounds - some of them were the risk guy, some of them came to us from the SOC. Usually such guys are involved in product development, but we try, on the contrary, to leave at least 1-2 people at the last stages, who could have a fresh look at the finished version and try to fulfil their usual functions in our platform.
- Debug of ready-made architectural solutions. Yes, sometimes we imagine ourselves as a compiler. It happens, it's normal.
- Finally, we as a team approach what we do from different angles, also playing our roles internally - it's a great chance to turn from analyst to designer or vice versa.
Through trial and error, we have developed for ourselves a kind of algorithm and roles that we try on ourselves in order to better understand the problem. Instead of team building, we try switching roles and often these business games lead us to breakthroughs in process solutions.
Training
For the very young and beyond!
There's a lot to tell and share here too. As I noted earlier, the format of business games for those who have not yet started to climb the career ladder is important because a person can try out the role of anyone beforehand.
But what if we look a few steps further? In particular, when we had the idea of ‘teaching kids about cyber security’ in our company, it ended up being all about simply introducing the youngest kids to the terms, simplifying the whole IS field to ‘you get attacked - you defend yourself’ as much as possible. We felt like this would make it easier to get into our field and make friends with cyber hygiene later on, not to mention it was just plain fun.
After all, our students. No, we don't put them in labs to play ThreatGen (although the thought was there...), but we give them a wide variety of tasks, with the opportunity to be a bank CISO or an engineer in an attempt to apply the knowledge gained in lectures in an almost combat format. Even at interviews or internships, we often set tasks for students in such a way that they have to consider the solution from a position that is not their own, a kind of forced out of the box.
In fact, we are only in the middle of our long journey of using business games to solve current problems. First of all, I wanted to share my experience in this direction and hopefully it will be useful for the whole community.
.jpg)
.jpg)
