How gamifying security improves cooperation with developers

Scaling security across development challenges the most seasoned professionals. Regardless of company size or industry, risks can no longer be comfortably managed across an organization as a centralized function. Security leaders need people in other departments to understand risks and help their teams remediate and reduce them for security to be successful. Last month, I moderated a panel hosted by Cobalt.io with Dinis Cruz, CISO at Glasswall, and the conversation centered around gamification’s role in security. While security definitely can’t be reduced to a game, gamification has positively impacted our security efforts and improved cooperation with development significantly. We considered gamification for two basic reasons:

1. To scale security efficiently.

2. To improve security engagement with engineering.

Gamification is designed to be fun and interesting for people. But before you introduce it, consider these important prerequisites:

• Obtain buy-in from senior management—Ask different stakeholders if something similar has been tried before and how it turned out. Use this insight to shape your gamification strategy. In general, make sure there are no negative connotations relating to gamification. When introducing new concepts you want to make sure that there aren’t any ghosts in the past that will haunt your efforts. 
• Collect copious security data—We spent a lot of time gathering loads of security data on the development pipeline, vulnerabilities, etc. Even before we knew what to do with it, we collected data. This helped our gamification efforts later on.
• Create a Security Services Catalog—The purpose of creating this was to be able to link data to our organizational structure. The data aggregation solution that links into our service catalog originally started for our own security purposes. However, engineering quickly came on board after seeing data such as how much each team is spending on certain resources, how many things they have running, and how SLAs are integrated into it. It’s highly likely that the rest of the engineering community will soon recognize the benefits of such solutions and start using it for things like team-based cost and results from utilization tracking.

Now that we have looked into the prerequisites and are ready to implement gamification I’d like to offer six pieces of advice based on the program that we have built out at Skyscanner.

1. Make sure everyone has time to play.

Before you start the gamification of security, you need to create time for engineering to address security issues. At Skyscanner, we created something called “engineering health,” to ensure that engineering team members would have the time to help us identify, remediate, and reduce risks. Each of our development teams devotes roughly a quarter of its backlog to operational improvements. Within the “engineering health” portion of the backlog, there’s an allotment for security. So whenever something related to security needs to get done, it falls into that bucket, which creates time to address security issues.

2. Start small and expand over time.

When we first introduced gamification, we started small and expanded over time. We didn’t require high data quality right away. Instead, we focused on simplicity and small initiatives. The initial solution focused on surfacing data through a centralized dashboard that was exposed to all the engineering teams. Security metrics involved were purely around enablement of various security pipeline tooling instead of complex and usually noise heavy vulnerability feeds. At this stage, we didn’t even include vulnerabilities. Now as we are beyond that phase we are in the process of adding that vulnerability data alongside other things. It’s extremely important to start small in order, not to overload engineers with too much confusing information.

3. Create real-time feedback loops.

Gamification requires a really good communication plan so that everyone can see progress quickly. We accomplished this with real-time feedback loops. We created a slackbot that alerts engineers immediately if something is insecure and presents a certain level of threat to our business. The rapid feedback is vital.  We’ve seen from experience that after 15-20 days if you approach a developer with a mistake in the codebase, it’s much harder for them to fix it because their workload has already shifted. Fixing things in real-time as much as possible was a primary aim of our gamification.

4. Make data visible -- anytime, anywhere).

Surfacing the data and making it continuously visible to all teams in an easily digestible way such as through dashboards is extremely important. We have created live dashboards that are exposed to everyone showing various security scores associated with our engineering teams. When developers can refer to the dashboard in real-time to see, for example, how fixing a vulnerability has contributed positively to the security posture of the organization, it makes a huge difference. As a result, people recognize their impact on the business right away.

5. Don’t forget about the rewards.

One of the most suitable rewarding models for this concept involves swag-based rewards like mugs, hats, t-shirts, and shout-outs for tribes and squads that are scoring really well. You can also incorporate security-related workloads into performance reviews. I actually don’t recommend giving purely financial rewards for security gamification as companies who have tried this saw mixed results and potential internal conflicts of interest. Even beyond the swag prizes for successful teams, the developers respond even more to a feeling of ownership and the proven data on how they have positively impacted the security of the business.

6. Finding more games to play.

Gamification made a huge difference for us. We’re currently working on risk forecasting and adding more monitoring and automation to our gamification. For example, if we notice that a development team is repeatedly introducing similar types of vulnerabilities over a longer period of time, the team will automatically receive mandatory training on that topic. Business-critical application deployments can even be blocked until a mandatory training has been completed. In this way, the training we offer is pinpointed for effectiveness and hopefully avoid fatiguing busy engineers and developers.

As we look to expand gamification, we want to find more ways to digitize and automate threat modeling. So far, the results of our gamification effort have increased engagement, communication, and cooperation across security and engineering, so I say, let the games continue!