Why Playing Board Games and D&D in Cyber Security Is Actually Useful

We're almost done. Now, before you all run off, I I cordially ask you to keep in mind, please do return your headsets. Okay? I know they look lovely in the dark and all of that, but if you're going to take them with you, there's going to be no bides. Next year, we're going to be selling microchips in hands to pay for the headsets. So because the last talk is going to be on speakers, you don't need them anymore. Welcome. You can return back to lovely takes venue and just listen or not. I mean not not forcing anybody. We have uh one more talk to go uh before all of this is going to be over for you. I myself uh

before I leave would like to thank you for putting up with me. I know every year somebody has this lovely question is why couldn't organizers themselves speak about it? At least they know something about it. But I'm very happy to listen to all the stories and um discover that turns out that in addition of playing video games, I should have played Dungeons and Dragons back in the day because that seems to be also a a very important topic. So before I going to go, I'm going to recommend give a book recommendation because I'm huge on books. I don't know if anybody read, but there's a cool series about a guy called Washington Poe by Matthew Craraven. So

for all the uh math enthusiasts here in the Washington Post series, the second character is Matilda Bradshaw who is a mathematics genius. So if you want to see more stories like the one you just heard, there's seven books about Washington Poe. There's plenty of that. So I've done my diligence. And now without further ado, we have one more person to come up on this stage and you're going to hear about why playing board games and Dungeons and Dragons in cyber security is actually useful. So give it up to Mr. Hans Mets.

[Music] [Music]

[Music]

Hello, I'm Hans and the topic is why you should be playing Tungeons and Dragons on company time and with company money. And I work at Opera, the very popular web browser, not the place where you go to singing performances. Uh so first of all light it's going to be about tabletop simulation games. Uh those who are here raise your hands. Who of you have played cyber security related tabletop in their career or life? Okay. Now raise your hand if in your life you have ever played either board games or Dungeons and Dragons or RPG video games. So that's like most of you, more than half of you. Uh but why even this thing started? Uh

we did a redesign of incident response procedures fully at Opera everything, all the workflows, all the checklists, all the policies and procedures and we needed to train people after this since everything changed. We also were not sure that our incident response procedures are actually correct. I mean we are pretty sure in what we are doing but we can still make mistakes. So how do we validate it? Like you can only validate it when you have an incident. And then there is the compliance aspect. We have to train our employees for incident response. So what are the ways you can do trainings? Disclaimer first. Absolutely any training has its use and any training is better than zero training. But that said, you

can like sort of scale the trainings in a way that the most basic one is the video training. You will record it, you will send it out, people will click okay, they will pass. You have a tracker for compliance. You can do inclass trainings. You can go more deeper and technical. Somewhere in the middle you're going to introduce gamification and 10 things are starting to get more interesting. So you have hands-on hacking collabs. You can get live feedback on your actions and on the absolute other end you can have tailor made trainings. By that I mean somebody goes into a team they will learn the problems they will learn the bottlenecks in the team. They will

design a specific scenario for that specific team and they will they will do a training and if we do a scale like this we can call it like usefulness scale or how good the training is. So the tailor made custom ones definitely are the most engaging and most useful. Uh but you can change the caption of the scale like it can just be cost. The tailor made custom training is also the most expensive and time consuming one and it's single use. You cannot reuse it. Whereas you will do the video training once and you can replay it hundreds and hundreds of times. So just for the compliance perspective, it would make sense to do video training and be

done with this. Uh however with incident response, it's like a bit different. We wanted to do something more. Why is it so special or why it's so different about it? Let's talk about how people make decisions. If you're shopping for groceries and you see the snack bar, you will just like crab it. Decision was made. However, most people when doing a bigger decision like buying a house, they want to have a lot more information. They want to look at it in all aspects. They want to make sure that they have all the time to be confident that this is the right decision. they are making. Same goes with business decisions. Same goes with big financial

