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:
Gamification is designed to be fun and interesting for people. But before you introduce it, consider these important prerequisites:
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.
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.
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.
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.
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.
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.
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!
Address:
3003 East Chestnut Expy
STE# 575
Springfield, Mo 65802
Phone: 1-844-277-3386
Fax:417-429-2935
E-Mail: contact@appdevelopermagazine.com