A couple of years ago, I had to complete a space medicine course. Although I thought that I knew what to expect, day one started in kind of an unusual way. The group was divided into teams and challenged to build the tallest possible free-standing structure using only raw spaghetti, marshmallows and medical tape. The challenge was far more difficult than it probably sounds. Spaghetti is not exactly the sturdiest building material.
After about 20 minutes, the instructor called time’s up, and the winning team was announced. At that point, all of the teams were brought together into one big group and asked to repeat the challenge--this time, cooperatively. In the end, we were able to construct a structure that was far larger than anything that the individual groups had been able to build. The reason why we were so successful on the second attempt was because we were all able to compare notes regarding what had worked and what hadn’t worked in our individual teams.
The exercise that I just described was intended as an ice-breaking, team-building exercise to help us get to know each other a little bit better before we got started with the space medicine curriculum. Even so, I think that the some of the foundational aspects of this exercise in gamification could be used to help to improve enterprise security.
Now, please do not misunderstand me. I’m not suggesting that your enterprise security team go build things out of spaghetti. What I am suggesting is that by dividing your security team into small groups and participating in relevant head-to head-competitions, it may be possible to use the lessons learned in those games to significantly improve the organization’s defenses. This, of course, raises the question: What kind of competition?
When I was a kid, I heard some of the other kids in school talking about playing "cops and robbers." Although I’m not entirely sure of what the rules were for this playground game, I’m pretty sure that the cops’ job was to catch the robbers, and the robbers' job was to get away if possible. So, with that in mind, consider how such a game might be adapted to the world of security. While I don’t envision a bunch of IT pros chasing each other around a playground, I can definitely picture a game of defenders vs. hackers being played in a lab environment.
Although this idea might seem kind of corny, and possibly a bit abstract, this is actually the method that some educational institutions are now using to teach cybersecurity. And, believe it or not, it isn’t just schools that have begun gamifying security training. Even Microsoft has gotten in on the act.
Microsoft offers a four-week course in Enterprise Security Fundamentals through an online learning portal called EDx. Although this course does include traditional academics, it also incorporates a number of “Red Team – Blue Team” exercises. As you have probably already figured out, the students are divided into two groups, a red team and a blue team. The red team’s job is to attack the blue team’s security infrastructure, and the blue team’s job is to defend against the attack. At the end of the exercise, both teams come together (just like in my spaghetti exercise) to figure out the best way to strengthen a network’s defenses based on the lessons learned during the exercise.
It is this coming together at the end of the exercise where the most valuable lessons are learned. The comparing of notes helps everyone involved to learn from the experience. The key is to review the exercise in an effective way. In fact, I would go so far as to say that the way in which the game is reviewed is absolutely critical. Let me give you an example from my life outside of IT.
Over the last several years, I have had the privilege of flying on a number of parabolic (zero gravity) flight campaigns in both the United States and in Canada. These aren’t tourist flights. There are typically several universities and various other organizations that are depending on the flight crew to perform various experiments on the flight.
The most important part of any of these flights is the debrief that happens once we are back on the ground. The debrief follows a very strict protocol in which the flight safety officer will outline the various flight parameters, and state which of our objectives were and were not achieved. After that, each member of the flight crew is required to talk about his or her own personal observations. We talk about ideas for making it easier to perform a particular experiment, safety concerns, things that could have potentially interfered with our job, and the list goes on.
There are a couple of reasons why this debrief session is so important. First, each flight campaign consists of multiple flights. The lessons learned on the first flight of a campaign can help the second flight to be more successful. Second, people have their own job to do, and may not be aware of what is going on elsewhere in the plane. Going through an exhaustive debrief helps us to understand the intricacies of each other’s tasks. More importantly, there may be a technique that we can learn from another crew member that will help make our own job easier. Similarly, a crew member might realize that he or she needs to do their task in a slightly different way to avoid interfering with something that someone else is trying to do.
A red team vs. blue team, enterprise security competition can certainly be a fun diversion from the normal day-to-day stuff, but the real benefit to these “war games” can only be realized if everyone involved takes the time to compare notes at the end of each game, and if the lessons learned are applied to the organization’s production environment.