decisions and investment decisions. In a case of an incident, however, you don't have this data. Also, you don't have any time and when you put the time pressure on top of it, it's especially hard for people to make any decision. So, we also sort of wanted to train for that. And we thought that maybe let's just do something in between hands-on but reusable. And we decided to do a tabletop training which would sit somewhere like this. You can reuse it to some extent. It has gamification and it requires active participation. So just to go quickly over what is a tabletop game? It's a pen and paper game. You play like a board game in different rooms or in a one big

conference room. You exchange data and information via data injects between the other parties. And uh it is a simulation of a real scenario where the main focus is on communication and decision making. The technical details do not matter that much. And it you can deliver it to like engineers, you can deliver it to management. So you can always alter the level. How deep do you go? Sounds perfect for our scenario, right? People can actually practice the procedures what we designed and they have to follow it. They can fail. They can make wrong decisions and nothing bad will actually happen. We are going to verify that our procedures actually work or if there is anything what we need to do to change

them and we can reuse it to some extent. It's still take going to take a lot of time but there is like element of reusability to this. So we know the problem, we know the solution. Let's go to the game design. Only a really small tiny issue. I had never ever designed any such game one year ago. This was the first time where I had to create something like this with the fake scenarios being like realistic to the company. It should be okay. I have had my fair share of hours in video games and board games and I mean too many hours. Shouldn't be that hard. Uh so let's just like three main challenges I thought I will

have. How do I communicate time progression? The game is not in real time. If we are going to spend one hour around the table in game it might be a full day. How do I make it clear to the players? Uh secondly, how do I control the team and communication? This should be fairly simple. You will make the teams, you will set the rules, what they can do, what they can't do. And then you have the scenario problem. How to ensure that the game is actually running smoothly, that there are no dead ends, and it can be played. Because if you take video games or board games, it's like fairly simple. A player runs into a door, they can turn around

and leave. They can knock on the door. They can open the door. Some people will try to talk to the door. Some players might even try to lick the door. But it's still all the options what are given by the game to the player. But with this scenario, we don't give them the actions and options. We just give them the failing scenario. And they need to figure out what to do on their own. similar to real cyber security incident. So let's just start designing. You have an action and then you take your magic crystal ball and you try to predict what would anyone in the room like to do based on this what action they would

take. So you have a few ways. Okay, it can go one of these three ways and from there they can decide something else. and they can make another decision. So something else will happen and something else will happen and sometimes there is relation between actions and a bunch of other things can happen and more things can happen and sometimes players can choose to do something what you didn't consider. Again should be okay. You just need a lot of paper and print outs and your living room is going to look like mess because you're trying out all the different parts. So, three months of doing this after working hours, I probably looked something like this. But

I was pretty confident that the game would work. So, let's go over the basics what we had. Like in most tabletop games, we gather people in a room, 10 to 20 people. We will divide them into the teams. Every team has a specific role. In our scenarios, we had the technical or product team. This was different a bit depending on the audience. Legal and privacy team put them together. We had our PR team handling internal and external communications as well as the security team. What we tried to do is that people would also get the different role. So when in your daily life you're a developer in this game now you are in PR team or security

team or in some other team if possible. And in addition to this, we also had external media who could make the situation better or worse for you depending on how you play the game as well as like minor mechanical things like social media and TM to actually run the game. And rules were also very simple. So you shall only use information what you formally have. We were playing in one big conference room meaning you will just hear what other teams are discussing but you cannot use this information if it's not formally given to you and all the formal communication should be very clear between parties as well. So we always know this team went and shared this piece of

information to that team and now they know before they didn't. All the business operation should continue normally and all actions must be realistic. For example, if you find a USB stick in a parking lot at the beginning of the game, you could assume that for the training scenario or hell is going to break loose, but you cannot isolate the network, turn off all the computers, and wait something for to happen because in real life, you wouldn't do it. So, you would have to act like you would probably act in a real life. And also team will decide when they have an incident. So the game starts and ends and within the game you have incident

somewhere. When do you start the official incident response procedure? It's entirely up to the players to press the big red button in the middle of the desk, start the incident, have an incident owner and start following the procedures. And yeah, the roll bar already covered. Uh based on these few scenarios and simple rules so far we have played eight games and a little bit more than 100 participants and we did a little bit of experimenting as well. So we have tiny bit of data. Uh personally what were my biggest fails of designing or running the game? Moderation is super hard and it takes practice. So few first sessions were not that great. You occur so many things you didn't know

you have to control or resolve or document and keeping track of the time was also super challenging. So for the initial two games it was a mess. Uh how I tried to communicate the time progression didn't work really well. So I had to change it. What I also learned is making sure that people are included is quite hard to do. You can have a few teams which are trying to attack the problem and brainstorm and you have to moderate it. Everyone has to have something to do and everyone has to have the chance to speak what they're going to do. And yeah, if you run this alone without any assistance, it's super hard to do everything, I highly recommend

having people to help you because you are running the game and you are handling data in checks and you are trying to see how the team communication works and you are trying to document everything as it goes as well. So this can be done up to 15 16 people by one person but it's not an easy task. While doing it, let's go into a bit more detailed what actually happened during the games. So these are random examples in random order. Sometimes it was one example, sometimes it happened multiple times in multiple games. But we had a game where during the game people were not sure if this this is an incident. Like maybe it's not. Maybe we don't have

enough data. Nobody wanted to press the button and call it an incident. And the scenario got escalating and escalating. Everything went worse. So we were 3 hours into the 4-hour game and formally nobody has opened the incident. What we all would learn from it, especially the playing teams, is that usually it's just better to report the incident immediately. Have a false positive, investigate it. Maybe it's nothing. Instead of waiting or fighting about like do we want to start an incident process because it will interfere with our normal business. And we also had the feedback in one game where they didn't exactly follow the procedure. They didn't get the timeline and documentation because they thought, well, it's a stupid game. In a real life

we would make good decisions but in a game it doesn't matter. Uh actually if you do something on a controlled easy scenario and you fail at this then you are very likely to fail in real life under real pressure. So if you play these games take it seriously or use this as like learning point. You cannot skip over into this site that oh yeah this is good but when I have actual incident when we are actually being hacked then I will do it properly before it I won't care also this happened in multiple games smart engineers can be a little bit stubborn and sometimes they can be too focused on wrong things instead of playing the game they start attacking

the game so they ask for the exact exploit what was used or they are trying to prove you that the breach what you describe in the game scenario it's not possible they know the technology stack cannot happen or how exactly did they got into this machine and we learned this can happen you have to control the game uh you have to explain to people that well you can also ruin all the movies with logic and you can also ruin all the video games with logic but maybe it's not worth it. So just play the game. Also you can design the scenarios that you're not giving mobile application to mobile engineers. You are giving them completely something else.

Then they have less knowledge to fight back and find your logic errors because you you're going to have them. And also in almost every game, engineers are really good problem solvers. You have a breach, you will patch the bug, release the code, incident solved. Oh, we didn't notify legal. Doesn't matter that user data was breached. But I mean now it's fixed. Data is not leaking anymore. Why we have to notify security team or legal and users are safe now. So I mean everything going forwards is good right? Uh they got to experience firsthand what it would actually mean in practice. So from their perspective it was fixed. Press did already know about it. Legal got informed through external parties

and then there was a mess to resolve it and to clear it later. Or we had another example where one team for a preached server asked if they can wipe the server. Of course, game controller allows them to wipe the server. And then you take this piece of papers which are the logs from the server and you will put them in the bin. And now the team has effectively given themselves no chance of figuring out what actually happens and what is actually compromised. If they want to delete the logs, they can like you should allow this. It will make the game more interesting. only one instance where for the first half an hour 40 minutes people were just

trying to find out whose fault is it and they really really learned that this doesn't help in any scenario when you have a cyber incident like focus on finding out what went wrong how to limit it doesn't matter who caused it at this point like first limit the damage and then you can figure it about was it a mistake? Was it deliberately done? Malicious action or not? But blaming people in the incident never helps. And yeah, distractions also work. So you can have multiple incidents happening at the same time. You can find something in a really important system and you're going to put all your focus there and you completely forgot about the less important system which had

actual huge data breach because it's not that obvious or you're focusing on a thing what looks important. So we learned exactly that for the game design. It also really helps for you to create these honey bots and things what can happen or where people can waste time. For example, you have whatever thing somebody asks you, I want to check the email server logs etc. to see if there have been any like obvious fishing emails. You have never thought about this, but you will allow them to do it. And they are just wasting time. And in a while, you come back and you tell them, "Oh, you found nothing." But they did spend some time on this like they would

in a real life. Uh probably the most impacting thing of like what turned how the legal and PR worked is lack of proper outward communication. So in most scenarios eventually it was known to the external press and in most scenarios players didn't know how to handle it. So in real life of course you have a dedicated team who is trained to handle such things but for the game it was useful to have them play through either you don't respond to press because you don't have enough data to respond to journalist what is happening so you give them no response or it's internal business they are interfering you don't have time so you don't talk to press who is actively

asking questions who is actively commenting on complaining meaning users. We learned that you should be doing this. You should be transparent. Even if you have nothing to say, you cannot ignore them. You can always acknowledge it that you have a problem. You're working very hard in fixing this and details will be later. Also, this highlighted the need to actually have the train press people and have others know what they're dealing with. Because in real life, you can have the incident and you can have your communications team going to engineering leads asking questions, what do we respond? What is happening? And you shush them away because like you have the logs and trouble and get us write something to

them. But no, you actually need to give them answer if they are asking. This happened in every game. This is one example. But we had similar things in all the games in multiple ways. People are so good at miscommunication that you even don't have to design this into the game. It will just happen naturally. So you can have a question going to security team and security team can pass on the question to developers. Meanwhile the product team can go to the same developers and say that oh security team is checking it. So effectively nobody does nothing. Everybody is waiting for somebody else to do something. Meanwhile more bad things continue happening and you have taken actually zero steps to

find out what the problem is. So for all these things, it was super useful for all the players to experience this in in the same room where they could see that oh this was a miscommunication and it really caused something and it was something so small and trivial what we like missed but we got some more damage because of it or we just like wasted some time where we didn't took any action. And on the last it was the point of decision making what was highlighted to absolutely every playing team. So some decisions are relatively easy. Where do we start investigating? Do we check these logs or these logs? If you talk about things like this, there is no

question. But sometimes you have to make decisions what cause loss of revenue or what will take down the service actions what will have business impact these are the most difficult actions where most people will freeze nobody wants to make the decision to put the system offline maybe it's wrong decision and then I'm held responsible some decisions do also you are not actually authorized to do So make sure that you at least know all the right people when it comes to the place where you need to turn off some services, notify users, have some loss of money, loss of availability, you know who to go and talk to about it, you know who could actually make the

decision or sign it off if it's needed. And yeah, it most of the scenarios we played escalated and got worse and worse because nobody wanted to make the decision. Everybody understood what needs to be done, but there was nobody brave enough to actually say that okay, now it's a decision, let's go and do it. Uh so yeah, people had all these learnings what we covered. Uh but they also got to know how the incident process actually works, how all the escalations work, how the communication should work and they got to see all the communication errors in practice and how they could affect the outcome of the scenario. And yeah, sometimes fast and wrong decisions are better than no decisions.

If you need to decide something, you will do it. If you make a wrong decision, you can always come back to this. You can decide something else. If you don't do any action, things will still continue happening and you don't have any control over it. And things are not obvious. Also, fastest actions what you can take are not correct ones. Sometimes they will make things worse. Like if you wipe the compromised server, you're digging a hole for yourself. Uh what else? So there was like a lot of things failing in the games. Maybe now it's a good time to mention that every game was Kobayashimaru. Every scenario was designed to fail. Teams had no control. They could only control how

much they are losing. And nobody knew this before they started playing. They only got to know this afterwards. Uh some people were really hopeful that they can somehow win or control the damage. No, everything will fail by design. And yeah, we also got the feedback that uh people who now assume different roles finally understood what is the role of the other people when we have like any crisis situation. It's not them pestering you about some small details or trying to interfere your work. They actually have a purpose in what they are doing. So let's say you want to design your own game. You should. It's huge fun to do and to play and uh you will find out so

many things about communication and mistakes you wouldn't imagine. So don't over complicate it. When I started it, my first idea was for every game I need the new scenario. No, you don't. You need like one or two good scenarios where you have this huge flowchart thought over and you can replay the same game because every game is played completely different. You have no idea how it plays out and you don't have to focus on that many scenarios. Just focus on something and you will learn later. Ensure that like you really have the reliable mechanisms to control the effective speed of the game. So are we in the middle of the first day, second day? Why it's also important is some

things are time critical. So when you do have a data breach what affects personal data, you have limited amount of hours to notify authorities about GDPR breach. When you have some other type of breach, you might have some other regulations to the stock markets. You need to inform. Uh so the game time actually should affect some of the decisions as well. And yeah, show it clearly and keep track of it. Keep your scenarios to the abstract level and fake clever where you actually control the text stacks. You don't want to get somebody attacking it. So you are not giving mobile application to mobile team. You're not get giving web applications to web team. They will

probably find errors in your scenarios instead of playing the game. So just avoid it. Give them something else. And yeah, of course, great honeybots and traps and everything for people to do something else. So the scenario is not that linear. It's not that straightforward. And when you're actually running the game, uh if your first game fails, don't change anything. Go and run it again. It might not be about the game. It might be the people playing it. And like I sort of mean it because all these eight games absolutely every game was completely different how it played out even though if the scenarios were save and yeah you have to control the time actively. If you see that people are

stuck you can either give them hints or you can make some things worse. If they are progressing too fast you have to like throttle the game. It also doesn't help when you have one person speedrun it and just raising their hand and going me me I know like we can do this and this and this and this and then we win. This is not the purpose like who gets there first. Later on uh for me it was very useful to actually do some maybe testing. I played exact same scenario for two teams. Only thing what they changed is how I control and communicate time progression. So I could have some data to see which worked

better. Was it this thing what I wrote on the whiteboard or was it the hourglass I had? By the way, our class is a really good idea because it also puts the time pressure on the people and it's really visible. And yeah, control the people. They should be playing the game. Also ensure that you have no team left alone. And uh you have to tell people to like shut up and wait their turn. You don't want two active teams running the game. It's a turnbased. Everybody gets their turn. You have the really good and correct idea, but it's not the time for it. Somebody else has to do something or make a decision about it.

And yeah, it takes the time to set it up. You have to consider it. Uh you cannot rush it, especially when you're doing it for the first time. You will never reach 100% or near 100% training level with such things. So if you need to train all your personnel for incident response, you still need the PowerPoint training as well for compliance reasons. And if you have Dungeons and Dragons and board game experience, it helps massively. Cannot overemphasize this. That was it. Thank you all B sites. Thank you for Opera to actually let me do this and take the time. And also a special thanks to Peter who as a post of me is actually a game designer and knows

what he's doing. So after two games, I took all the data, transcripts, everything. And I went and I spoke to him of I'm running a project like this. Here is where I'm failing. Can you help me a little bit? And he could. So he actually played a really good role in this as well. So that's it. Questions? [Applause]